7.1 产品分类 (Product Classification)
7.1.1 概述
根据《网络弹性法案》(Cyber Resilience Act, CRA)，每个含数字元素的产品都必须被归入一个 CRA 风险类别。分类结果决定了所需的合规评估程序。CRA 区分四个类别：标准 (Standard)、Class I（重要）、Class II（重要）和关键 (Critical)。
法律依据
Art. 7(1) CRA： 具有 Annex III 所列产品类别之核心功能的含数字元素产品，属于重要含数字元素产品，分为 Class I 与 Class II。
Art. 8(1) CRA： 具有 Annex IV 所列产品类别之核心功能的含数字元素产品，属于关键含数字元素产品。
委员会实施法规 (EU) 2025/2392 载明了重要产品与关键产品各类别的技术描述。
Art. 64(3) CRA： 违反 Art. 32 的合规评估义务可能引发行政罚款。
「标准」一词
标准（指南中称 default）并非 CRA 定义的术语。此处用于指代不具有 Annex III 或 IV 类别核心功能、因而适用 Art. 32(1) 合规评估机制的产品。
7.1.2 核心功能 —— 决定性概念
分类不取决于产品能做什么，而取决于其核心功能。CRA 未定义该术语；委员会指南作出了界定。
定义
含数字元素产品的核心功能，指该产品若不具备便无法实现其预期用途的主要特征与技术能力。
其判断须结合产品的具体情境与使用条件，并考虑（其中包括）制造商在使用说明、宣传或销售材料及陈述以及技术文档中提供的信息。
规则 1 —— 附属功能不改变分类
产品很少局限于其核心功能；几乎所有产品都会执行额外功能。产品执行了重要或关键类别技术描述之外的其他或额外功能，并不妨碍其具有该核心功能。
反之——Art. 7(1) 对重要产品作了明确规定，同样逻辑适用于关键产品：
仅仅集成并不足够
仅仅集成某个重要或关键的含数字元素产品，并不使集成方产品本身成为重要或关键产品。
示例： 某智能手机集成了具备实施法规 (EU) 2025/2392 附件 I 第 11 项所述功能的操作系统。该操作系统管理硬件资源并执行应用程序——但智能手机作为整体具有不同的核心功能：使用户能够通信并获取信息与服务。因此它不具有操作系统的核心功能。
规则 2 —— 明显超出或明显不足
某产品可能与某个重要或关键类别相似，或属于同一大类产品族，但其核心功能明显超出或明显不足于该类别。
| 情形 | 示例 | 判定 |
|---|---|---|
| 超出 | SOAR 软件通常能够从多源采集数据、进行分析与关联，并将其呈现为可执行的安全信息——即 SIEM 的功能。但其核心功能明显超出 SIEM，事件响应等能力构成其核心技术能力 | 通常不被视为具有 SIEM 系统的核心功能 |
| 不足 | 日志采集与可视化工具摄取日志数据并展示系统事件的基础仪表盘。它们可支持安全监控，但不执行数据关联，也不提供可执行的安全洞察 | 通常不被视为具有 SIEM 系统的核心功能 |
| 两者皆非 | 某产品的额外功能仅仅补充或增强了本身即对应某重要或关键类别的核心功能 | 保留该核心功能并据此分类 |
判断依据是产品的主要特征与技术能力，结合其预期用途客观衡量——而非依据其描述或营销方式（在该描述未反映实际技术特征时）。
不得作虚假陈述
制造商不得对其产品的核心功能作虚假陈述，以规避适用于重要或关键产品的合规评估机制——例如过度强调或淡化某些功能的作用，使产品看似明显超出或明显不足于某一核心功能。
宣传材料、使用说明与技术文档之间的明显不一致，正是市场监管机构会关注的对象。
规则 3 —— 恰好一个核心功能
一个产品，一个核心功能
就确定适用的合规评估机制而言，含数字元素的产品不得有一个以上的核心功能。
依 Annex VII，技术文档必须描述产品的预期用途及所采用的合规评估程序。因此必须明确标明核心功能——唯有如此才能确定正确的合规评估机制，市场监管机构也才能核查本法规是否被正确适用。
规则 4 —— 可单独获取的模块是独立产品
有些产品作为单一产品投放市场，但由具有独立功能的不同模块构成。
| 情形 | 分类层级 |
|---|---|
| 制造商也单独提供这些模块——单独购买、单独许可或单独订阅 | 每个模块都是独立产品，按其自身的核心功能分类 |
| 模块仅作为集成产品的组成部分提供，不单独提供 | 核心功能在集成产品层面确定 |
示例： 某制造商将由 SIEM、入侵检测系统与分析模块组成的统一安全套件投放市场，并同时提供各模块的单独订阅。每个模块都是独立产品：SIEM 模块适用 Class I 重要产品的机制；入侵检测系统适用 Class II（防火墙、入侵检测与防御系统）；分析模块适用标准机制，因其核心功能不对应任何重要或关键类别。
规则 5 —— FOSS 减免 (Art. 32(5))
符合 FOSS 条件并投放市场的 Class I 或 Class II 重要产品，可依 Art. 32(5) 采用标准类别的合规评估程序 → 1.7 自由与开源软件及其管理者。
7.1.3 分类决策树
以下决策树概述了产品分类的系统化方法：
第 0 步 —— 确定产品的「唯一」核心功能（→ 7.1.2）
即产品若不具备便无法实现其预期用途的主要特征与
技术能力。附属功能与被集成的功能不计入。
│
▼
该核心功能是否对应 Annex IV 中的某个类别？
├── 是 → 关键 (CRITICAL)（Module B+C 或 H；EUCC 仅在 Art. 8(1) 授权法案通过后）
└── 否
└── 是否对应 Annex III 中的某个类别？
├── 是 → 属于哪个类别？
│ ├── Class II → CLASS II（Module B+C 或 H）
│ │ 属 FOSS 且已投放市场 → 标准机制（Art. 32(5)）
│ └── Class I → CLASS I（Module A* 或 B+C）
│ 属 FOSS 且已投放市场 → 标准机制（Art. 32(5)）
└── 否 → 标准 (STANDARD)（Module A）* Module A 仅在完全适用协调标准时可用
7.1.4 产品类别
类别：标准（默认）
合规评估： 内部控制 (Internal Control)（Module A）— 自我评估
大多数产品属于此类别。制造商自行执行合规评估。
典型产品：
- 标准 Web 应用
- 内部工具和实用程序
- 非关键容器镜像
- 简单 IoT 传感器
Class I（Annex III）
合规评估： 内部控制（Module A）（适用协调标准时）或 EU 型式检验（Module B+C）
Annex III 中的示例：
- 身份管理系统和特权访问管理软件
- 独立浏览器
- 密码管理器
- 搜索、删除和隔离恶意软件的软件
- VPN 产品
- 网络管理系统
- SIEM 系统
- 引导管理器
- 防火墙、IDS/IPS（非工业用途）
- 路由器、调制解调器（用于互联网接入）
- 具有安全相关功能的微控制器
- 操作系统（非服务器/桌面 Class II）
Class II（Annex III）
合规评估： EU 型式检验（Module B+C） 或 全面质量保证（Module H）
Annex III 中的示例：
- 虚拟机管理程序和容器运行时环境
- 工业用途的防火墙和 IDS/IPS
- 防篡改微控制器/微处理器
- 服务器、桌面、移动设备的操作系统
- 公钥基础设施和证书颁发机构
- 工业自动化与控制系统 (IACS)
- 工业 IoT 设备（不受其他行业法规约束的）
类别：关键（Annex IV）
合规评估（当前）： 根据 Art. 32(3) CRA，采用 EU 型式检验（Module B+C） 或 全面质量保证（Module H）。
合规评估（有条件，未来）： 欧洲网络安全证书（EUCC），保证级别为"实质性 (substantial)"或更高——仅在欧盟委员会根据 Art. 8(1) CRA 通过指明该产品的授权法案后才成为强制要求。
EUCC 并非自动强制
对于 Annex IV 产品，EUCC 并非自动要求。根据 Art. 8(1) CRA，委员会可通过授权法案触发 EUCC 义务；截至 2026 年 6 月，这尚未发生。在此之前，适用 Art. 32(3) CRA 规定的标准合规评估（Module B+C 或 H）。
Annex IV 中的示例：
- 硬件安全模块 (HSM)
- 智能卡及类似设备（含安全元件）
- 智能卡读卡器
- 机器人和机器控制器的传感器和执行器
- 智能电表网关
7.1.5 各类别的合规评估
| 类别 | Module A（自评） | Module B+C（型式） | Module H（质量） | EUCC |
|---|---|---|---|---|
| 标准 | ✅ | - | - | - |
| Class I | ✅* | ✅ | - | - |
| Class II | - | ✅ | ✅ | - |
| 关键 | - | ✅ | ✅ | ⚠️† |
* 仅在适用协调标准或符合 EU 网络安全认证时
† 对于关键产品，EUCC 目前并非强制。只有在委员会根据 Art. 8(1) CRA 通过授权法案后才具有约束力。在此之前，适用 Art. 32(3) CRA 规定的 Module B+C 或 H（截至 2026 年 6 月）。
AI Act 协同
在 AI Act Annex III 中列为高风险 AI 系统的产品也可能出现在 CRA Annex III 中（如 IACS、安全组件）。当产品同时受两部法规约束时，适用更严格的合规评估。请协调 CRA 和 AI Act 团队之间的分类决策。
适用性检查
使用交互式适用性检查逐步完成完整分类流程，包括各产品类别的工作量估算。
7.1.6 BAUER GROUP 的相关产品类型
对照 Annex III（重要产品）审查
| Annex III 类别 | 是否适用于 BAUER GROUP？ | 理由 |
|---|---|---|
| 身份管理系统 | 待审查 | 如提供 IAM 解决方案 |
| 密码管理器 | 待审查 | 如提供凭据管理 |
| VPN 产品 | 待审查 | 如提供 VPN 解决方案 |
| 网络管理系统 | 待审查 | 如提供网络工具 |
| 防火墙、IDS/IPS | 待审查 | 如提供安全产品 |
| 路由器、调制解调器 | 待审查 | 如提供带固件的网络硬件 |
| 微控制器（安全相关） | 可能适用 | ESP32/STM32 具有安全相关功能的固件 |
| 操作系统 | 待审查 | 如提供操作系统级产品 |
| 容器运行时 | 否（通常） | 我们使用容器但不提供运行时 |
| 虚拟机管理程序 | 否（通常） | 我们使用虚拟机管理程序但不提供 |
| 工业 IoT 设备 | 可能适用 | 如提供工业用途的 IoT 设备 |
对照 Annex IV（关键产品）审查
| Annex IV 类别 | 是否适用于 BAUER GROUP？ | 理由 |
|---|---|---|
| 硬件安全模块 (HSM) | 否（通常） | 我们使用 HSM 但不生产 |
| 智能卡/安全元件 | 否（通常） | |
| 智能电表网关 | 待审查 | 如涉及能源产品 |
BAUER GROUP 产品的典型分类
| 产品类型 | 预期类别 | 评估程序 |
|---|---|---|
| 标准 Web 应用 | 标准 | Module A |
| REST API | 标准 | Module A |
| 容器镜像（微服务） | 标准 | Module A |
| NPM/NuGet 库 | 标准 | Module A |
| ESP32 IoT 传感器（非安全关键） | 标准 | Module A |
| ESP32/STM32 工业控制器 | Class I | Module A* 或 B+C |
| 带认证功能的固件 | Class I | Module A* 或 B+C |
| 带固件的网络路由器 | Class I | Module A* 或 B+C |
7.1.7 分类流程
对于每个产品，必须执行以下流程：
1. 功能审查
验证产品是否满足 Annex III 或 IV 中列出的功能之一。系统性地与所有类别进行比对。
2. 预期用途
考虑预期用途：
- 产品是否用于关键基础设施？
- 是否处理敏感/个人数据？
- 是否具有网络功能？
- 被入侵是否可能造成物理损害？
3. 记录分类结果
使用风险评估模板记录分类决定。
建议
如有疑问，请选择更高的类别。保守的分类在监管上比过低的分类更安全。
7.1.8 分类的文档化
每个产品的分类记录在产品描述中：
- 对照 Annex III 和 IV 审查 — 系统性地与所有类别比对
- 理由 — 为何适用此分类（引用附录）
- 合规评估程序 — 适用哪个模块
- 日期 — 分类执行日期
- 责任人 — 分类执行人
7.1.2 节解释的来源与法律地位：欧盟委员会 CRA 指南。