NEWVenvera 支持您的语言: 完整平台支持英语、德语、西班牙语、保加利亚语、阿拉伯语和简体中文。查看新功能 →
欧盟《网络弹性法案》(CRA)要求详解
合规指南

欧盟《网络弹性法案》(CRA)要求详解

·Alexander Sverdlov

欧盟《网络弹性法案》(CRA)的要求分布在 Regulation (EU) 2024/2847 的三个部分。附件 I 规定了基本网络安全要求:每一款具有数字元素的产品都必须具备的 13 项安全属性(第 I 部分),以及在产品获得支持的整个期间内制造商必须持续执行的 8 项漏洞处理义务(第 II 部分)。第 13 条将这些要求转化为制造商的义务:形成文件的风险评估、至少五年的支持期、技术文档、合格评定、欧盟符合性声明以及 CE 标志。第 14 条增加了报告义务:对于被积极利用的漏洞或严重事件,必须在 24 小时内以早期预警的形式报告给指定的 CSIRT 和 ENISA。

时间节点已不再停留在理论层面。第 14 条自 2026 年 9 月 11 日起适用,第 69(3) 条还将其延伸适用于在该条例其余部分适用之前已投放市场的产品。其他所有内容,包括附件 I、合格评定和 CE 标志,均自 2027 年 12 月 11 日起适用。

要求所在位置具体内容适用日期
产品安全属性附件 I 第 I 部分13 项属性,从发布时不存在已知的可利用漏洞,到安全删除数据。2027 年 12 月 11 日
漏洞处理附件 I 第 II 部分8 项义务,包括软件物料清单(SBOM)、定期安全测试、协调披露以及免费安全更新。2027 年 12 月 11 日
风险评估第 13(2) 条和第 13(3) 条形成文件的网络安全风险评估,用于指导设计,并在整个支持期内持续更新。2027 年 12 月 11 日
支持期第 13(8) 条至少五年;如果产品的使用时间更短,则为预期使用时间。2027 年 12 月 11 日
技术文件和 CE 标志第 13(12)、28、30、31、32 条技术文档、合格评定、欧盟符合性声明和 CE 标志。2027 年 12 月 11 日
报告第 14 条通过单一报告平台提交 24 小时早期预警、72 小时通知和最终报告。2026 年 9 月 11 日
用数字看 CRA 要求:附件 I 第 I 部分的 13 项产品属性、第 II 部分的 8 项漏洞处理义务、至少五年的支持期,以及技术文件十年的保存期

附件 I 第 I 部分规定了哪些基本网络安全要求?

第 I 部分开篇规定了一项总体原则:产品的设计、开发和生产必须基于风险,确保适当的网络安全水平。随后,第 (2) 点列出了 13 项属性,每一项都应以制造商的风险评估为基础,并在适用时实施。概括而言,产品必须:

要点产品必须
(a)在提供时不存在已知的可利用漏洞。
(b)以默认安全的配置交付,并可将其重置为原始状态。
(c)允许通过安全更新修复漏洞,在适用情况下默认开启自动更新,并提供明确的退出选项。
(d)通过认证、身份或访问管理机制防止未经授权的访问,并报告可能发生的未经授权访问。
(e)保护数据的机密性,例如对静态数据和传输中的数据进行加密。
(f)保护数据、命令、程序和配置的完整性,并报告损坏情况。
(g)仅处理其预期用途所需的数据。
(h)保护基本功能的可用性,包括抵御拒绝服务攻击的韧性。
(i)尽量减少自身对其他设备或网络造成的负面影响。
(j)限制攻击面,包括外部接口。
(k)通过漏洞利用缓解机制降低事件的影响。
(l)记录并监控相关的内部活动,并允许用户选择退出。
(m)让用户能够安全、永久地删除所有数据和设置。

“以网络安全风险评估为基础”这一措辞很关键。第 13(3) 条要求风险评估说明第 I 部分第 (2) 点中的每一项是否适用以及如何实施,第 13(4) 条则要求在技术文档中为任何不适用的基本要求提供明确的理由。跳过某一项是允许的。不加说明地跳过则不允许。

