大数跨境

欧盟《网络韧性法案》CRA 等级解读、合格评定选型路径与实施时间表

欧盟《网络韧性法案》CRA 等级解读、合格评定选型路径与实施时间表 ASPICE汽车软件开发流程学习基地
2026-09-21
13

REGULATION (EU) 2024/2847

欧盟《网络韧性法案》

CRA 等级解读、合格评定选型路径与实施时间

图1  覆盖软件、硬件、云与联网设备的产品安全生态(概念插图)

法规状态  正式法规;以EUR-Lex文本为准适用对象  拟在欧盟市场提供的带数字元素产品

信息时点  2026年9月21日文档用途  管理层、产品、工程、合规与供应链协同


一、先给结论:CRA的“等级”是合规路径分流,不是安全成熟度评分

CRA是一部直接适用于欧盟市场的产品网络安全法规。它要求制造商在产品设计、开发、投放市场、漏洞处理和维护的整个生命周期中满足附件I基本网络安全要求,并以技术文档、EU符合性声明与CE标志证明符合性。法规关注的是“带有数字元素的产品”能否以足够安全的方式进入欧盟市场,而不是对企业整体网络安全能力打分。 [1]

本材料把常见的“等级”表述整理为四条合规通道:默认类别、重要产品Class I、重要产品Class II与关键产品。分类的关键问题是整体产品的核心功能是否落入附件III或附件IV,并应结合实施条例(EU) 2025/2392的技术描述判断。即使落入默认类别,产品仍需满足附件I和制造商义务;差异主要体现在能否以内部控制完成合格评定,以及何时必须有公告机构参与。 [1] [3] [4]

管理层需要记住的三个日期。 2026年9月11日,第14条漏洞与严重事件报告义务已开始适用;2027年12月11日,CRA将全面适用;中间的标准、公告机构和认证机制仍在实施过程中,必须持续核验。

 

二、适用范围:先判断产品是否进入CRA,再讨论等级

Article 2(1)的起点是:产品是否在欧盟市场提供,以及其预期用途或合理可预见用途是否包括与设备或网络直接或间接的逻辑或物理数据连接。覆盖对象可以是硬件、软件、单独上市的组件及相关远程数据处理解决方案。实际筛查不能只看产品名称或是否“在线”,而应保留用途说明、连接方式、部署架构和商业提供方式的证据。 [1]

法规同时列出若干直接排除或可能的部门法规接口,例如部分医疗器械、体外诊断医疗器械、特定机动车相关产品、已依航空法规认证的产品及特定船用设备。对其他受部门法规覆盖的产品,只有在满足Article 2规定条件并由委员会采取相应法律行动时,CRA适用才可能被限制或排除。因此,行业法规并行适用的产品应当进行书面比对,而不是自行推定豁免。 [1]

判断边界的证据标准。 每个SKU、独立销售组件、软件版本和远程处理方案都应形成一条“范围结论卡”:市场提供方式、连接性、预期与合理可预见用途、排除项、关联部门法规、结论与复核日期。

 

三、等级解读:四类产品对应四种合规压力

类别

识别方式

评定与证明路径

使用时的关键提醒

默认类别

在范围内,但整体产品核心功能不符合附件III或IV的技术描述。委员会以移动应用、智能音箱、电脑游戏等作为示例。

制造商可采用内部控制(模块A)完成合格评定;仍须满足附件I、风险评估、技术文档、漏洞处理、EU DoC和CE。

“默认”不等于无监管要求。

重要产品 Class I

附件III Class I所列核心功能,例如身份/特权访问管理、浏览器、密码管理器、反恶意软件、VPN、网络管理、操作系统、路由器等。

若相关协调标准、共同规范或适格认证未被采用、仅部分采用或不存在,须走公告机构参与的路径;否则可按法规允许的路径证明符合性。

分类以核心功能为准,不是看产品是否包含此类组件。

重要产品 Class II

附件III Class II所列核心功能,例如hypervisor、容器运行时、防火墙、入侵检测/防御系统、抗篡改微处理器或微控制器。

须采用Article 32(3)所列第三方合格评定路径,即EU型式检验加生产控制或全面质量保证。

Class II不是Class I的“更高分”,而是独立列举的产品类别。

关键产品

附件IV所列核心功能,例如带security boxes的硬件、智能计量网关、特定高级安全/安全密码处理硬件、智能卡或secure elements。

原则上必须使用公告机构参与的评定;Article 8下是否需要欧洲网络安全证书,取决于后续授权法案和适用认证方案。

