网络韧性法案：2026 年 9 月 11 日是一个真实的期限
大多数欧盟条例给你一个合规日期，外加一段所有人悄悄组织起来的过渡期。网络韧性法案不一样。它的第一项硬性义务是一个 24 小时通报倒计时，从 2026 年 9 月 11 日开始。
24 小时的倒计时没法分阶段上线。要么那天流程已经存在，要么你就误期。
网络韧性法案是什么
第 (EU) 2024/2847 号条例为在欧盟市场上提供的带数字元素的产品设定网络安全要求。这个词覆盖的范围比人们最初以为的大得多：任何软件或硬件产品，以及其远程数据处理方案，只要其预期用途或合理可预见的用途包含直接或间接的数据连接。
联网设备在范围内。大多数商业软件、操作系统、浏览器、移动应用、固件，以及嵌在其他产品里的组件同样在内。
条例于 2024 年 11 月公布，分阶段适用：
- 2026 年 6 月 11 日：符合性评估机构的义务。
- 2026 年 9 月 11 日：对被主动利用的漏洞和严重事件的通报义务。
- 2027 年 12 月 11 日：全面适用，包括基本网络安全要求、CE 标识、技术文档和软件物料清单。
中间那个日期是要照着规划的，因为它先到，而且它依赖你可能还没有的能力。
2026 年 9 月 11 日会发生什么
从那天起，制造商必须通报：
其带数字元素产品中被主动利用的漏洞，以及
影响这些产品安全的严重事件。
通报通过由 ENISA 运营的网络韧性法案统一通报平台，提交给制造商主要营业地所在成员国指定的 CSIRT，再由其转发给其他相关 CSIRT 和 ENISA。
时间线：
- 知悉后 24 小时内：早期预警。
- 72 小时内：完整通报，包括已采取的纠正或缓解措施。
- 补救措施可用后 14 天内：被主动利用漏洞的最终报告。
- 一个月内：严重事件的最终报告。
是知悉后 24 小时，不是确认后，不是修好后。如果你产品里某个组件的漏洞在周六被野外利用，倒计时就在周六走。
为什么这比看上去难
通报义务本身是一张表。难的是你在填表之前必须具备的一切。
你得知道产品里有什么
要通报你产品里的某个漏洞正被主动利用，你必须知道那个有漏洞的组件在你的产品里。对于有几百个传递依赖的现代应用，这不是一个人靠记忆能回答的问题。
这就是团队现在就在搭软件物料清单流水线的原因，比 2027 年 12 月的正式 SBOM 要求早了一年多。SBOM 不是目标。目标是能在几小时内回答"这影响到我们吗？"，而 SBOM 是让这个问题可回答的东西。
难受的地方在于，这同样适用于你几年前发出去的产品。如果你有在用的受支持设备，固件是 2022 年从一棵没人记录过的依赖树构建出来的，重建它是实打实的工作。
你得盯着
知悉会启动倒计时，而这个"知悉"被期待是主动的而非偶然的。这意味着监控漏洞源、订阅你所用组件的公告、跟踪已知被利用漏洞目录，并有一条安全研究人员能找到你并得到回复的渠道。
你得有一条决策路径
必须有人能在一天中的任何时刻判断某个事件是否达到门槛、倒计时是否已经开始。没有指定角色和升级路径，头几个小时会花在弄清谁有权做这个决定上。
无人维护的依赖变成负债
如果你产品里的某个组件不再获得安全更新，当它被利用时你仍然承担通报义务，而你没有上游修复可指。梳理无人维护的依赖是准备阶段最有价值的事情之一，因为答案有时会逼出一次自带交付周期的迁移。
2027 年 12 月全面适用会带来什么
2027 年 12 月的义务是更大的工程，必须提前很久开始。
默认且从设计上安全。 产品必须以确保基于风险的适当网络安全水平的方式设计、开发和制造。没有默认口令。开箱即安全配置。攻击面最小化。传输中和静态数据的保护。
漏洞处理。 一套书面流程，覆盖识别、修复、测试、分发和披露。安全更新必须无迟延且免费提供，支持期要反映产品的预期生命周期，五年是常见的参考值。
软件物料清单。 机器可读格式，至少覆盖顶层依赖，并保持更新。
技术文档和符合性评估。 大多数产品自评。重要和关键类别，包括密码管理器、VPN、操作系统和工业控制系统等，需要第三方参与。
CE 标识。 那个实体标识的数字等价物，用以声明符合性。
协同漏洞披露政策。 要公开发布，并有一个真的能用的联系点。
谁真正在范围内
有几个边界情形反复出现。
在商业活动之外开发的自由和开源软件基本在范围外。条例引入了"开源软件管理者"这一概念，义务较轻。但如果你把开源商业化，或把它交付在你出售的产品里，产品义务就是你的。
软件即服务通常不在网络韧性法案范围内，更多落在 NIS2 之下，不过与带数字元素产品集成在一起的远程数据处理方案会被拉进来。如果你的设备需要你的云后端才能工作，后端就随产品一起进来。
进口商和分销商也承担义务。如果你以自己的名称或商标把第三方产品投放欧盟市场，你会被当作制造商。
已在别处受监管的产品，如医疗器械、车辆和航空设备，在各自的框架里处理。
适用范围的问题确实不简单，在这里花一小时和你们律师一起，能省下几个月方向错误的开发。
剩下的时间我们会怎么做
如果你在范围内且现在开始，这个顺序是有效的：
先建立产品清单。 你在欧盟市场上实际有什么？包括仍在使用的老版本、贴牌变体，以及你替别人分销的产品。这份清单通常比任何人预期的都长。
接着，把 SBOM 生成建进 CI。 每次构建生成 SBOM，CycloneDX 或 SPDX 格式，与发布产物一起保存，并保持可检索。目的是能问"我们发布过的哪些版本包含这个库？"并在几分钟内得到答案。
接着，接上漏洞监控。 把 SBOM 数据喂给一个跟踪公告和已知被利用漏洞目录的扫描器，并把告警发到一个真的有人看的频道。
接着，写事件处置手册。 谁宣布、谁评估、谁通报、谁对外沟通。指名到人、指定替补、留好非工作时间的联系方式。然后用一个虚构的公告演练一次。正是在演练里你会发现，有通报平台权限的那个人正在休假。
接着，发布漏洞披露政策。 一个 security.txt 文件、一个有人看的邮箱和一个公布的响应时间。这是一个下午的工作，也是从研究者那里还是从记者那里听到问题的区别。
最后，开始面向 2027 年 12 月的工作。 安全默认值、更新机制、支持期决策和文档，都是架构问题，不是文书工作。你在 2026 年设计的产品，2028 年还会在市场上。
没人利用的重叠
网络韧性法案和其他制度之间存在大量重复工作，而多数公司分别应对，这是浪费。
为网络韧性法案建的 SBOM 回答了 NIS2 供应链问题的大部分。事件处置手册与 NIS2 的 24 小时早期预警和 GDPR 的 72 小时泄露通报重叠。漏洞处理流程直接喂给客户的安全问卷和大企业采购。
把它当成平台能力建一次。另一种选择是三个团队建同一份资产清单的三个版本。
从哪里得到帮助
我们为向欧盟销售的公司构建和维护软件，这越来越意味着构建网络韧性法案所预设的那套供应链可见性和更新基础设施。如果你在弄清自己是否在范围内，或者日历上有那个九月的日期却还没有监控，写信到 office@c9group.dev。
我们的遗留系统维护服务常常是这件事的起点，因为依赖可见性最差的产品往往是最老的。完整的监管图景见我们的 2026 年欧盟数字合规指南。
我们是工程师，不是律师。适用范围和分类的判断属于你们的律师，我们按那个答案来建。