网络信息安全系列: 欧盟网络弹性法案CRA深度解析与合规指南

潜在案列：一家智能门锁制造商收到欧盟大客户邮件——“2027年12月后，无CRA合规证明的产品将不再纳入采购清单”。研发总监连夜翻查法条，发现产品里还躺着admin/123456的默认密码，调试用的UART接口裸露在生产固件中，连SBOM是什么都需要现查。

如果你的产品带芯片、带固件、能直接或间接联网，并以商业目的进入欧盟市场——CRA不是“建议”也不是“认证加分项”，而是CE框架下的强制性准入门槛。

本文将从法规原文出发，把条文、实施条例、企业落地路径拆开讲清楚：

• CRA的立法定位与关键时间轴——2026年9月就要动手

• PDE的定义与适用/豁免边界——别踩“我以为不算”的坑

• 产品分级模型——Default / Important Class I/II / Critical 的判定依据

• Annex I的21项技术要求——翻译成工程语言

• 合规路径——Module A自我评估 vs 第三方认证，预算差异有多大

• 可立即执行的行动清单——从今天到2027年12月

适用读者：硬件/嵌入式产品经理、研发总监、合规负责人、系统架构师 适用场景：产品出口欧盟的合规评估、新品立项的安全需求定义、现有产品的合规改造 版本说明：基于Regulation (EU) 2024/2847及Implementing Regulation (EU) 2025/2392，2026年6月整理

摘要

欧盟《网络弹性法案》（Cyber Resilience Act, CRA；正式编号 Regulation (EU) 2024/2847）是全球首部针对带数字元素产品（Products with Digital Elements, PDE）的强制性横向网络安全法规。它把“安全”从企业自选动作，变成产品进入欧盟市场的准入条件——制造商必须在设计阶段就落实安全（Secure by Design/Default），并在产品整个支持周期内提供安全更新、漏洞管理与透明披露；合规后以CE标志证明符合CRA要求。

法规关键日期：

• 2024-11-20：刊登于欧盟官方公报（OJ）

• 2024-12-10：法规正式生效

• 2026-06-11：合格评估机构（Notified Body）相关规则生效

• 2026-09-11：漏洞与安全事件上报义务启动（24h预警/72h详情）

• 2027-12-11：主要义务全面强制实施

核心结论：CRA的本质是“将网络安全变成可审计、可追责、可撤回的法律要件”。合规起点不是找认证机构，而是先完成产品分级判定（Classification Rationale）——最为有效。

第一章：CRA立法定位

1.1 从碎片化到统一规则：CRA填补了什么空白？

过去十年，欧盟对网络安全的监管走了一条清晰的路径：

CRA的定位是横向的“产品侧”安全底线。它不关心你的公司有没有安全部门，而关心：

• 产品出厂时有没有后门级默认密码？

• 能不能打补丁？补丁签名校验了吗？

• 漏洞被发现后，你怎么处理、多长时间响应？

• 有没有留下可追溯的证据？

🔑 一句话定性：CRA把“安全”从市场营销话术，变成了欧盟海关和法律可执行的义务。

1.2 法规定位三句话

CRA与NIS2、GDPR的关系是互补而非替代：

三者叠加，构成了欧盟数字安全的完整拼图。CRA管的是“产品侧”，不替NIS2管组织，不替GDPR管个人数据。

第二章：PDE的定义与适用边界——先画清楚“管什么、不管什么”

2.1 法定口径：什么是PDE？

根据CRA Article 3(1)，“带数字元素的产品”（PDE）定义为：

“软件或硬件产品及其远程数据处理解决方案，包括单独投放市场的软件或硬件组件。”

落入CRA管辖需同时满足三条：

典型命中清单：

2.2 法定豁免——不要自己脑补，按法条走

根据CRA Article 2(2)-(7)，以下不在CRA产品管辖范围内：

⚠️ 重要踩坑提示：

2.3 适用/豁免决策树

产品是否以商业活动提供？
├── NO → 不在CRA管辖范围（如个人DIY非营利分发）
└── YES → 是否包含软件/固件/硬件数字元素？
├── NO → 不在CRA管辖范围（纯机械产品）
└── YES → 是否能直接或间接连接设备/网络？
├── NO → 不在CRA管辖范围
└── YES → 是否在法定豁免清单（MDR/机动车/航空/国防等）？
├── YES → 适用专属法规，CRA通常不适用
└── NO → ✅ 落入CRA管辖，进入分级判定

第三章：关键时间轴——2026年9月就要动手

🔑 关键判断：2026年9月是第一个会“流血”的节点——不是罚款上限，而是监管会发现你连流程都没有。已上市产品不受追溯，但若发生实质性修改（substantial modification）则需重新合规。

第四章：产品分级模型——这决定了你的预算和路径