附件 I 第 II 部分对漏洞处理有哪些要求?

第 II 部分是一组流程,而不是产品属性,大多数制造商真正的工作量都集中在这里。制造商必须:

要点制造商必须
(1)识别并记录漏洞和组件,包括以常用的机器可读格式编制、至少涵盖顶层依赖项的软件物料清单。
(2)毫不延迟地处理和修复漏洞,并在技术可行的情况下,将安全更新与功能更新分开发布。
(3)对产品的安全性进行有效且定期的测试和审查。
(4)在更新可用后公开披露已修复漏洞的信息;仅在有充分正当理由的情况下,才可在有限范围内推迟披露。
(5)制定并执行协调漏洞披露策略。
(6)促进漏洞信息的共享,包括提供用于报告漏洞的联系地址。
(7)提供安全分发更新的机制;对于安全更新,在适用情况下自动分发。
(8)毫不延迟地免费发布安全更新,并附带安全公告信息,除非就定制产品与企业用户另有约定。

第 13(8) 条将第 II 部分与支持期挂钩:在整个支持期内,都必须按照第 II 部分处理漏洞。第 13(9) 条进一步规定,支持期内发布的每一项安全更新,都必须在至少 10 年或支持期的剩余时间内保持可用,以较长者为准。

Venvera 中的欧盟《网络弹性法案》(CRA)控制措施页面,按治理、风险评估和安全开发分组列出 CRA-1 至 CRA-24 控制措施,并显示实施状态和覆盖范围

制造商根据第 13 条必须做什么?

第 13 条共有 25 款。其中产生大部分工作量的是以下几款。

形成文件的风险评估

第 13(2) 条和第 13(3) 条要求对网络安全风险进行评估,评估须贯穿规划、设计、开发、生产、交付和维护各个阶段,形成文件,并在支持期内持续更新。该评估须纳入技术文档。

对组件开展尽职调查

第 13(5) 条要求在集成第三方组件(包括自由和开源组件)时开展尽职调查。第 13(6) 条要求制造商将其在某个组件中发现的漏洞,报告给该组件的维护者。

设定支持期,并告知其结束时间

第 13(8) 条将支持期设定为至少五年,除非产品的预期使用时间更短,在这种情况下,支持期与预期使用时间一致。第 13(19) 条要求在购买时明确告知结束日期,至少精确到年和月。

文档、合格评定和 CE 标志

在将产品投放市场之前,第 13(12) 条要求完成第 31 条规定的技术文档、第 32 条规定的合格评定、第 28 条规定的欧盟符合性声明以及第 30 条规定的 CE 标志。第 13(13) 条要求将技术文档和符合性声明保存至少 10 年或整个支持期,以较长者为准。

单一联络点

第 13(17) 条要求设立单一联络点,让用户能够直接报告漏洞,且该联络点不能仅限于自动化工具。

欧盟《网络弹性法案》(CRA)规定的制造商核心义务:风险评估、附件 I 第 I 和第 II 部分、第 31 条规定的技术文件、第 32 条规定的合格评定以及第 14 条规定的报告

适用哪种合格评定路径?

第 32 条按产品类别规定了评定路径,我们的指南 CRA 的适用范围对此有详细说明。默认类产品可以采用内部控制(模块 A)。附件 III 中的 I 类重要产品也可以采用模块 A,但前提是制造商完整适用了协调标准、通用规范,或保证级别至少为“实质级”的认证方案。否则,这类产品需要采用欧盟型式检验(模块 B 加模块 C)或全面质量保证(模块 H)。II 类重要产品必须采用模块 B 加模块 C、模块 H,或保证级别至少为“实质级”的认证方案。附件 IV 中的关键产品,在第 8(1) 条有要求时须采用欧洲网络安全认证方案,否则采用 II 类产品的评定路径。

第 14 条的报告要求是什么?

