附录 I 在哪里落地 —— 以及 OEM 必须长期承担的五项责任
许多 IoT OEM 已经具备安全启动、加密通信、OTA 更新以及访问控制等安全能力。但欧盟《网络韧性法案》（CRA）改变了这些能力的运营含义。
在 CRA 框架下，网络安全不再只是产品功能，而成为与 CE 标志直接绑定的长期制造商责任。承担责任的是 OEM 本身，而不是芯片厂商、云服务提供商或代工厂。
自 2026 年 9 月 11 日起，CRA 第 14 条所规定的 24 小时漏洞预警窗口将不再只是内部 SLA，而成为法律义务。自 2027 年 12 月 11 日起，不满足 附录 I 要求的产品将无法满足 CRA 合规要求并进入欧盟市场。
CRA 将产品网络安全责任明确归属于 CE 标志持有人。对于严重违规行为，最高可处以 1500 万欧元罚款，或上一财年全球营业额的 2.5%，以较高者为准。
本文重点从工程与运营视角解释：
许多组织虽然已经具备较成熟的固件安全能力，但关键安全流程仍然依赖人工或弱治理方式运行。常见情况包括：
在 CRA 出现之前，这些通常被视为内部运营问题。而在 CRA 框架下，它们将直接变成制造商责任。
CRA 第 14 条的漏洞上报义务，以及 附录 VII 的文档要求，使得可追溯性、责任归属以及可重复执行的运营控制能力，在量产规模下变得越来越重要。
CRA 的要求通常可以分为两类：
下面的章节将进一步说明这些要求在运营层面的实际含义。
上面的表格解释了 附录 I 的要求落在哪里。下面则说明这些要求在运营上的真实含义 —— 一个主要在平台选型阶段决定，另外四项则需要在整个产品生命周期中持续运营。
硬件安全是整个体系的基础。软件无法弥补芯片本身不具备的安全能力。在确定 SoC 或 MCU 平台之前，OEM 应重点确认以下能力。
由不可变 Boot ROM 与硬件随机数生成器（TRNG）构成的隔离安全执行环境。缺少这一基础时，完整性能力将更多依赖软件假设，难以长期建立可信性。
私钥、设备身份与 OTA 解密密钥存储在安全边界内部，例如 Secure Element、TrustZone 或基于 PUF 的存储。随着设备价值与攻击价值提升，仅依赖通用 MCU 的软件级密钥保护将越来越难以防御。
支持 AES、ECC（P-256/P-384）与 SHA-256/384 的硬件加速。一旦 TLS 或消息签名进入生产数据路径，仅依赖软件密码算法将带来明显的性能与功耗开销。
基于不可变安全存储的 Challenge-Response 调试认证，以及启动阶段强制执行的防回滚机制。用于防止已修复漏洞的旧固件被重新刷入设备。
对于采用 HSM 签名治理的 OEM，工具链应支持私钥始终保留在硬件安全边界内，包括：
密钥与设备证书贯穿整个产品生命周期。如果密钥泄露，无论底层芯片或固件多么安全，整体安全模型都会失效。多数 IoT OEM 在生命周期中都会管理多类密码资产。
用于在执行前验证固件与 OTA 更新真实性。
用于签发与管理设备证书及信任链。
用于保护 OTA 更新包在传输过程中的安全。
用于制造返修、售后服务与故障分析中的调试授权。这些资产通常通过四类基础设施统一管理：
CRA 并未明确要求 HSM 或审批流。但CRA 第 14 条的漏洞上报要求，以及 附录 VII 的文档义务，使得缺乏可追溯性与治理能力的运营模式越来越难以支撑。每类密钥都应具备：
设备级可追溯性 —— 即知道每一台设备上部署了哪些固件、密钥与证书 —— 虽然并未被 CRA 明确规定，但在量产规模下，实际上已经成为执行 CRA 第 14 条与 附录 VII 要求的基础能力。
一旦发现产品存在正在被利用的漏洞，CRA 第 14 条的上报时钟就会立即开始计时。OEM 必须能够快速识别：
核心运营能力通常包括以下内容。
基于 SPDX 或 CycloneDX 等机器可读格式，在每次构建时自动生成并长期保留。
持续跟踪：
许多芯片层漏洞通常会首先出现在厂商 PSIRT 渠道中。
公开漏洞提交渠道，以及内部漏洞分级与响应流程。
明确以下责任归属：
提交 24 小时预警只是开始。真正更难的部分，是将修复可靠地交付到已部署设备上 —— 对多数 IoT 产品而言，这意味着 OTA。
CRA 并未明确要求 OTA 能力。但对于大多数联网 IoT 产品而言，依赖人工方式进行现场修复，在量产规模下并不现实。因此，OTA 实际上会成为执行 CRA 生命周期责任的核心运营机制。OTA 系统通常需要承担：
许多 OTA 系统最初是为功能发布而设计，而不是为合规驱动的安全修复而设计。安全修复通常会引入更多运营要求：
CRA 的文档要求远远超出产品发布阶段。欧盟市场监管机构有权在产品最后一次进入欧盟市场后的十年内，要求提供完整的合规文档。
典型 附录 VII 文档包括：
对于许多 OEM 而言，文档保留将变成长期运营系统，而不再只是发布阶段的一次性交付。跨多个产品代际维护可追溯的历史记录，往往会变成组织与基础设施挑战，而不仅仅是固件问题。
现代 SoC 与参考设计已经越来越多地提供硬件安全基础能力。大多数 IoT OEM 也已经具备 OTA 与发布文档流程。但对许多团队而言，最大的缺口通常仍然是：
CRA 最终改变的，不只是产品需要具备哪些安全功能。它更改变了 OEM 必须长期运营哪些安全能力。