不要把尚未落地的认证设想当作当前必然条件。

 

重要产品与关键产品的具体技术边界不能只从附件名称或营销描述判断。实施条例(EU) 2025/2392已就附件III Class I/II及附件IV提供技术描述;分类材料应把产品功能、部署方式、可操控的安全能力和该实施条例逐项映射。 [1] [4]

四、选型路径:把法规判断变成可重复的产品决策

选型应采用“范围—核心功能—技术描述—标准覆盖—合格评定—上市证据”的顺序。这样既避免把集成组件误认作整机类别,也避免因为产品看似普通而跳过CRA基础义务。以下流程可作为产品立项、变更评审和上市放行的共同门槛。 [1] [3] [4]

步骤

需要回答的问题

应形成的证据

1. 范围与排除

是否在欧盟市场提供?用途是否包括直接或间接数据连接?是否有Article 2排除/限制?

范围结论卡与部门法规接口记录。

2. 核心功能

整体产品的核心功能是什么?不能仅以一个集成组件代替整机判断。

功能边界说明与架构证据。

3. 分类映射

核心功能是否符合Annex III/IV及(EU) 2025/2392技术描述?

分类档案、逐项映射与反例。

4. 证明基础

协调标准、共同规范或认证是否在法律上可用且覆盖相应附件I要求?

标准覆盖矩阵与法律状态快照。

5. 合格评定

应使用模块A、B+C、H还是适用的认证方案?是否须有公告机构参与?

评定计划与公告机构策略。

6. 上市证据

技术文档、EU DoC、CE、供应链与支持期资料是否已闭环?

上市放行包与版本化台账。

 

流程图的使用方式。 把“是否符合附件III/IV技术描述”作为需要产品、架构、安全与法规共同签字的节点。流程图输出的是拟定合规路径,不替代对具体技术事实、标准覆盖范围和适用法律行为的复核。

 

五、合格评定:先看产品类别,再看标准和认证的法律状态

Article 32给制造商列出四类证明程序:内部控制(模块A);EU型式检验(模块B)加基于EU型式的内部生产控制(模块C);全面质量保证(模块H);以及在可用并适用时的欧洲网络安全认证方案。对于默认类别,内部控制通常可用。对于重要产品Class I,是否必须引入公告机构取决于相关协调标准、共同规范或规定等级的欧洲网络安全认证是否被完整、正确地采用;对于Class II与关键产品,法规设置了更严格的第三方路径。 [1] [3]

协调标准并不是企业选择的任何ISO、IEC或行业标准。只有已经在《欧盟官方公报》引用的协调标准,才对其覆盖的附件I要求产生符合性推定。委员会在特定条件下可以设立共同规范,其作用也仅限于所覆盖的要求。标准化请求、工作草案、供应商认证或ENISA的技术研究都可能具有参考价值,但不能自动等同于CRA的符合性推定。 [1] [2]

动作

应解决的问题

最低留痕

步骤1:边界

核验范围、产品主体、上市模式、用途与连接性;检索Article 2排除/限制。

范围结论卡、法规接口清单。

步骤2:分类

识别整体产品核心功能;对照Annex III/IV与(EU) 2025/2392。

功能映射表、分类理由、反例说明。

步骤3:证据路径

核验每项附件I要求由何种协调标准、共同规范、认证或控制措施覆盖。

标准覆盖矩阵、适用法律状态快照。

步骤4:评定主体

按Article 32确认模块A、B+C或H;需要时预留公告机构。

评定计划、公告机构遴选与审查记录。

步骤5:上市放行

形成技术文档、EU DoC、CE标志和供应链信息。

上市放行包、版本与保存期限台账。

 

六、全生命周期义务:分类只决定评定深度,附件I和制造商义务贯穿始终

图3  CRA产品安全生命周期闭环

对所有范围内产品,Article 6要求产品满足附件I第一部分的基本网络安全要求,并要求制造商流程满足附件I第二部分。Article 13进一步要求制造商开展、记录和更新网络安全风险评估,并将风险评估结论用于产品规划、设计、开发、生产、交付和维护。技术文档应在上市前完成,并在支持期内持续更新。 [1]

·漏洞与组件:制造商应在支持期内有效处理产品及组件漏洞,并对整合的第三方组件开展尽职调查。 [1]

·支持期:原则上至少五年;若产品预期使用期少于五年,可对应预期使用期。安全更新应至少在十年或支持期结束前持续可获得,以较长者为准。 [1]