第 14 条有两种触发情形,两者的前两个时限相同。两类报告都须通过第 16 条规定的单一报告平台,同时提交给被指定为协调者的 CSIRT 和 ENISA。欧盟委员会表示,ENISA 的平台自 2026 年 9 月 11 日起已投入运行。

阶段被积极利用的漏洞影响产品安全的严重事件
早期预警知悉后 24 小时内,Art. 14(2)(a)知悉后 24 小时内,Art. 14(4)(a)
通知知悉后 72 小时内,Art. 14(2)(b)知悉后 72 小时内,Art. 14(4)(b)
最终报告纠正或缓解措施可用后最迟 14 天内,Art. 14(2)(c)事件通知后一个月内,Art. 14(4)(c)

第 14(5) 条对严重事件作出了定义:指影响或可能影响产品保护敏感或重要数据或功能的可用性、真实性、完整性或机密性的能力的事件,或者导致或可能导致恶意代码进入产品或用户系统的事件。第 14(8) 条还规定了一项义务:将漏洞或事件以及用户可以采取的应对措施告知受影响的用户,并在适当情况下告知所有用户。

针对被积极利用漏洞的第 14 条报告时限:24 小时内发出早期预警,72 小时内提交通知,修复方案可用后 14 天内提交最终报告

进口商和分销商需要做什么?

根据第 19 条,进口商只有在产品符合附件 I 的情况下,才能将其投放市场。在此之前,进口商必须确保制造商已开展合格评定、编制了技术文档、加贴了 CE 标志,并提供了符合性声明和用户信息。根据第 20 条,分销商必须尽到应有的谨慎,在提供产品之前核实 CE 标志和所需文件。

第 21 条是一个陷阱:以自己的名称或商标将产品投放市场,或对产品进行实质性修改的进口商或分销商,将被视为制造商,须全面承担第 13 条和第 14 条规定的义务。谁属于哪种角色,请参阅我们的指南谁必须遵守 CRA。

CRA 规定的经济运营者义务:制造商适用第 13 条和第 14 条,进口商适用第 19 条,分销商适用第 20 条,以自有品牌销售产品者根据第 21 条被视为制造商

各项要求何时适用?

第 71 条规定了分阶段的适用日期。第 IV 章,即关于通报合格评定机构的规则,自 2026 年 6 月 11 日起适用。第 14 条自 2026 年 9 月 11 日起适用。其他所有内容自 2027 年 12 月 11 日起适用。根据第 69(2) 条,2027 年 12 月 11 日之前投放市场的产品,只有在该日期之后进行了实质性修改,才需要满足该条例的其余要求;但第 69(3) 条规定,第 14 条无论如何都适用于这些产品。完整的时间表请参阅我们的指南欧盟《网络弹性法案》(CRA)2026 年和 2027 年截止期限。

第 71 条规定的 CRA 日期:2024 年 12 月 10 日生效,公告机构规则自 2026 年 6 月 11 日起适用,第 14 条报告义务自 2026 年 9 月 11 日起适用,其他所有内容自 2027 年 12 月 11 日起适用

其他搜索结果错在哪里

第一个错误是时间。一些指南称,该条例在报告义务适用日期的三年后才全面适用。事实上,报告义务自 2026 年 9 月 11 日起已经适用,而全面适用在 15 个月之后,即 2027 年 12 月 11 日。

第二个错误是把附件 I 简化成一份单一的“要求”清单。第 I 部分描述的是产品本身,在产品投放市场时进行评估。第 II 部分描述的是在整个支持期内必须持续运行的流程。一款产品可能在发布当天满足第 I 部分的要求,却因为第 II 部分的流程停止运行,在一年后不再合规。

第三个错误是把软件物料清单(SBOM)当作漏洞处理的全部内容。它只是八项中的第 (1) 项。定期安全测试、协调披露、免费且及时的安全更新以及已修复漏洞的公开披露同样重要,而且第 64(2) 条将整个附件 I 列入最高处罚档次:1500 万欧元或全球年营业额的 2.5%,以较高者为准。各处罚档次详见我们的指南 CRA 罚款与处罚。

