欧盟《网络弹性法案》（Cyber Resilience Act，CRA）已经生效。

2026 年 9 月 11 日报告义务将率先适用，要求所有销往欧盟市场的含数字元素产品制造商的漏洞与安全事件连续性强制报告义务。

对智能制造企业来说，影响往往落在那些容易被忽略的软件部分：固件、嵌入式系统、通信模组、移动 App、云端接口、第三方 SDK、开源组件，以及供应商交付的软件包。

产品进入欧盟市场后，企业需要能说明这些数字部分如何被设计、验证、维护和修复。

事项	关键含义
监管对象	投放欧盟市场的带有数字元素的硬件、软件及单独投放市场的组件
关键时间	2026 年 9 月 11 日报告义务先适用，2027 年 12 月 11 日主要义务全面适用
准备重点	产品分类、技术文档、漏洞处理、SBOM/SCA、供应商交付件和版本证据链

根据欧盟委员会公开说明：

2024年12月10日：CRA 正式生效，企业进入准备窗口期；

2026年9月11日起：漏洞与严重事件报告义务开始适用；

2027年12月11日起：主要网络安全要求、技术文档和符合性评估义务全面适用

换句话说，这不是一个等到 2027 年再集中准备的事项，报告义务会先一步到来。

01 CRA 要解决什么问题

欧盟官方对 CRA 的定位比较清楚。主要是解决以下两个问题：

1. 市场上大量硬件和软件产品网络安全水平不足；

2. 产品在售出之后缺少及时的安全更新和漏洞维护；

CRA 的监管思路，就是把产品安全责任前移并延长。

• 前移，是指产品在规划、设计、开发和生产阶段就要考虑基本网络安全要求；

• 延长，是指产品投放市场后，制造商还要在支持期内处理漏洞、提供安全更新，并在特定情形下履行报告义务；

这也是 CRA 与传统发布前测试的根本差异：

• 传统发布前，测试只能回答某个时间点是否发现问题

• 但是CRA 更关心的是，产品在整个生命周期中是否具备可证明的安全管理能力，包括风险评估、技术文档、符合性评估、漏洞处理、安全更新和事件报告。

02 CRA 的关键条款

企业理解 CRA 时，可以先抓住 3 个核心条款和 1 个关键附录。

条款或附件		关注点	对企业的实际要求
条款13		制造商义务	风险评估、技术文档、符合性评估、CE 标识、支持期和安全更新
条款14		报告义务	被主动利用漏洞和严重安全事件需要按时报告
条款25		FOSS 软件安全证明	选择自由和开源软件及第三方组件时，需要履行安全尽职调查
附录	Part Ⅰ	产品属性相关要求	默认安全、安全更新、访问控制、数据保护、可用性、攻击面收敛
	Part Ⅱ	漏洞处理要求	组件识别、SBOM、漏洞修复、CVD、补丁管理、安全更新发布

这几项加在一起，构成了 CRA 的基本监管逻辑：产品上市前要证明设计和开发过程满足网络安全要求，上市后要持续处理漏洞和安全更新。

03 哪些产品会被纳入CRA

CRA 的核心对象是投放到欧盟市场的带有数字元素的产品。按照欧盟委员会的实施 FAQ，这类产品包括硬件产品、软件产品，也包括单独投放市场的软件或硬件组件。

是否适用CRA范围，判断点如下：

判断点	对智能制造企业的含义
是否投放欧盟市场	内部自用系统通常不直接落入 CRA；对外销售、分销、交付到欧盟市场的产品需要评估
是否带有数字元素	网关、控制器、联网终端、边缘设备、App、设备管理软件、远程数据处理方案都可能涉及
是否存在数据连接	直接或间接连接设备、网络、云服务，都可能进入 CRA 视野

注：单纯 SaaS 通常不按产品处理；如果它是某个带数字元素产品不可缺少的远程数据处理能力，需要结合产品功能判断。

04 哪些情况不适用或适用较轻

CRA 的范围很广，但并不是所有数字产品都一概纳入。

为了避免大家把 CRA 误解成所有联网产品一律适用，在此同时说明排除范围：

