摘要

  • 2026 年 9 月 11 日起，欧盟《网络韧性法》第 14 条开始约束数字要素产品制造商：知悉正在被主动利用的漏洞或严重安全事件后，须在 24 小时内发出预警，并在 72 小时内提交较完整通知。
  • Single Reporting Platform 实现的是“一次提交”，不是“单一权力”。制造商选择国家 CSIRT 协调机构，由后者评估并通常向其他相关 CSIRT 分发；ENISA 运营平台。首发版本只有英文、没有 API，不接受自愿报告，也尚未启动开源软件管理者的报告义务。

欧盟先让报警器通电，再等整套产品安全规范全面投入使用。

这是《网络韧性法》分阶段生效的关键设计。European Commission 公布的实施时间表显示，安全设计、漏洞处置、合格评定等主要要求要到 2027 年 12 月 11 日普遍适用；第 14 条的报告义务则从 2026 年 9 月 11 日开始。

现在触发时钟的不是产品获得认证，也不是监管机构启动调查，而是制造商“知悉”特定事件。对于正在被主动利用的漏洞，或对数字要素产品安全造成严重影响的事件，制造商必须不无故拖延，并最迟在知悉后 24 小时发出早期预警；72 小时内补交含一般资料和初步评估的通知。

European Commission 的报告说明还区分两种最终报告：主动利用漏洞在纠正或缓解措施可用后最迟 14 天提交；严重事件则在 72 小时通知后一个月内提交。换句话说，前三个节点由“知悉”与“措施可用”这类事实触发，并不以门户网站显示的倒计时为法律起点。

这也意味着，2027 年底以前并非空白准备期。只要产品属于适用范围并已在欧盟市场提供，即使它在主要义务全面生效前进入市场，制造商今天仍可能承担报告责任。报告通道先行，使监管机构在更完整的产品规范到来前就能看到结构化风险信号。

一个入口，四类责任

ENISA 的 Single Reporting Platform让制造商针对同一漏洞或事件只报一次。企业即使在欧盟拥有多个分支或子公司，或者母公司设在欧盟以外，也不必把同一份材料逐国重复递交；但集团内部仍要自行协调，确定由谁申报。

“一次”描述的是提交动作，不是权力归一。申报人需要选择一个被指定为协调机构的国家 CSIRT，通常依据制造商的主要设立地确定。选择责任在制造商。ENISA 维护的协调 CSIRT 清单因此不是通讯录附件，而是合规路由表。

在常规路径中，所选 CSIRT 与 ENISA 同时取得通知。最初接收的 CSIRT 随后把材料及时分发给产品已投放市场的其他相关成员国 CSIRT，并可按执法需要把部分信息交给市场监管机构。

这条链上至少有四种不同责任。制造商掌握产品、内部知悉时间与技术事实；国家协调机构作初步评估并控制跨境流转；ENISA 负责平台、汇总视野与后续分析；市场监管机构决定是否调查、纠正或执法。平台集中，并没有把这些角色折叠成一个“欧盟监管者”。

因此，上传成功不能自动证明路由正确。ENISA 的常见问题页面明确说，若选错协调机构，通知可能被判为无效，需要重新提交。企业若只列出法条，却没有把制造商法人、主要设立地、产品在各成员国的可得性连起来，仍然缺少执行地图。

PEC 不是制造商自行按下的保密键

对正在被利用的漏洞，过早扩散完整细节有时会扩大攻击面。《网络韧性法》因此设置了“特别例外情形”（Particularly Exceptional Circumstances，PEC），允许在严格的网络安全理由下延迟常规分发。

但操作流程有两把钥匙。ENISA 的 PEC 指引把它放在主动利用漏洞的 72 小时通知里：制造商勾选并陈述理由，国家协调 CSIRT 判断是否接受。若成立，ENISA 起初只收到有限信息，协调机构继续负责何时向有关 CSIRT 和 ENISA 分享完整通知。

制造商提出，公共机构决定。这个界限防止企业把任何敏感事件都单方面变成长期秘密，也避免系统机械扩散尚不适合广泛流转的漏洞细节。

一份可核查的内部记录应把四件事分开：何时提出 PEC、依据是什么、谁作出决定、何时恢复完整分发。没有这些时间戳，协调披露与漏报在事后可能留下相同外观。

首发平台有意只覆盖最小法定面

ENISA 于 9 月 10 日更新的常见问题把首发边界写得很清楚。当前入口只处理制造商依据第 14 条提交的强制通知，范围是主动利用漏洞与严重安全事件。第 15 条允许的自愿报告尚未上线，非制造商若要报告漏洞或安全问题，暂时应直接联系相关国家 CSIRT。

开源软件管理者也不应被提前纳入今天的时钟。他们依据第 24 条第 3 款承担的报告义务从 2027 年 12 月 11 日开始。平台说明会提到这些未来用户，但未来设计不能被误读为当前责任。

首发界面只有英文，也没有应用程序编程接口。企业可以自动化内部工单、漏洞分类和材料准备，却仍须由人员通过网页完成正式提交。对拥有大量产品的制造商而言，缺少 API 不是单纯的不便，而是要在 24 小时窗口内安排人、账号、复核与替班的容量问题。

身份链同样具体。指定代表使用带多因素认证的个人 EU Login 账号；代表与制造商之间的关联由所选 CSIRT 验证。验证与申报并行，不会阻挡首次紧急通知：在必须完成验证前，尚未核验的代表最多可为同一制造商提交 20 份通知。ENISA 注册指引由此给出一个实务结论——不要等事故发生后才决定法人、国家协调机构与备用代表。

屏幕提醒不等于法定期限

ENISA 公开了一项尤其值得注意的首发实现差异。当前门户的“72 小时”计数器，是在 24 小时预警的提交时刻上再加 48 小时。法条却从制造商知悉事件时起算 72 小时。若预警提交得早，页面就可能在真正的 72 小时尚未走完前把通知显示为逾期。ENISA 表示后续会改用“知悉时间”字段计算。

这不是期限变更。它恰好说明运行界面为何不能悄然替代政策文本。制造商至少应分别保存：知悉时刻、支撑知悉的证据、预警提交时间、自行计算的 72 小时终点、页面显示终点和每次回执。

反过来也一样：门户提醒若晚于法律时钟，不能延长期限。真正可辩护的做法，是让内部事件时间线与平台状态相互校验，而不是选择对自己最有利的那个时间。

临时不可用时也要保持双重记录。ENISA 的规则是待平台恢复后仍须补交；如确有立即沟通必要，可以先直接联系指定 CSIRT，但直接联络不能替代后续平台提交。单次连接失败、登录问题或个别支持工单，都不足以证明整个服务中断。

公开运行版本，不公开漏洞内容

监督这套治理机制，并不需要把尚未修补的漏洞、制造商或攻击细节暴露给公众。需要公开的是系统在某一时刻能够做什么。

ENISA 可以维护一份保护隐私的运行状态与规则版本日志，列明服务中断、允许的申报人类别、支持的报告类型、界面语言、API 状态、期限计数逻辑，以及每次变更的生效时间。它不应列出具体报告，却能让企业、监管者和审计人员还原当时使用的是哪一版执行规则。

这是我的编辑建议，不是现行 CRA 要求，也不是 ENISA 已作出的承诺。它遵循 The Policy Mirror 对权力链的追踪、Running Code Primary 对实际执行状态的检验，以及 Why BTW Media Exists 对事实、制度叙事和主张的区分。

欧盟已经把统一入口打开。接下来真正考验制度的，是每一次知悉、提交、判断与分发能否保留各自的责任人和时间。

资料来源