您目前的状况如何?

请针对一款产品填写下表。空白的一行就是一个差距。

问题您的答案要求
在获悉某个漏洞正被利用后,您能否在 24 小时内提交早期预警?第 14(2)(a) 条,现已生效
是否有一份形成文件的风险评估,逐一涵盖附件 I 第 I 部分第 (2) 点中的每一项?第 13(3) 条
您能否为当前版本生成机器可读的 SBOM?附件 I 第 II 部分第 (1) 点
您的协调漏洞披露策略是否已发布,并附有联系地址?附件 I 第 II 部分第 (5) 点和第 (6) 点
支持期有多长,购买时是否显示其结束日期?第 13(8) 条和第 13(19) 条
该产品的类别要求采用哪种合格评定路径?第 32 条

我们的 CRA 合规检查清单将这些问题转化为一份可执行的工作清单,免费合规检查则为您提供覆盖各个 CRA 领域的基线。在 Venvera 中,CRA 模块将各项义务作为控制措施进行跟踪,并配有差距评估。它负责记录和跟踪合规情况,本身不测试产品,也不分析代码。

Venvera 中的欧盟《网络弹性法案》(CRA)差距评估页面,列出一项得分为 58% 的已完成评估,以及另一项正在进行中的评估
CRA 要求的结论:该条例规范的是产品如何构建和获得支持,而不仅仅是交付什么产品

常见问题

CRA 的要求是否适用于软件?

是的。具有数字元素的产品包括软件,以及属于该产品的远程数据处理解决方案。是否属于适用范围,取决于产品是否具有数据连接,以及是否在商业活动过程中在欧盟市场上提供。

CRA 是否强制要求 SBOM?

是的。附件 I 第 II 部分第 (1) 点要求以常用的机器可读格式编制软件物料清单,且至少涵盖顶层依赖项。根据附件 VII,它属于技术文档的一部分。根据附件 II 第 9 点,是否向用户提供软件物料清单由制造商自行决定。

安全更新必须提供多长时间?

在整个支持期内提供。第 13(8) 条将支持期设定为至少五年,除非产品的预期使用时间更短。此外,每一项安全更新在发布后都必须保持可用至少 10 年或支持期的剩余时间,以较长者为准。

报告义务是否适用于已投放市场的产品?

是的。第 69(3) 条规定,第 14 条适用于 2027 年 12 月 11 日之前投放市场的所有适用范围内的产品,因此较早的产品自 2026 年 9 月 11 日起也受其约束。

我们是否需要公告机构?

默认类产品不需要,这类产品可以进行自我评估。I 类重要产品需要公告机构,除非完整适用了协调标准、通用规范或符合条件的认证方案;II 类重要产品则需要采用第三方路径或认证方案。

一手资料来源

文中的要求、条款和日期取自 Regulation (EU) 2024/2847 第 13、14、19、20、21、32、64、69 和 71 条以及附件 I,并已对照其已发布的勘误进行核对。单一报告平台的状态取自欧盟委员会的 CRA 报告义务页面。附件 I 各要点为概括性内容;在依据某项具体条款之前,请阅读完整文本。

Alexander Sverdlov

Alexander Sverdlov

Venvera 首席执行官兼创始人

Alexander 是 Venvera 的创始人,在欧洲网络安全与合规领域拥有 20 多年经验。他曾为受监管的金融机构、金融科技公司和 SaaS 企业主导安全与风险项目,这些企业需要遵守 DORA、NIS2、GDPR、ISO 27001 和 EU AI Act。创立 Venvera 之前,他创办了进攻性安全咨询公司 Atlant Security,为 EU 和中东地区的客户开展渗透测试、红队演练和 ISO 27001 就绪项目。他的文章聚焦现代合规的跨框架实践:如何把一项控制措施映射到多项义务,电子表格会在哪里失灵,以及审计师真正坐下来之后,监管机构实际要求的是什么。

查看 Alexander 的更多文章 →

相关文章