• 未投放市场的产品不适用：未在商业活动中供应给欧盟市场的内部工具或内部系统，通常不属于 CRA 直接适用对象；

• 部分已有专门欧盟法规覆盖的产品被排除：医疗器械、体外诊断医疗器械、部分车辆、民航认证产品、船用设备等，需要结合具体产品和对应法规判断；

• 部分替换件和特殊用途产品不适用：同规格替换件、国家安全/国防用途、涉密信息处理用途产品存在排除情形；

• 自由和开源软件有特殊处理：商业活动中投放市场的自由和开源软件才会进入 CRA 范围；开源软件维护者适用更定制化的义务；

对制造商来说，集成开源组件不代表开源社区替企业承担责任。

产品以企业名义进入欧盟市场后，组件来源、漏洞影响和修复责任仍要由制造商解释。

05 制造商义务不是一次性的准入审批

CRA 对制造商的要求，不能理解成产品上市前做一次认证、拿到材料就结束。它更像一条产品安全责任链。

阶段	主要动作	常见证据
上市前	网络安全风险评估、基本要求映射、技术文档、符合性评估	风险评估记录、安全需求、测试验证、组件清单
上市时	欧盟符合性声明、CE 标识、用户说明、支持期说明	DoC、说明书、支持期结束时间、联系渠道
上市后	漏洞处理、安全更新、必要时报告被主动利用漏洞和严重事件	漏洞响应记录、补丁状态、客户通知、报告记录

06 产品分级与评估模型

欧盟委员会在符合性评估说明中提到，大多数普通产品可以由制造商进行自我评估；重要产品和关键产品的路径更严格，可能需要公告机构参与或适用欧盟网络安全认证方案。

产品层级	典型例子	符合性路径影响	评估模型
默认类别	普通联网设备、一般软件、普通组件	通常可采用内部控制程序进行自评	通常允许制造商自评（Module A），企业也可以选择更高等级路径
重要产品	操作系统、路由器、防火墙、网络管理、身份与访问管理类产品等	是否采用协调标准、通用规范或认证方案，会影响自评空间	class I：如果采用了协调标准、通用规范或适用的欧盟网络安全认证方案，可走自评；如果没有或只部分采用，通常要走 NB 第三方评估，常见是 Module B+C 或 Module Hclass II：一般需要更严格路径，通常是 Module B+C、Module H，或适用的欧盟网络安全认证方案
关键产品	安全元件、智能表计网关、高敏感安全基础组件等	通常需要更严格的第三方符合性评估或认证方案	第三方参与是强制的，未来如有适用的欧盟网络安全认证方案，应按认证方案；条件不满足时，再走类似 Class II 的 B+C / H 等路径

智能制造企业做 CRA 准备，第一步不只看产品是否适用，还要看产品可能落在哪个类别。分类结果会影响准备节奏、证据深度和第三方评估需求。

07 漏洞报告义务

很多企业只记住了 2027 年 12 月全面适用这个节点，但更早需要关注的是 2026 年 9 月 11 日。

自这一天起，制造商需要报告被主动利用的漏洞，以及影响带数字元素产品安全的严重事件。

欧盟委员会摘要还特别说明，报告义务适用于已经在欧盟市场供应的带数字元素产品，包括 2027 年 12 月 11 日前已经投放市场的产品。

根据欧盟委员会报告义务页面，制造商在知悉相关情况后，需要在 24 小时内提交早期预警，在 72 小时内提交完整通知。

针对被主动利用的漏洞，最终报告应不晚于纠正或缓解措施可用后 14 天提交；严重事件的最终报告则应在 72 小时提交后的一个月内完成。报告将通过 CRA 单一报告平台提交。

报告义务表面看是时限要求，实际考验影响面判断。

企业需要快速回答：

• 漏洞是否影响自己的产品？

• 影响哪些版本？

• 涉及哪些已出货设备？

• 是否有缓解措施？

• 是否需要安全更新？

• 是否触发报告和客户通知？

08 为什么智能制造企业压力更大

智能制造产品出货后，软件会跟随设备进入客户现场、工厂产线、渠道库存、海外仓和终端用户环境。

