欧盟《网络弹性法案》（CRA）核心要求：适用范围、关键合规义务、时间线、与RED/CE标志的关系
欧盟《网络弹性法案》（Cyber Resilience Act, CRA）于2024年正式生效，是欧盟首部针对数字产品全生命周期的强制性网络安全立法。它不再依赖“自愿标准”或“事后补救”，而是将网络安全要求嵌入产品从设计、开发、生产到运维的每一个环节。对于硬件安全工程师和可信执行环境（TEE）设计者而言，CRA不仅是一份合规清单，更直接决定了产品架构、安全边界、漏洞响应机制和上市节奏。本章将系统拆解CRA的适用范围、关键合规义务、实施时间线，以及它与RED指令和CE标志之间的复杂关系。
2.1 适用范围：哪些产品必须纳入CRA合规体系
核心原理：数字产品全链条覆盖
CRA的适用范围远比传统RED（无线电设备指令）宽泛。它覆盖所有“带有数字元素的实体产品”（products with digital elements），包括硬件设备、独立软件（SaaS、本地应用）以及远程数据处理服务。这意味着，一个智能门锁、一个工业PLC、一个路由器固件、甚至一个手机App的后端云服务，只要其功能依赖数字组件且通过网络连接，就落入CRA管辖。CRA将产品分为“默认类别”（default category）和“重要类别”（important category），后者又细分为Class I和Class II，不同类别对应不同的符合性评估路径。
判断方法：三步定位法
- 第一步：确认是否属于“数字元素产品”——产品是否包含可编程电子组件（MCU/MPU/FPGA）或软件？是否具备网络连接能力（Wi-Fi、BLE、以太网、蜂窝、LoRa等）？若答案为是，则初步落入CRA范围。
- 第二步：检查是否被明确排除——医疗器械（MDR）、汽车（UNECE R155）、航空（EASA）、军工产品不在CRA范围内。但需注意：若产品是通用计算设备（如树莓派）但被用于医疗场景，CRA仍适用。
- 第三步：判断产品类别——根据CRA Annex III清单，判断产品是否属于“重要类别”。例如：智能家居中心、安全摄像头、路由器、防火墙、工业防火墙属于Class I；智能电网设备、医疗物联网网关、安全芯片（Secure Element）属于Class II。若不在清单中，则归为默认类别。
案例拆解：一款智能门锁的CRA适用性分析
假设某公司开发一款支持蓝牙和Wi-Fi的智能门锁，内置TEE用于存储密钥。该产品显然属于“数字元素产品”，且不在排除清单中。进一步对照Annex III，智能门锁属于“智能家居安全设备”，被列为Class I重要产品。因此，该产品需要：
- 满足ANNEX I Part I的安全设计要求（如安全启动、加密存储、最小权限）；
- 建立漏洞报告和处理机制（Part II）；
- 由第三方评估机构（Notified Body）进行符合性评估（因属于Class I）。
若该门锁仅支持蓝牙（无Wi-Fi），且不涉及远程管理，仍属于CRA范围，但可能因功能简单而降低评估复杂度。关键判断依据是“网络连接能力”和“安全功能重要性”，而非产品形态。
常见误区与总结
误区2：认为“仅硬件需要合规”。CRA明确覆盖“独立软件”和“远程数据处理”，例如一个智能门锁的云平台若存在漏洞，同样会被追责。
误区3：忽略“组件级”责任。CRA要求产品制造商对其使用的第三方组件（如开源库、RTOS）负责，需提供SBOM并确保组件无已知可利用漏洞。
2.2 关键合规义务：从设计到运维的完整闭环
核心原理：安全生命周期管理
CRA将合规义务分为三大板块：安全设计要求（ANNEX I Part I）、漏洞处理要求（ANNEX I Part II）、文档与报告义务。这三者不是孤立的，而是形成闭环：设计阶段的安全特性决定了产品抵御攻击的能力；漏洞处理机制确保产品上市后能持续应对新威胁；文档和报告义务则保障了透明度和可追溯性。
关键义务清单与硬件安全映射
| CRA义务条款 | 核心要求 | 硬件/TEE设计对应措施 |
|---|---|---|
| ANNEX I Part I (2)(a) | 安全默认配置 | TEE默认启用安全启动、禁用调试接口（JTAG/SWD） |
| ANNEX I Part I (2)(b) | 漏洞管理机制 | 硬件唯一ID + 安全日志记录，支持远程审计 |
| ANNEX I Part I (2)(c) | 数据保护（加密/最小化） | TEE内密钥管理、硬件加密引擎（AES/RSA/ECC） |
| ANNEX I Part I (2)(d) | 最小权限原则 | ARM TrustZone/ RISC-V PMP隔离，外设访问控制 |
| ANNEX I Part I (2)(e) | 完整性保护 | 安全启动链（Root of Trust）、固件签名验证 |
| ANNEX I Part I (2)(f) | 安全更新机制 | A/B分区 + 回滚保护 + 签名固件更新 |
| ANNEX I Part II (1) | 漏洞报告（24小时内通知ENISA） | 建立安全事件响应团队（PSIRT），硬件日志可追溯 |
| ANNEX I Part II (5) | SBOM（软件物料清单） | 硬件组件清单 + 固件依赖库版本记录 |
操作流程：建立CRA合规工程基线
- 威胁建模与安全需求分析——基于产品功能定义资产、攻击面、信任边界，输出安全需求规格书（SSRS）。
- 安全架构设计——确定TEE边界、密钥管理方案、安全启动链、更新机制。此阶段需输出硬件安全模块（HSM）选型报告。
- 开发与验证——实施安全编码规范，进行静态分析（SAST）、动态测试（DAST）、模糊测试（Fuzzing）。硬件层面需进行侧信道攻击评估（如DPA/SPA）。
- 漏洞管理流程建立——部署SBOM生成工具（如Syft、Trivy），建立漏洞披露政策（VDP），设置安全联系邮箱。
- 技术文档编制——撰写EU符合性声明（EU DoC）、技术文档（含设计原理、测试报告、风险评估）。
案例拆解：工业路由器漏洞响应流程
某工业路由器厂商在2026年3月收到安全研究员报告，其TEE中使用的加密库存在侧信道漏洞。该厂商的合规流程如下：
- 第1小时：确认漏洞真实性，评估影响范围（涉及3个产品线，约5万台设备）。
- 第24小时：向ENISA提交初步漏洞报告（CRA要求），同时通知受影响的客户。
- 第7天：发布固件更新（包含修复后的加密库），通过安全启动链签名，并推送至设备。
- 第30天：提交最终漏洞分析报告，更新SBOM，并在产品安全页公开披露。
该案例中，硬件设计的关键支撑是：TEE提供了安全存储（用于存放更新密钥）、安全启动（验证固件签名）、以及独立的信任根（防止攻击者篡改更新流程）。若无TEE，攻击者可能直接注入恶意固件，导致漏洞无法修复。
常见误区与总结
误区2：忽视“漏洞报告时限”。CRA要求“主动利用的漏洞”必须在24小时内报告ENISA，这需要企业具备7×24小时安全监控能力。
误区3：将SBOM视为“软件清单”。硬件组件（如芯片型号、固件版本、FPGA bitstream）同样需要记录在SBOM中。
2.3 实施时间线：关键节点与过渡期策略
核心原理：分阶段强制
CRA采用“渐进式”实施策略，给企业留出缓冲期，但缓冲期并不等于“等待期”。企业应利用过渡期完成差距分析、产品改造和合规预评估。
| 时间节点 | 里程碑事件 | 企业行动建议 |
|---|---|---|
| 2024年12月10日 | CRA正式生效（进入过渡期） | 启动合规差距分析，建立跨部门工作组 |
| 2025年6月 | 协调标准（Harmonised Standards）陆续发布 | 跟踪ENISA/ETSI标准动态，更新内部设计规范 |
| 2026年9月11日 | 漏洞报告义务开始适用（Part II） | 上线漏洞管理平台，完成PSIRT团队组建 |
| 2027年12月11日 | 全面强制实施（Part I + Part II） | 所有新产品必须带CE标志（含CRA要求） |
| 2028年12月11日 | 过渡期结束，旧产品需完成合规 | 对存量产品进行改造或停产规划 |
操作流程：过渡期合规路线图
- 2025年Q1-Q2：差距分析——对照CRA Annex I，逐项评估现有产品的安全设计、漏洞管理、文档体系。输出差距报告和整改优先级。
- 2025年Q3-Q4：设计整改——针对硬件安全短板（如缺少安全启动、调试接口未锁定），启动芯片选型或板级设计变更。此阶段需与TEE供应商（如ARM、Synopsys、RISC-V生态）确认安全特性支持情况。
- 2026年全年：试点验证——选择1-2款主力产品进行完整CRA合规试点，包括第三方评估、漏洞演练、SBOM生成。积累经验后推广至全产品线。
- 2027年：全面合规——确保所有新产品在上市前完成CRA评估，更新EU DoC，并在产品标签上标注CE标志。
案例拆解：中小型IoT厂商的过渡期决策
一家年出货量50万台的智能摄像头厂商，产品基于海思Hi3516方案，未启用TEE。面对CRA，其面临两个选择：
- 方案A：在现有平台上增加独立安全芯片（如ATECC608B），实现密钥存储和签名验证。成本增加约2美元/台，开发周期3个月。
- 方案B：更换为支持TrustZone的SoC（如瑞芯微RV1126），在TEE中运行安全应用。成本增加5美元/台，开发周期6个月，但安全能力更强。
该厂商最终选择方案A，因为其产品定位中低端市场，且CRA Class I评估允许“基于标准进行自我评估+公告机构抽查”。方案A虽无法提供完整TEE隔离，但通过安全芯片实现了“安全密钥存储”和“固件完整性验证”，满足CRA最低要求。此案例说明：CRA合规并非必须采用TEE，但TEE是满足高级别安全要求的最优路径。
常见误区与总结
误区2：忽视“存量产品”合规。CRA要求2028年后所有在售产品（包括已上市）必须合规，这意味着老产品可能需要硬件改造或停产。
误区3：低估标准制定的不确定性。协调标准可能延迟发布，企业应基于CRA法律文本本身进行合规设计，而非等待标准。
2.4 与RED指令和CE标志的关系：从并行到融合
核心原理：CRA作为特别法优先适用
RED（无线电设备指令2014/53/EU）第3(3)(d)(e)(f)条原本规定了网络安全要求，但CRA生效后，这些条款被CRA替代。具体而言：
- RED第3(3)(d)条（网络保护）——被CRA Annex I Part I覆盖；
- RED第3(3)(e)条（个人数据保护）——被CRA Annex I Part I(2)(c)覆盖；
- RED第3(3)(f)条（防欺诈）——被CRA Annex I Part I(2)(a)(b)覆盖。
这意味着，对于同时属于RED和CRA范围的产品（如Wi-Fi路由器、蓝牙耳机），制造商只需进行一次符合性评估，但需同时满足两套指令的其余要求（如RED的频谱效率、电磁兼容性）。
CE标志的叠加逻辑
CE标志是产品进入欧盟市场的“护照”。CRA并未创建新的标志，而是将CRA要求纳入现有CE标志体系。具体流程为：
- 产品满足所有适用指令（RED、EMC、LVD、CRA等）的要求；
- 编制EU符合性声明（EU DoC），列出所有适用指令；
- 在技术文档中附上CRA符合性评估报告（如为Class I/II，需公告机构参与）；
- 在产品标签、包装或随附文件上标注CE标志。
案例拆解：一款BLE信标的合规路径
某公司开发BLE信标（用于室内定位），该产品同时受RED和CRA管辖。其合规路径如下：
- RED要求：满足无线电频谱效率（ETSI EN 300 328）、电磁兼容（ETSI EN 301 489）、安全（IEC 62368-1）。
- CRA要求：因BLE信标属于“默认类别”（非重要类别），可进行自我评估。需满足ANNEX I Part I（如安全更新、最小权限）和Part II（漏洞报告）。
- CE标志：在EU DoC中同时引用RED和CRA，附上CRA技术文档（含SBOM、漏洞管理流程说明）。
该案例中，由于BLE信标功能简单（仅广播ID），CRA合规成本较低。但若信标支持OTA固件更新，则需确保更新机制的安全性（签名验证、回滚保护），这通常需要硬件支持（如安全启动）。
常见误区与总结
误区2：忽视“公告机构”的介入。对于Class I/II产品，必须选择有资质的公告机构（如TÜV、BSI、DNV），且评估周期可能长达3-6个月，需提前预约。
误区3：混淆“CE标志”与“CRA合规”。CE标志是结果，CRA合规是过程。即使产品已贴CE标志，若未满足CRA要求，仍可能被市场监管部门下架。
综上所述，CRA不是一次性的“认证考试”，而是一套持续运行的安全管理体系。硬件安全工程师需要将CRA要求转化为具体的设计约束：从芯片选型时的安全特性评估，到PCB设计时的调试接口保护，再到固件更新机制的签名验证。只有将CRA融入产品开发流程的每一个环节，才能在2027年全面强制实施时从容应对，同时真正提升产品的网络弹性。