📋 目录
| 章节 | 标题 | 核心内容 |
|---|---|---|
| 背景概述 | 为什么需要CRA？ | 立法背景与核心问题 |
| 第一章 | 总则 | 适用范围、定义、产品分级 |
| 第二章 | 经济运营主体义务 | 制造商/进口商/分销商/开源软件责任 |
| 第三章 | 产品合规性 | 合规路径、CE标志、合格声明 |
| 第四章 | 合规评估机构通报 | 认证机构资质与管理 |
| 第五章 | 市场监督与执法 | 监管机构职权与产品召回 |
| 第六~八章 | 授权/保密/罚则/过渡条款 | 授权机制、处罚标准、生效时间表 |
| 附录摘要 | 关键附录 | 安全要求清单、产品分类列表 |
🌐 背景概述：为什么需要CRA？
核心问题
在CRA颁布之前，欧盟面临两大严峻挑战：
问题一：数字产品网络安全水平低
├── 漏洞普遍存在（硬件+软件）
└── 安全更新不及时、不一致
问题二：用户缺乏足够信息
├── 无法判断产品的安全水平
└── 不知道如何安全使用产品
立法背景时间线
2020年12月 欧盟网络安全战略发布
2022年 欧委会提出CRA草案
2024年10月23日 欧洲议会和理事会正式通过
2024年11月20日 在欧盟官方期刊（OJ L）发布
2027年12月11日 绝大多数条款正式生效（过渡期3年）
CRA的核心目标
| 目标 | 具体内容 |
|---|---|
| 🔒 提升产品安全 | 要求数字产品在全生命周期内符合网络安全要求 |
| 📢 提高透明度 | 要求制造商公开披露安全支持期限 |
| ⚖️ 统一内部市场 | 建立横向统一标准，消除各国法规碎片化 |
| 🛡️ 强化供应链安全 | 将安全要求延伸至供应链各环节 |
CRA与其他法规的关系
CRA（横向基础法规）
├── 与 NIS2（EU 2022/2555）：互补，NIS2管实体，CRA管产品
├── 与 AI法案（EU 2024/1689）：协同，AI产品需同时满足两法
├── 与 RED指令（2014/53/EU）：互补，RED已涵盖无线产品部分安全要求
├── 与 MDR（EU 2017/745）医疗器械：MDR优先，CRA不适用
└── 与 GPSR（EU 2023/988）：协同适用消费品通用安全
第一章：总则（General Provisions，Articles 1–12）
📌 本章核心：界定法规的适用范围、产品分级体系和关键术语，是理解整部法规的基础。
1.1 法规主要内容（Article 1）
CRA规定了以下四大方面的规则：
- 上市规则 — 数字产品上市前须满足的网络安全要求
- 设计开发安全要求 — 产品硬件/软件设计、开发、生产阶段的基本安全要求（附录I Part I）
- 漏洞处理要求 — 产品全生命周期内的漏洞管理流程要求（附录I Part II）
- 市场监督规则 — 市场监管部门的执法机制
1.2 适用范围（Article 2）
适用对象：所有在欧盟市场销售，且具有直接或间接逻辑/物理数据连接功能的软硬件产品（即"数字产品"，products with digital elements）。
主要豁免（以下产品不受CRA管辖）：
| 豁免类别 | 具体法规 | 说明 |
|---|---|---|
| 医疗器械 | EU 2017/745（MDR）/ 2017/746（IVDR） | 已有专门法规 |
| 车辆安全 | EU 2019/2144 | 汽车网络安全另有规定 |
| 航空产品 | EU 2018/1139 | 航空安全认证豁免 |
| 船舶设备 | Directive 2014/90/EU | 海事设备豁免 |
⚠️ 认证工程师注意：即便产品同时受其他法规管辖（如RED指令无线产品），若其他法规仅部分覆盖CRA要求，则CRA仍可能补充适用。
1.3 产品分级体系（Articles 7–8，Annexes III–IV）
CRA按网络安全风险将数字产品分为三个级别：
┌─────────────────────────────────────────────────────────────┐
│ CRA 产品分级体系 │
├─────────────────────────────────────────────────────────────┤
│ 📦 默认类产品（Default） │
│ ├── 覆盖范围：绝大多数数字产品 │
│ ├── 合规路径：制造商自我声明（Self-declaration） │
│ └── 代表产品：普通IoT设备、消费电子等 │
├─────────────────────────────────────────────────────────────┤
│ ⚠️ 重要类产品（Important，附录III） │
│ ├── 分为 Class I 和 Class II 两级 │
│ ├── 合规路径：Class I可用第三方CB或自我声明+标准 │
│ │ Class II必须经过第三方认证机构（NB） │
│ └── 代表产品：OS、路由器、浏览器、VPN、防火墙等 │
├─────────────────────────────────────────────────────────────┤
│ 🔴 关键类产品（Critical，附录IV） │
│ ├── 覆盖范围：最高风险产品 │
│ ├── 合规路径：须持有欧洲网络安全证书（EU Cybersec Cert） │
│ │ 或经强制第三方审核 │
│ └── 代表产品：HSM硬件安全模块、智能电表网关、安全芯片等 │
└─────────────────────────────────────────────────────────────┘
附录III 重要产品清单（Important Products，Annex III）
Class I（需要第三方或自我声明+标准）：
| 序号 | 产品类别 |
|---|---|
| 1 | 身份管理与特权访问管理系统（含生物识别读取器） |
| 2 | 独立及嵌入式浏览器 |
| 3 | 密码管理器 |
| 4 | 防病毒/反恶意软件 |
| 5 | VPN产品 |
| 6 | 网络管理系统 |
| 7 | SIEM系统（安全信息与事件管理） |
| 8 | 启动管理器（Boot managers） |
| 9 | PKI及数字证书签发软件 |
| 10 | 物理/虚拟网络接口 |
| 11 | 操作系统 |
| 12 | 互联网路由器、调制解调器、交换机 |
| 13 | 带安全功能的微处理器 |
| 14 | 带安全功能的微控制器 |
| 15 | 带安全功能的ASIC和FPGA |
| 16 | 智能家居通用语音助手 |
| 17 | 带安全功能的智能家居产品（智能门锁、安防摄像头、婴儿监视器、报警系统） |
| 18 | 具有社交互动或位置追踪功能的联网玩具 |
| 19 | 健康监测可穿戴设备或儿童可穿戴设备 |
Class II（必须经过NB第三方审核）：
| 序号 | 产品类别 |
|---|---|
| 1 | 虚拟机监控程序（Hypervisors）和容器运行时系统 |
| 2 | 防火墙、入侵检测/防御系统（IDS/IPS） |
| 3 | 防篡改微处理器 |
| 4 | 防篡改微控制器 |
附录IV 关键产品清单（Critical Products，Annex IV）
| 序号 | 产品类别 |
|---|---|
| 1 | 带安全盒的硬件设备（HSM等） |
| 2 | 智能计量系统中的智能电表网关及高级安全加密处理设备 |
| 3 | 智能卡或类似设备（含安全元件） |
1.4 关键术语速查（Article 3，部分）
| 术语 | 定义简释 |
|---|---|
| 数字产品（PDE） | 具有数据连接功能的软件或硬件产品及其远程数据处理解决方案 |
| 制造商 | 开发/制造数字产品并以其名义/商标上市的自然人或法人 |
| 经济运营主体 | 制造商、授权代表、进口商、分销商等所有相关方 |
| 重大修改 | 影响产品合规状态或改变其预期用途的上市后变更 |
| 支持期 | 制造商承诺提供安全更新的期限 |
| 漏洞 | 可被网络威胁利用的产品弱点/缺陷 |
| 可被利用漏洞 | 在实际操作条件下可被攻击者有效利用的漏洞 |
| 积极被利用漏洞 | 有可靠证据表明已被恶意行为者实际利用的漏洞 |
| 软件物料清单（SBOM） | 记录软件组件及其供应链关系的正式文件 |
| CE标志 | 制造商声明产品符合CRA及相关法规要求的标识 |
| 合规评估机构（CAB） | 开展合规评估的机构 |
| 通报机构（NB） | 经成员国官方指定、授权开展合规评估的机构 |
1.5 与其他法规协同适用规则（Articles 4–5）
- Article 4（RED指令协同）：产品若同时受RED指令（无线设备指令2014/53/EU）约束，则CRA的部分安全要求（第3(3)(d)(e)(f)条相关内容）视为已被RED满足，避免重复审查。
- Article 5（AI法案协同）：对于已获AI法案高风险认证的产品，AI法案的合规评估程序同等有效，CRA不再单独要求重复测评，但需在EU符合性声明中明确体现。
第二章：经济运营主体义务（Articles 13–26）
📌 本章核心：规定制造商、进口商、分销商、授权代表、开源软件管理者各自的法律义务。对认证工程师而言，本章是最重要的实操章节。
2.1 制造商义务（Article 13）— 核心责任清单
制造商是CRA合规的第一责任主体，须承担以下24项义务中的关键要点：
🔧 产品设计与上市前义务
| 义务 | 说明 |
|---|---|
| 网络安全风险评估 | 在产品整个生命周期（规划→设计→开发→生产→交付→维护）中开展并记录风险评估 |
| 符合附录I要求 | 产品须满足附录I Part I（产品安全）和Part II（漏洞管理）的全部基本要求 |
| 确定支持期限 | 须评估并确定产品的安全支持期（通常不少于5年） |
| 提供用户信息 | 产品须附带附录II规定的用户信息和使用说明（支持期≥10年内保持可获取） |
| 标注支持期终止日期 | 在产品、包装或数字方式清晰标注支持期结束时间（至少到月份） |
| 唯一身份识别 | 产品须标有类型/批次/序列号等标识 |
| 制造商联系方式 | 在产品/包装上标注名称、地址、邮件/网站 |
| 设立漏洞报告联系点 | 必须设置用户可直接联系的单一联系点（不得仅用自动回复工具） |
| CE标志 | 完成合规评估后加贴CE标志 |
| EU符合性声明 | 提供完整或简化版EU DoC |
| 技术文档 | 按附录VII要求准备并保存技术文档（≥10年） |
🔒 上市后义务（持续性）
| 义务 | 说明 |
|---|---|
| 持续提供安全更新 | 在支持期内，须免费及时提供安全补丁/更新 |
| 主动发现漏洞 | 须积极监控并记录产品漏洞，建立CVE披露机制 |
| SBOM（软件物料清单） | 须建立并维护SBOM，记录所有软件组件及依赖关系 |
| 不合规时立即纠正 | 发现产品不合规须立即采取纠正措施（召回/下架） |
| 停产时通知 | 停止运营前须通知监管机构和用户 |
2.2 漏洞上报义务（Article 14）— ⏱️ 关键时限
这是CRA最具操作性的条款之一，制造商必须严格遵守以下上报时限：
发现"积极被利用漏洞"或"严重安全事件"
│
▼
【24小时内】发送早期预警通知
├── 上报至：CSIRT（协调员）+ ENISA
└── 内容：漏洞基本情况，受影响成员国
│
▼
【72小时内】发送漏洞通知
├── 上报至：单一报告平台（Article 16）
└── 内容：产品信息、漏洞性质、已采取的缓解措施
│
▼
【补救措施可用后14天内】提交最终报告
└── 内容：漏洞描述+严重性+影响、攻击者信息（如已知）、
安全更新详情
💡 认证工程师提示：24小时/72小时时限是强制性的，制造商需提前建立内部安全事件响应机制，确保能在规定时间内完成上报。
2.3 进口商义务（Article 19）
进口商须确保：
- ✅ 制造商已完成合规评估程序（Article 32）
- ✅ 制造商已准备技术文档
- ✅ 产品贴有CE标志并附有EU符合性声明
- ✅ 产品附有符合附录II的用户说明（用当地语言）
- ✅ 制造商已正确标注产品识别信息
⚠️ 如发现产品不合规或存在重大网络安全风险，进口商不得将产品上市，并须立即通知制造商和监管机构。
2.4 分销商义务（Article 20）
- 在销售前核查产品是否贴有CE标志、附有EU符合性声明和用户说明
- 发现不合规或重大风险时，须停止销售并通知制造商和监管机构
- 发现制造商已停止运营时，须通知监管机构和用户
2.5 授权代表（Article 18）
- 制造商可书面授权欧盟境内代表，代表其处理合规文件保管和市场监管配合
- 授权代表不承担产品设计、开发、生产合规的主体责任
2.6 开源软件管理者义务（Articles 24–25）
CRA专门为开源软件设立了**专属管理者（Open-source software steward）**角色，对其要求相对宽松但仍有约束：
| 义务 | 要求 |
|---|---|
| 安全政策 | 须建立并文档化产品安全政策 |
| 漏洞处理 | 须有漏洞处理流程 |
| 协作配合 | 须配合市场监管 |
| 严重事件上报 | 涉及其托管平台的严重安全事件须上报 |
💡 商业化的开源软件（monetised）须按正常产品要求合规；纯公益性开源项目则适用开源管理者的轻量义务。
2.7 支持期（Support Period）规则（Article 13第8款）
支持期是CRA的核心创新之一，制造商须考虑以下因素确定合理支持期：
支持期确定原则：
├── 产品预期使用期限
├── 产品类别的通常使用年限
├── 安全更新的可用性
└── 最低要求：通常不少于5年
（除非预期使用寿命更短）
第三章：产品合规性（Conformity of the Product，Articles 27–34）
📌 本章核心：规定产品如何证明合规，包括合规评估路径、CE标志规则、EU符合性声明要求，以及附录I的基本网络安全要求。这是认证流程的直接操作指南。
3.1 附录I：基本网络安全要求（Essential Cybersecurity Requirements）
附录I分为两部分，是CRA的技术核心：
Part I — 产品安全属性要求（13项）
| 序号 | 要求 | 说明 |
|---|---|---|
| (a) | 无已知可利用漏洞上市 | 上市时不得存在已知可被利用的漏洞 |
| (b) | 安全默认配置 | 默认配置须安全，并可恢复出厂设置 |
| (c) | 安全更新机制 | 支持安全更新（默认自动更新，可选择退出） |
| (d) | 访问控制 | 防止未授权访问，支持身份认证/访问管理 |
| (e) | 数据保密性 | 加密存储/传输中的数据（技术最先进水平） |
| (f) | 数据完整性 | 防止数据/命令/配置被未授权篡改，报告损坏 |
| (g) | 数据最小化 | 仅处理产品预期功能所必需的数据 |
| (h) | 可用性保护 | 保护基本功能可用性，含DoS攻击防护 |
| (i) | 降低对外部影响 | 最小化产品对其他设备/网络服务可用性的负面影响 |
| (j) | 减少攻击面 | 设计上限制攻击面（含外部接口） |
| (k) | 漏洞利用缓解 | 采用适当技术降低安全事件影响 |
| (l) | 安全日志/监控 | 记录并监控数据访问/修改行为，用户可选择退出 |
| (m) | 安全数据清除 | 用户可安全、永久删除所有数据和设置 |
Part II — 漏洞处理流程要求（8项）
| 序号 | 要求 | 说明 |
|---|---|---|
| (1) | SBOM | 建立软件物料清单（机器可读格式，至少涵盖顶级依赖项） |
| (2) | 及时修复漏洞 | 无延迟地处理漏洞并提供安全更新；安全更新与功能更新分离 |
| (3) | 定期安全测试 | 对产品进行有效的定期安全测试和审查 |
| (4) | 漏洞信息披露 | 安全更新发布后，公开披露已修复漏洞的描述、严重性、影响和修复方法 |
| (5) | 协调漏洞披露政策（CVD） | 建立并执行协调漏洞披露政策 |
| (6) | 漏洞报告联系渠道 | 设立接收用户漏洞报告的联系地址 |
| (7) | 安全更新分发机制 | 提供安全的更新分发机制（适用时支持自动更新） |
| (8) | 免费及时发布安全更新 | 安全更新须免费（B2B定制产品除外）、无延迟发布，并附咨询消息 |
3.2 合规证明路径（Article 32）— 按产品类别选择路径
┌──────────────────────────────────────────────────────────────────┐
│ CRA 合规评估路径总览（按产品类别） │
├────────────────┬─────────────────────────────────────────────────┤
│ 产品类别 │ 可选合规路径 │
├────────────────┼─────────────────────────────────────────────────┤
│ 默认类产品 │ 路径A：制造商内部控制（模块A，自我声明） │
│（Default） │ 路径B：EU型式检验+内部生产控制（模块B+C） │
│ │ 路径C：全面质量保证（模块H） │
│ │ 路径D：欧洲网络安全认证方案（若适用） │
├────────────────┼─────────────────────────────────────────────────┤
│ 重要类 Class I │ 已充分应用谐调标准时：同默认类全部路径 │
│（Important I） │ 未完全应用谐调标准时：必须用路径B或C（NB介入） │
├────────────────┼─────────────────────────────────────────────────┤
│ 重要类 Class II│ 必须选用路径B、C或D（均需NB参与） │
│（Important II）│ │
├────────────────┼─────────────────────────────────────────────────┤
│ 关键类产品 │ 首选：欧洲网络安全证书（Article 8第1款） │
│（Critical） │ 备选：无证书方案时，采用Class II路径 │
└────────────────┴─────────────────────────────────────────────────┘
模块说明：
├── 模块A：制造商完全自我评估，无需第三方介入
├── 模块B：由NB进行EU型式审查（发放EU型式检验证书）
├── 模块C：基于B的结论，制造商自行声明批量产品合规
└── 模块H：制造商须通过NB认证的全面质量管理体系
3.3 符合性推定（Article 27）
通过以下方式可推定产品符合附录I要求（无需逐条单独验证）：
- 谐调标准（Harmonised Standards） — 欧委会委托欧洲标准化组织制定，引用后具有推定合规效力
- 通用技术规范（Common Specifications） — 欧委会在无谐调标准时通过实施法令发布
- 欧洲网络安全认证方案 — 根据欧盟网络安全法（EU 2019/881）发布的认证方案
💡 认证工程师提示：目前（截至2025年）CRA专属谐调标准仍在制定中，认证工程师应持续关注ETSI、CEN/CENELEC的标准动态。现阶段可参考EN 303 645（IoT消费类）等现有标准。
3.4 EU符合性声明（Article 28，Annex V）
EU DoC（EU Declaration of Conformity）必须包含以下内容：
| 必填项 | 说明 |
|---|---|
| 产品名称/型号/标识 | 可唯一识别产品的信息（含照片，若适用） |
| 制造商名称和地址 | 或授权代表的名称和地址 |
| 责任声明 | 声明合规责任由提供方独自承担 |
| 合规声明 | 声明产品符合相关欧盟法规 |
| 引用标准/规范 | 引用的谐调标准、通用规范或网络安全认证方案 |
| NB信息（若适用） | NB名称、编号、认证程序描述、证书编号 |
| 签署信息 | 地点、日期、姓名、职位、签名 |
若产品同时受多个欧盟法规约束，可出具一份统一的EU DoC，注明所有适用法规。
3.5 CE标志规则（Articles 29–30）
- CE标志须醒目、清晰、不可去除地标注在产品上
- 纯软件产品：可标注在EU DoC或官网上
- 不能直接标注在产品上时：标注在包装和EU DoC上
- CE标志后须跟随通报机构（NB）编号（适用于需要NB介入的产品）
3.6 对中小企业的特殊支持（Article 33）
| 支持措施 | 内容 |
|---|---|
| 专项培训 | 成员国须组织针对中小企业的CRA培训 |
| 专用沟通渠道 | 设立专门咨询渠道解答中小企业问题 |
| 监管沙盒 | 成员国可建立"网络韧性监管沙盒"供创新产品测试 |
| 简化技术文档格式 | 中小企业可使用欧委会统一的简化格式提交附录VII技术文档 |
| 降低评估费用 | NB须考虑中小企业需求，按比例减免评估费用 |
第四章：合规评估机构通报（Notification of Conformity Assessment Bodies，Articles 35–51）
📌 本章核心：规定谁可以成为通报机构（Notified Body，NB），以及各成员国如何对NB进行管理。对认证工程师的直接意义在于：了解NB的资质要求，有助于选择合适的认证机构。
4.1 通报机构（NB）体系概览
欧盟成员国政府
│
▼
通报机构管理局（Notifying Authority）
├── 负责评估、指定和监督NB
├── 无利益冲突
└── 通过NANDO系统向欧委会和其他成员国通报
│
▼
通报机构（Notified Body，NB）
├── 经成员国授权的第三方合规评估机构
├── 须满足Article 39规定的资质要求
└── 开展模块B、C、H评估，出具EU型式检验证书
4.2 NB必须满足的核心资质要求（Article 39）
| 要求类别 | 具体内容 |
|---|---|
| 法律地位 | 须是在成员国注册的法律实体 |
| 独立性 | 与被评估的经济运营主体无利益关系（独立性要求） |
| 专业能力 | 具备相关产品类别的评估知识和能力 |
| 人员资质 | 评估人员须具备：相关合规评估活动知识、附录I基本要求知识、谐调标准及通用规范知识、出具证书和报告的能力 |
| 公正性 | NB高层管理和评估人员的报酬不得与评估数量或结果挂钩 |
| 责任保险 | 须有相应责任保险（除非成员国法律规定由国家承担） |
| 保密义务 | 评估人员须对获取的信息保密（向本国市监机构披露除外） |
| 参与协调 | 须参与NB协调小组（Article 51）工作 |
4.3 NB的通报程序（Articles 42–43）
申请阶段
└── 向所在成员国通报机构管理局提交申请
├── 评估活动说明、程序、产品范围
└── 国家认可机构签发的认可证书（推荐但非强制）
评估阶段
└── 通报机构管理局审查申请材料
└── 核查是否满足Article 39要求
通报阶段
└── 通过NANDO系统正式通报欧委会和其他成员国
└── 通报内容包含：评估活动范围、认证程序、产品类型
生效阶段
└── 通报发布14天后（若无异议）NB正式生效
└── NB获得唯一标识编号
4.4 NB的运营义务（Article 47）
- 按Article 32和附录VIII规定的程序开展合规评估
- 评估须比例适当，避免对经济运营主体造成不必要负担
- 发现不符合时，不得签发合格证书，须要求制造商采取纠正措施
- 持续监控已认证产品；若发现不再合规，须暂停或撤回证书
- 须向通报机构管理局报告证书拒绝/限制/暂停/撤销情况
4.5 NB协调机制（Articles 50–51）
- 欧委会负责建立跨行业NB协调小组，确保各成员国NB之间的一致性
- 各成员国须确保本国NB参与协调小组工作
- NB之间须共享关于合规评估结果（尤其是否定结果）的信息
第五章：市场监督与执法（Market Surveillance and Enforcement，Articles 52–60）
📌 本章核心：规定欧盟成员国市场监管机构的职权和执法手段。认证工程师需了解：若产品被发现不合规，监管机构有哪些执法权力和产品可能面临的后果。
5.1 市场监督体系（Article 52）
欧盟委员会（European Commission）
│ 协调
▼
各成员国市场监督机构（MSA）
├── 负责CRA在本国市场的实施和执法
├── 须与CSIRT（网络安全事件响应团队）合作
├── 须与ENISA（欧盟网络安全局）合作
└── 须与其他领域MSA交换信息
ADCO（行政合作小组）
└── CRA专属的跨国MSA协调机制
5.2 市场监督机构的主要职权（Articles 53–57）
| 职权 | 内容 |
|---|---|
| 信息要求权 | 要求经济运营主体提供合规文件和信息 |
| 调查权 | 对产品开展符合性调查（可请求CSIRT/ENISA提供技术分析） |
| 纠正措施权 | 要求经济运营主体采取纠正措施 |
| 召回/下架权 | 强制要求将不合规产品从市场下架或召回 |
| 临时禁令权 | 对存在重大网络安全风险的产品发布临时禁售令 |
| 跨境协调权 | 非限于本国时通知欧委会和其他成员国 |
5.3 产品不合规的处置流程（Article 54）
MSA发现或怀疑产品不合规
│
▼
要求经济运营主体在合理期限内采取纠正措施
│
经营主体配合 ─────────────────────────→ 监控后续情况
│
未配合纠正
│
▼
MSA采取临时措施：
├── 禁止产品在本国继续销售
├── 要求从市场撤回
└── 要求召回
│
▼
通知欧委会和其他成员国
（含产品识别、不合规性质、风险、措施详情）
│
▼
其他成员国MSA跟进采取相应措施
5.4 显著网络安全风险的特殊处理（Article 54第2款）
当产品被认定存在显著网络安全风险时，MSA还须：
- 考虑非技术风险因素（包括供应链安全风险评估结果）
- 通知负责NIS2指令实施的主管机构并与之合作
💡 认证工程师提示："显著网络安全风险"的认定综合考量产品性质、受影响用户规模、漏洞严重程度等因素，认证工程师须协助客户在风险评估文件中充分论证。
5.5 ENISA的作用（Articles 58–59）
| 角色 | 职责 |
|---|---|
| 技术顾问 | 应MSA请求提供技术建议和分析 |
| 漏洞数据库 | 维护欧洲漏洞数据库（EUVD） |
| 协调者 | 协调CSIRTs与MSA的信息交流 |
| 标准制定 | 参与谐调标准制定咨询 |
| 报告者 | 每两年向欧盟机构报告CRA实施状况 |
第六章：授权与委员会程序（Articles 61–62）
📌 本章核心：规定欧委会的授权立法机制，说明CRA未来如何通过授权法规进行更新。
6.1 欧委会授权立法权力（Article 61）
欧委会获授权在以下方面发布委托法令（Delegated Acts），以补充和更新CRA：
| 授权事项 | 相关条款 |
|---|---|
| 限制或豁免某些产品的适用 | Article 2(5) |
| 修订附录III（重要产品）和附录IV（关键产品）列表 | Article 7(3) |
| 关键产品的强制网络安全认证要求 | Articles 8(1)(2) |
| 支持期的最低期限规定 | Article 13(8) |
| 漏洞报告义务的补充规定 | Article 14(9) |
| 开源软件自愿安全认证方案 | Article 25 |
| EU DoC最低内容要求的更新 | Article 28(5) |
💡 授权期为5年（自2024年12月10日起），可自动续期；欧洲议会或理事会可撤回授权。
第七章：保密与罚则（Confidentiality and Penalties，Articles 63–65）
📌 本章核心：规定信息保密要求和违规处罚标准。罚款规模是制造商重视CRA合规的重要驱动力。
7.1 保密义务（Article 63）
所有参与CRA执行的各方须对以下信息保密：
- 知识产权和商业机密（含源代码）
- 监察/调查/审计相关信息
- 公共和国家安全利益
- 刑事或行政诉讼完整性
7.2 行政罚款体系（Article 64）
CRA设立了三级行政罚款，按违规严重程度递减：
┌─────────────────────────────────────────────────────────────────┐
│ CRA 行政罚款等级表 │
├──────────────────────────────┬──────────────────────────────────┤
│ 违规类型 │ 最高罚款 │
├──────────────────────────────┼──────────────────────────────────┤
│ 一级（最严重）： │ 1500万欧元 或 │
│ • 违反附录I基本安全要求 │ 全球年营业额的 2.5% │
│ • 违反Article 13制造商义务 │ （取较高者） │
│ • 违反Article 14漏洞报告义务 │ │
├──────────────────────────────┼──────────────────────────────────┤
│ 二级： │ 1000万欧元 或 │
│ • 违反进口商/分销商义务 │ 全球年营业额的 2% │
│ • 违反技术文档/NB相关义务 │ （取较高者） │
│ • 违反CE标志/DoC相关义务 │ │
├──────────────────────────────┼──────────────────────────────────┤
│ 三级（最轻）： │ 500万欧元 或 │
│ • 向NB或MSA提供虚假/不完整信息 │ 全球年营业额的 1% │
│ │ （取较高者） │
└──────────────────────────────┴──────────────────────────────────┘
罚款豁免情形：
- 微型企业和小企业若仅违反Article 14漏洞报告时限要求，免除罚款
- 开源软件管理者不适用上述行政罚款
罚款考量因素：违规性质/严重性/持续时间、是否重复违规、企业规模和市场份额
第八章：过渡与最终条款（Transitional and Final Provisions，Articles 66–71）
📌 本章核心：关键时间节点，是认证工程师制定合规计划的直接参考。
8.1 CRA生效时间表（Article 71）— ⚠️ 最重要的实操信息
CRA关键时间节点（官方日历）
│
├─ 2024年11月20日 ─── CRA在欧盟官方期刊发布
│
├─ 2024年12月10日 ─── CRA正式生效（第20天），委托立法授权起算日
│
├─ 2025年12月11日 ─── 欧委会须发布漏洞报告授权法规
│
├─ 2026年6月11日 ─── 第四章（Articles 35-51，NB通报）正式适用
│ ⚠️ 成员国须在此前完成NB通报，避免认证瓶颈
│
├─ 2026年9月11日 ─── Article 14（漏洞上报义务）正式适用
│ ⚠️ 制造商须在此时间点前建立24h/72h响应机制
│
└─ 2027年12月11日 ─── CRA全面生效（绝大多数条款）
⚠️ 所有新上市数字产品须满足CRA全部要求
已上市产品无需补合规（除非经"重大修改"）
8.2 过渡期安排（Article 69）
| 情况 | 规则 |
|---|---|
| 2027年12月11日前已上市产品 | 无需补做CRA合规（豁免） |
| 2027年12月11日前已上市产品发生重大修改 | 须按CRA要求重新评估 |
| 其他法规已签发的EU型式检验证书 | 有效期延至2028年6月11日 |
| 漏洞报告义务（Article 14） | 所有产品均适用，含2027年前上市产品 |
📎 附录摘要
附录I：基本网络安全要求（已在第三章详述）
- Part I（13项）：产品安全属性要求（(a)至(m)）
- Part II（8项）：制造商漏洞处理流程要求
附录II：用户信息与使用说明（Annex II）
产品至少须附带以下信息：
| 序号 | 必须包含的内容 |
|---|---|
| 1 | 制造商名称、地址、邮件/网站联系方式 |
| 2 | 漏洞报告联系点（含CVD政策链接） |
| 3 | 产品名称/型号/唯一识别信息 |
| 4 | 预期用途、主要功能、安全属性说明 |
| 5 | 已知或可预见的网络安全风险说明 |
| 6 | EU DoC网址（如适用） |
| 7 | 技术支持类型及支持期终止日期 |
| 8 | 安全使用操作说明（初始设置、安全更新、数据清除、退役方法、关闭自动更新方法等） |
| 9 | SBOM获取方式（如制造商决定提供） |
附录VII：技术文档内容要求（Annex VII）
技术文档须包含以下8项：
| 序号 | 内容 |
|---|---|
| 1 | 产品总体描述（预期用途、软件版本、外观图纸/照片、用户说明） |
| 2 | 设计开发和漏洞处理流程描述（含架构图、SBOM、CVD政策、更新分发机制） |
| 3 | 网络安全风险评估（涵盖附录I Part I各项要求的适用性分析） |
| 4 | 支持期确定依据 |
| 5 | 适用标准/规范/认证方案列表（含未完全适用部分的替代方案说明） |
| 6 | 测试报告（验证符合附录I要求） |
| 7 | EU符合性声明（DoC）副本 |
| 8 | SBOM（应监管机构合理要求时提供） |
附录VIII：合规评估模块对比
| 模块 | 名称 | 是否需NB | 要点 |
|---|---|---|---|
| 模块A | 内部控制 | 否 | 制造商自我评估，保存技术文档和DoC≥10年 |
| 模块B | EU型式检验 | 是 | NB审核样品，发放EU型式检验证书 |
| 模块C | 基于EU型式的内部生产控制 | 否（依托B） | 制造商按模块B的型式声明批量产品合规 |
| 模块H | 全面质量保证 | 是 | 制造商实施经NB批准的全面QMS |
📊 认证工程师实操速查
快速判断产品合规路径
步骤一：产品是否具有数据连接功能（直接或间接）？
├── 否 → CRA不适用
└── 是 → 进入下一步
步骤二：是否属于豁免产品（医疗/航空/车辆/船舶）？
├── 是 → CRA不适用
└── 否 → 进入下一步
步骤三：查附录III，是否为重要产品（Important）？
├── 否 → 默认类 → 可选模块A（自我声明）
└── 是 → 确认Class（I或II）后进入下一步
步骤四（Class I）：是否完全应用了谐调标准？
├── 是 → 可选模块A/B+C/H/欧洲认证
└── 否 → 必须用模块B+C或模块H（NB必须介入）
步骤四（Class II）：必须选择 模块B+C / 模块H / 欧洲网络安全认证
步骤五：查附录IV，是否为关键产品（Critical）？
└── 是 → 须获取欧洲网络安全证书（或Class II路径）
关键合规文件清单
| 文件 | 谁来准备 | 最低保存年限 |
|---|---|---|
| 网络安全风险评估报告 | 制造商 | ≥10年（支持期内持续更新） |
| 技术文档（附录VII） | 制造商 | ≥10年 |
| EU符合性声明（附录V） | 制造商 | ≥10年 |
| SBOM软件物料清单 | 制造商 | 持续更新 |
| CVD漏洞披露政策 | 制造商 | 持续维护 |
| 漏洞处理记录 | 制造商 | 持续记录 |
| EU型式检验证书（模块B） | NB签发 | 按证书有效期 |
| 用户说明书（附录II） | 制造商 | ≥10年可获取 |