·上市文件:完成适用合格评定,签署EU符合性声明并加贴CE标志;技术文档和声明通常至少保存十年或至支持期结束,以较长者为准。 [1]

·供应链:进口商与分销商须核验相应的符合性要素;实质性修改后再次投放市场的主体,可能就受影响部分承担制造商义务。 [1]

七、报告义务与实施时间表:2026年已进入“事件报告先行”阶段

Article 14要求制造商报告被积极利用的漏洞和影响产品安全的严重事件。报告节奏包括最迟24小时的早期预警和最迟72小时的通知;漏洞的最终报告在纠正或缓解措施可用后最迟14日提交,严重事件最终报告在72小时通知后1个月内提交。委员会实施页面列出,报告义务自2026年9月11日起适用。 [1] [2]

图4  CRA实施节点:法规适用日与委员会实施计划

时间轴阅读提示。 2026年Q3、Q4以及2027年10月30日等为委员会实施页面公布的工作计划或交付节点,不应与法规的硬性适用日混淆。应把它们作为标准、认证和公告机构能力的持续监测点。

 

对于2027年12月11日前已投放市场的产品,Article 69设定了过渡安排;产品在该日期后发生实质性修改时,需要重新评估CRA要求。与此同时,第14条报告义务对范围内旧产品的处理另有规定。因此,“存量产品全部豁免”不是安全的结论,必须逐个产品、版本和修改情形分析。 [1]

八、建议的落地路线:以产品台账驱动证据链,而非以一次性审计驱动

在法规全面适用前,企业应把CRA纳入产品生命周期管理,而不是仅在上市前补一套文件。最有效的组织方式是建立可追溯的产品台账,并让产品、工程、PSIRT、采购、法务、质量与销售复用同一组事实:产品是什么、谁是制造商、如何连接、核心功能是什么、使用了哪些组件、支持到何时、是否发生实质性修改、由谁完成合格评定。

阶段

核心动作

可交付证据

0–30天

建立欧盟产品/SKU/版本清单;确定制造商、进口商、授权代表、分销商及远程处理方案。

范围结论卡、责任人矩阵、报告联络机制。

31–60天

完成第一轮核心功能与附件III/IV映射;核验技术描述和标准法律状态。

分类档案、标准覆盖矩阵、第三方评定缺口清单。

61–90天

将风险评估、漏洞处置、组件尽调、支持期、安全更新和报告时限嵌入研发与PSIRT流程。

技术文档目录、演练记录、SBOM/组件治理与更新策略。

持续运行

监测协调标准引用、共同规范、授权/实施法案、公告机构与认证方案;对实质性修改触发复评。

法规监测日志、变更控制记录、年度复审。

 

九、常见误读:四个应当避免的捷径

第一,不要将“默认类别”理解为“没有CRA义务”。默认类别仍须满足附件I、Article 13等制造商义务,并完成适用的合格评定、文档和CE流程。第二,不要仅因整机集成了浏览器、操作系统或防火墙组件就自动将整机归类为重要产品;法规强调核心功能判断。 [1] [3]

第三,不要把任意安全标准或供应商证书视为CRA的自动合规证明。符合性推定的前提是法律规定的标准、共同规范或认证条件。第四,不要将委员会实施页的计划节点当成法规的固定法律截止日;法规适用日期与实施计划的法律性质不同。 [1] [2]

本材料的边界。 它提供可复用的法规解读与选型框架。对于产品功能边界、部门法规接口、复杂软件供应链、实质性修改或认证方案适用性,应结合具体技术事实、最新欧盟官方公报和专业法律意见复核。

 

CRA解决方案微信:nalanqiguan 或扫描二维码 


【声明】内容源于网络
0
0
ASPICE汽车软件开发流程学习基地
Automotive SPICE是一个国际广泛使用的、评估和改进系统及软件开发过程的标准,也是由欧洲主要汽车制造商共同制定的面向汽车行业的流程评估模型。ASPICE3.1能力级别分为0到5级,其中HIS PROCESSES 包括16个过程。
内容 95
粉丝 0
ASPICE汽车软件开发流程学习基地 Automotive SPICE是一个国际广泛使用的、评估和改进系统及软件开发过程的标准,也是由欧洲主要汽车制造商共同制定的面向汽车行业的流程评估模型。ASPICE3.1能力级别分为0到5级,其中HIS PROCESSES 包括16个过程。
总阅读3.5k
粉丝0
内容95