CRA的工程化核心是风险分级：不是所有产品都走昂贵第三方认证。分级依据在Annex III（Important） 和Annex IV（Critical），并由Implementing Regulation (EU) 2025/2392给出技术描述（定义什么叫操作系统、防火墙、安全元件等）。

4.1 四层模型

4.2 重要/关键产品的技术描述（Implementing Regulation (EU) 2025/2392）

欧盟委员会已通过实施条例(EU) 2025/2392，为Annex III/IV的产品类别提供了功能性和技术性定义。这意味着：

• 不能按行业“拍脑袋”：不是说“我是工控设备所以我自动重要”。CRA看的是产品功能是否落在Annex III/IV的技术描述里。

• 一台普通工业网关很可能落在Important Class I/II周边

• 一台PLC若具备安全功能/关键控制能力，会接近Class II或Critical周边

• 但“工控外壳里的普通触摸屏HMI”未必自动Critical——关键在于它管什么、出事后果多严重

4.3 工程建议：先做分类裁定表（Classification Rationale）

建议为每个SKU制作一张Classification Rationale，写清楚：

这页纸是你应对公告机构、海关质疑、客户审厂时最有用的东西。

第五章：CRA到底要求你“做哪些事”——Annex I翻译成工程语言

CRA的技术要求集中在Annex I，分为Part I（设计开发期，约13项）和Part II（上市后漏洞处理，约8项）。

5.1 Part I — 设计与开发安全属性

5.2 Part II — 上市后漏洞处理义务（强制性要求）

2026年9月11日是一个关键的截止日期，要求产品制造商、分销商和系统集成商遵守第14条“制造商的报告义务”，即应将产品中任何被主动利用的漏洞以及对产品安全产生影响的重大事件通知指定的CSIRT。

⚠️ 风险提示：如果产品里还有admin/123456或Telnet开在默认端口且无鉴权加固计划——不要在2026年9月前让产品出现在欧盟监管雷达上，否则“漏洞上报义务”会第一时间把你的现状变成官方记录。

第六章：合规路径怎么走——Module A vs 第三方

6.1 四条评定路径

CRA Article 32认可四种符合性评定方式：

6.2 决策图

你的产品 ∈ Annex III/IV？
├── NO → Default → Module A（自我评估）
│ 1) 风险评估 + 威胁模型
│ 2) 安全测试（SAST/DAST/固件扫描）
│ 3) SBOM + 更新证明 + 维护期声明
│ 4) 技术文档（Technical File）
│ 5) 签EU DoC → 贴CE
│
├── YES → Important Class I
│ ├── 有协调标准/通用规范覆盖？→ 可Module A[citation:9]
│ └── 无标准覆盖？→ 必须Module B+C或H
│
└── YES → Important Class II / Critical
→ 必须第三方（Module B+C或H）
→ 关键类可能走EUCC认证[citation:3]

6.3 预算现实影响

💡 工程建议：找欧盟公告机构（如TÜV、SGS等）排队需要时间，建议Class II/Critical产品现在就开始接触，进行预评估。

第七章：制造商核心合规动作

通用安全要求

• 风险评估：确保产品满足CRA的基本要求（essential requirements）。

• 安全设计 (Secure by Design)：没有已知的可利用漏洞、默认安全配置、最小攻击面、定期更新等。

• 自我宣称：企业需要做到产品漏洞管理和披露相关的自我宣称。

• 

漏洞管理与用户文档

• 组件识别：维护软件物料清单（SBOM）。

• 漏洞公开与分析：建立VDP（漏洞披露政策）和SRC（安全响应中心）。

• 用户文档：必须包含组件说明、维护周期、安全配置指南。

• 

可以按如下步骤执行

Phase 0 — 判定（1-2周）

• 逐SKU判定：PDE？豁免？落在Annex几？产出Classification Rationale

• 梳理哪些SKU会触发第三方评定

Phase 1 — 止血（立刻）

• 清默认密码、关无用服务、加固调试接口（UART/JTAG生产要锁或签名校验）

• 建立security@yourdomain接收通道 + 初版CVD政策

• 盘点开源组件 → 建初步SBOM（CycloneDX或SPDX）

Phase 2 — 文件化（2025年内）

• 威胁模型（STRIDE或等价）

• 安全测试证据包：SAST报告、固件漏洞扫描、接口渗透测试概要

• 更新机制审计：签名校验、回滚保护、降级阻断

• 技术文档按Annex I逐项对应章节

Phase 3 — 体系化（赶2026年9月前）

• PSIRT流程（工单/优先级/SLA/责任人）

• 上报演练：知道往哪个平台/格式报、哪些字段必填

• 欧盟授权代表（AR）签约（非EU制造商必须）

• Class II/Critical：启动公告机构预沟通

第八章：CRA与NIS2/GDPR/RED的关系——别混为一谈

第九章：总结与适用边界

9.1 核心结论

9.2 适用边界

9.3 最后三句话

附录：参考标准与法规原文