合规指南
对于大多数制造商而言，从零开始实现欧盟《网络弹性法案》（CRA）合规需要 12 到 24 个月。这一区间之所以很宽，是因为 CRA 并不是要求您在某个日期之前提交一份文件。它要求您改变构建、交付和支持产品的方式，然后证明这一点。已经在运行安全开发生命周期和有效漏洞披露流程的企业，耗时接近 12 个月这一端，而且还能省去预算中最大一项支出的大部分，我们关于欧盟《网络弹性法案》合规成本的指南根据欧盟委员会自己的数据对这项支出进行了估算。如果企业的构建流水线没有文档记录，产品组合也从未正式分类，就应按 24 个月或更长时间来规划。
真正应当驱动您计划的日期，并不是 CRA 全面适用的 2027 年 12 月 11 日。而是第 14 条报告义务开始生效的 2026 年 9 月 11 日，因为这些义务适用于已经投放市场的产品，而一个仍处于范围界定阶段的项目无法满足这些义务。
| 阶段 | 通常耗时 | 制约因素 |
|---|---|---|
| 界定范围与分类 | 4 至 8 周 | 掌握您投放到欧盟市场的每一款带有数字元素的产品，以及每款产品属于附件 III 中的哪一类别。 |
| 附件 I 差距评估 | 6 至 12 周 | 能否接触到真正了解构建过程的人员。第 II 部分（漏洞处理）的差距通常比第 I 部分更大。 |
| 安全开发与漏洞处理 | 6 至 12 个月 | 工程能力。正是这一阶段决定了您最终需要 12 个月还是 24 个月。 |
| 技术文档 | 2 至 4 个月 | 可部分并行开展，但不能在构建变更完成之前结束。 |
| 合格评定与 CE 标志 | 1 至 6 个月 | 产品类别。自我评估可以很快完成，而公告机构的排队则不然。 |
CRA 合规需要多长时间？
12 到 24 个月是如实的规划区间，而且区间内的分布并不均匀。范围界定、文档编制和评估阶段相当可预测。工程阶段则不然，而且它占据了总时长的大部分。
估算自身所处位置的一个有效方法，是问问自己：如果监管机构明天就提出要求，您需要构建哪些东西？如果您能够为已交付的产品提供软件物料清单，说出负责对外部提交的漏洞报告进行分诊的人员，并展示上一个版本运行过的安全测试，那么您更接近 12 个月，而不是 24 个月。如果这三项中有任何一项让您无从回答，那么您的时间将主要花在工程阶段。
什么决定了需要 12 个月还是 24 个月？
以下四个因素，按影响程度从大到小排列。
1. 是否已有安全开发生命周期
附件 I 第 I 部分要求产品在交付时不存在已知的可被利用的漏洞，采用默认安全配置，并具备安全更新能力。附件 I 第 II 部分要求进行漏洞处理：SBOM、协调披露以及及时的安全更新。大多数制造商正是在第 II 部分发现了真正的工作量。为一次审计生成一份 SBOM，只需要一周的工作量。而为每个版本自动生成 SBOM 并保持其准确，则需要对流水线进行变更。
2. 产品分类
默认类产品进行自我评估。附件 III 中的重要产品可以采用协调标准，或者借助第三方。第 II 类重要产品需要第三方。附件 IV 中的关键产品可能需要通过欧洲网络安全认证计划。每升高一级，都会同时增加成本和日历时间，而日历时间正是人们容易低估的部分，因为公告机构的能力有限，而且随着 2027 年临近，排队时间会越来越长。
3. 产品组合规模与共享组件
合规工作量并不随产品数量线性增长。基于同一个共享平台的十款产品，更接近于一个项目，而不是十个。十年间通过收购获得、分别运行在十套技术栈上的十款产品，则确实是十个项目。请尽早梳理出共享组件的图谱，因为正是这份图谱会告诉您，您需要的是 12 个月还是 24 个月。
4. 您已经为其他法规做过哪些工作
如果您已经完成过欧盟 NIS2 指令的合规工作，或者持有 ISO 27001 认证，那么欧盟《网络弹性法案》（CRA）的一部分投入其实已经完成。安全开发、资产清单和事件处理流程是相互重叠的。而 CRA 特有的部分，即产品层面的基本要求、SBOM、CE 标志和技术文件，则不重叠。
您真正应当以哪个截止期限为准来规划？
以 2026 年 9 月 11 日为准来规划。这是第 14 条报告义务开始生效的日期：被积极利用的漏洞和严重事件必须报告，24 小时内发出早期预警，72 小时内提交更完整的通知。这些义务适用于您已经投放市场的产品，因此提前交付产品并不能为您换来任何宽限期。
随后，该法案将于 2027 年 12 月 11 日全面适用，涵盖基本要求、合格评定、CE 标志和欧盟符合性声明。另一个单独的里程碑是 2026 年 6 月 11 日，自该日起成员国可以指定合格评定机构，这一点之所以重要，主要是因为从这时起才开始有公告机构的能力可用。完整的日期安排，请参阅我们关于欧盟《网络弹性法案》2026 年和 2027 年截止期限的指南。
从今天算起，2026 年 9 月 11 日已经近在眼前。如果您的报告流程尚未设计好，那么这就是需要优先于其他一切提前完成的部分，因为这是唯一一项可能在您的产品工作完成之前就被违反的义务。
其他搜索结果错在哪里
已发布的指南中反复出现三个问题。
第一个问题是只给出单一数字。那些声称 CRA 合规需要 6 个月或 18 个月的文章，其实是在描述某一家公司的产品组合，却没有说明这一点。仅在评估阶段，您产品的分类就能让答案相差四倍。
第二个问题是把 2027 年 12 月 11 日当作截止期限。它是最后一个截止期限，而不是第一个。从 2027 年倒推进行规划，会把早一年多到来的报告义务放在进度计划中错误的位置上。
第三个问题是把这项工作描述成文档编制工作。技术文件只是产出。真正耗时的是让文件内容属实的工程变更，下载再多的模板也无法缩短这一过程。
未来 30 天内您可以做些什么？
请针对您自己的产品组合填写下表。如果某一行您无法填写完整，那么这一行就是您的第一个项目。
| 问题 | 您的回答 | 为何重要 |
|---|---|---|
| 您在欧盟市场投放了多少款带有数字元素的产品？ | 没有数量就无法界定范围，而没有范围，任何估算都只是猜测。 | |
| 其中有多少款属于附件 III 的重要产品或附件 IV 的关键产品？ | 这决定了您的合格评定路径，以及评估日程的大部分安排。 | |
| 您能否为上一个版本生成 SBOM？ | 附件 I 第 II 部分。如果答案是否定的，这将是您耗时最长的阶段。 | |
| 目前由谁对外部提交的漏洞报告进行分诊？ | 第 14 条需要的是指定的负责人和计时机制，而不是一个收件箱。 | |
| 您明天就能提交 24 小时早期预警吗？ | 对于已投放市场的产品，该义务自 2026 年 9 月 11 日起生效。 |
如果您希望在确定计划之前先建立基线，可以进行一次免费合规检查。它不会估算工程工作量，但会告诉您上述五行中哪些会让您感到吃力。
常见问题
我们能在 2026 年 9 月 11 日之前做好准备吗？
就报告义务而言，在大多数情况下可以。设计报告流程、指定负责人并演练 24 小时早期预警，只需要数周的工作，而不是数月。到那时能否满足全部基本要求则是另一个问题，对于大多数制造商来说，答案是否定的。这正是到 2027 年 12 月为止额外的 15 个月的用途。
CRA 是否适用于单独销售的软件？
是的。带有数字元素的产品包括独立于硬件投放市场的软件。适用范围取决于产品，而不是行业，我们关于谁必须遵守欧盟《网络弹性法案》（CRA）的指南对此有详细介绍。
开源会缩短还是延长时间？
两者都有。在商业活动之外提供的自由和开源软件，在很大程度上不在经营者义务的范围内；但如果您将开源组件集成到您投放市场的产品中，它们就属于您的 SBOM 和漏洞处理的范围。组件清点工作通常会延长差距评估阶段。
我们需要公告机构吗？
仅以下情况需要：附件 III 中的第 II 类重要产品、附件 IV 中的关键产品，以及您未完全采用协调标准的第 I 类重要产品。默认类产品进行自我评估。请尽早核实分类，因为仅这一个答案就会让完成日期前后相差数月。
如果我们错过了截止期限怎么办？
第 64 条设定了罚款上限，而最高档位恰好涵盖上文讨论的附件 I 要求以及第 13 条和第 14 条规定的义务。详情请参阅我们关于欧盟《网络弹性法案》罚款与处罚的指南。
主要来源
上文中的日期和义务取自 Regulation (EU) 2024/2847（第 13 条、第 14 条和第 71 条，以及附件 I、III 和 IV）和欧盟委员会关于欧盟《网络弹性法案》（CRA）的政策页面。各阶段的耗时是根据实施工作得出的规划估算，并非该条例中的数字。在依赖任何具体日期之前，请先核实现行文本。