漏洞披露后，企业处理的不只是代码问题，还要判断设备批次、固件版本、模组供应商、OTA 能力、现场升级条件和售后通知范围，具体如下：

• 供应链长：芯片原厂、模组厂、ODM/OEM、第三方 SDK、开源社区和内部研发共同构成软件来源；

• 生命周期长：工业设备和智能硬件常常持续销售、部署和维护多年；

• 修复成本高：补丁发布涉及固件签名、兼容性验证、OTA 推送、客户现场环境和售后响应；

• 版本复杂：海外版本、渠道库存、客户定制版本容易造成影响面判断困难；

CRA 把研发、安全、供应链、质量、法务和售后之间分散的产品安全责任，拉到同一条合规链路上。

09 企业准备重点

对多数出海智能制造企业来说，CRA 准备可以先从四件事开始：

准备事项	要先回答的问题
识别产品范围	哪些硬件、软件、固件、App、组件和远程数据处理能力会随产品进入欧盟市场
梳理版本和组件	每个产品型号、固件版本、软件包、供应商交付件和开源组件能否对应起来
建立漏洞响应和报告流程	新漏洞出现后，谁判断影响面，谁确认修复方案，谁负责客户通知和监管报告
准备技术文档与责任边界	风险评估、测试验证、SBOM、支持期、安全更新、供应商责任和符合性路径是否有证据支撑

这四项并不是等到 2027 年才需要启动去做，尤其是 2026 年 9 月报告义务先适用，企业越早把产品、版本、组件、漏洞和客户交付状态串起来，后续越容易把 CRA 要求落到日常流程中。

10 SCA 和 SBOM 在 CRA 中的位置

从企业当前需要准备的重点工作来看，SCA和SBOM的功能非常明显，它是 CRA 落地中很关键的基础能力。

因为很多义务最终都需要回到产品中到底包含哪些软件成分、这些成分是否影响产品安全。

SCA 负责识别开源组件、第三方库、SDK、固件包、二进制依赖和版本关系。

SBOM 则把这些软件成分以标准化清单的方式表达出来，便于客户审查、漏洞影响判断和合规留痕。

它们的价值不是替代 CRA 合规，而是支撑制造商把产品安全责任讲清楚。

SBOM 临时导出一张表，难以支撑 CRA。持续更新、能对应具体产品版本和出货状态的软件成分数据，才有合规价值。

SCA 提供成分识别，SBOM 承接清单表达，漏洞影响面分析把清单转成响应能力。

11 四个容易误读的地方

误读	更准确的理解
CRA 到 2027 年再处理	报告义务 2026 年 9 月开始，符合性评估机构相关规定也已提前启动
CRA 主要是法务和认证部门的事	法务解释条款，认证推动流程，核心证据来自研发、产品、安全、供应链、质量和售后
硬件制造企业可以绕开 CRA	带数字元素并进入欧盟市场的硬件产品，同样需要评估适用范围
SBOM 是一份交付材料	CRA 场景下更需要持续、可追溯、能对应产品版本的 SBOM 和 SCA 数据

写在最后

CRA 的政策含义很清楚：欧盟正在把联网产品网络安全，从企业自律和客户要求，推进为市场准入和持续销售条件。

对出海智能制造企业来说，关键变化有三项：

带有数字元素的产品可能进入 CRA 视野；

制造商责任延伸到支持期内的漏洞处理和安全更新；

报告义务会倒逼企业把产品、版本、组件、供应商和客户交付状态关联起来。

真正难点不在读懂条文，而在把产品、版本、组件、供应商、漏洞响应流程串起来。

2026年6月17日，墨菲安全联合涂鸦智能、安克创新共同发布了《出海智能制造开源安全治理最佳实践》，包含全套治理框架、量化数据、KPI体系与实操清单，可以扫描下方二维码获取完整报告。

⚠️注：本文基于欧盟委员会、EUR-Lex、SCA/SBOM 厂商公开解读等资料做业务与安全视角解读，不构成法律意见。

具体适用边界、产品分类和合规路径，仍建议结合目标市场、产品形态与法律顾问意见进一步确认。