2026 年 9 月 11 日，欧盟《网络弹性法案》（Cyber Resilience Act，法规编号 Regulation (EU) 2024/2847，下称 CRA）第 14 条的漏洞与事件通报义务开始适用。到今天已经过去两个月，很多做出口交付的团队仍把它当成 2027 年 12 月才需要处理的认证事项。实际情况是：整套法案的全面适用确实在 2027 年 12 月 11 日，但“出事后按小时计时”的那一部分已经先跑起来了，而且覆盖 2027 年 12 月 11 日之前已经卖到欧盟的存量产品。
这篇文章不讨论宏大的合规叙事，只处理一个具体场景：一家中国软件或系统集成公司，把带联网能力的软件、固件或本地部署系统交付给欧盟客户，从 2026 年 9 月之后，交付物里应该多出哪些东西，出事后 24 小时、72 小时和最终报告这三个节点分别怎么过，SBOM（软件物料清单）怎么和构建绑定，支持期与授权代表又该怎么写进合同。
一、一句话读懂：管的不再只是“上市时安不安全”
CRA 对“带数字元素的产品”（products with digital elements）设定了一套贯穿全生命周期的网络安全要求。它把过去分散在若干指令里的产品安全义务收拢到一部横向法规里，核心可以拆成两条线：一条是上市前的设计与文档义务，另一条是上市后的漏洞处理与事件通报义务。前者随法案全面适用，后者提前了 15 个月。
第 14 条只盯两类事情。第一类是“已被实际利用的漏洞”（actively exploited vulnerability）：有可靠证据表明，攻击者未经系统所有者许可，已经完成了利用。第二类是“严重安全事件”（severe incident）：已经或可能损害产品保护数据、功能的可用性、真实性、完整性或保密能力的事件。两类事情都从制造商“知悉”那一刻开始计时，而不是从公开披露、补丁发布或者客户投诉开始计时。
这里有一个容易被忽略的细节：通报义务不只落在欧盟本地企业身上。只要产品是在欧盟市场提供，制造商注册地在哪里并不影响义务成立。对中国出口企业来说，这意味着“我们在国内、不直接面对欧盟监管机构”不再是理由。
二、先判定交付物：四类形态，三种结论
合规工作最怕一上来就写文档。第一步应该是把交付物拆开，逐个判定它在不在 CRA 的范围内。软件和固件都属于“带数字元素的产品”，但交付形态不同，结论差别很大。
| 交付形态 | 典型例子 | 初步判断 | 要先确认的点 |
|---|---|---|---|
| 随设备交付的固件 | 网关、控制器、数据归集终端、带联网模块的仪表 | 通常在范围内 | 联网方式、支持期、更新通道 |
| 本地部署软件 | 装在客户机房的业务系统、边缘侧服务 | 通常在范围内 | 是否可下载、是否随设备、是否单独销售 |
| 纯云端 SaaS | 浏览器访问的多租户服务 | 一般不在范围内 | 是否构成产品不可分割的远程数据处理方案 |
| 单客户定制开发 | 按一份合同为一个客户做的系统 | 需要逐个判断 | 是否向第三方提供、是否被客户再销售、合同是否约定 |
“需要逐个判断”不是含糊其辞。CRA 的适用锚点是“在欧盟市场提供或投放”，欧盟委员会 2026 年 7 月 27 日发布的实施指南 C(2026) 5252 用了大量示例来解释软件何时算投放市场、远程数据处理方案何时算产品的一部分、开源软件在什么情况下不承担制造商义务。指南本身不具法律约束力，但它是指南层面最接近官方口径的材料，遇到边界情况应当逐条对照，而不是凭经验拍板。
还有一条经常被忽略的过渡规则：2027 年 12 月 11 日之前已经投放欧盟市场的产品，如果之后没有发生“实质性修改”，并不需要立刻补齐全部上市前义务，但仍然要先适用第 14 条的通报义务。换句话说，存量产品不是“一次豁免、永久有效”，而是“先报事、后补课”，不存在一份永久豁免。一旦改动触及安全相关功能、认证机制、数据处理方式，就可能被认定为实质性修改，从而触发完整的合规流程。
三、三条时间线：24 小时、72 小时与最终报告
第 14 条把通报拆成阶段，而不是要求企业在 24 小时内交出一份完整调查报告。这个设计很重要：第一阶段只要求把已经知道的事情说清楚，后续再补细节。
| 节点 | 已被利用的漏洞（AEV） | 严重安全事件（SI） |
|---|---|---|
| 早期预警 | 知悉后 24 小时内 | 知悉后 24 小时内，并说明是否怀疑由恶意行为引起 |
| 正式通报 | 知悉后 72 小时内，补充漏洞性质、受影响产品、初步影响与已采取措施 | 知悉后 72 小时内，补充事件性质、初步评估与缓解措施 |
| 最终报告 | 纠正或缓解措施可用后 14 天内 | 正式通报提交后 1 个月内 |
| 用户通知 | 及时通知受影响用户，说明风险与可采取的措施 | 同上 |
注意最终报告的两条起算线并不对称。漏洞的最终报告从“修复或缓解措施可用”开始算，事件的最终报告从“正式通报提交”开始算。很多团队把两者混成一个“14 天”，结果要么提前交了一份不完整的报告，要么在事件场景下算错了截止日。内部作业手册里应当把两条计时线分开写。
通报统一通过 ENISA 运营的单一报告平台（Single Reporting Platform，SRP）提交，平台在 2026 年 9 月 11 日与通报义务同步上线。提交后，信息会同时到达制造商主要营业地所在成员国的协调 CSIRT 和 ENISA，再由协调 CSIRT 分发给产品被提供所在成员国的其他 CSIRT。对非欧盟制造商，第 14 条第 7 款给出了接收方的选择顺序：优先是授权代表所在的成员国，其次是有最大进口商的成员国，再次是有最大经销商的成员国，最后是用户最集中的成员国。选错协调 CSIRT 可能导致通报被退回重提，所以这件事不能留到事发当天再决定。
关于平台操作，有两个实务点值得提前准备。第一，平台使用 EU Login 账号并开启多因素认证，账号是个人账号而不是企业账号；第二，可以设置主要代表和备用代表，避免只设一个联系人、遇休假离职或时差导致错过窗口。ENISA 的指南也明确，代表身份的人工验证与首次提交通报是并行的，验证不是第一次上报的前置条件，但长期不验证会影响后续提交。把账号开通、角色配置和一次模拟填报放在平时做，成本远低于事发当天现注册。
罚则方面，第 64 条把处罚分成三档：违反附件一基本要求以及第 13 条、第 14 条义务的，最高为 1500 万欧元或全球年营业额的 2.5%，取较高者；违反其他义务的，最高为 1000 万欧元或 2%；提供不正确、不完整或误导性信息的，最高为 500 万欧元或 1%。具体认定与适用由成员国监管机构决定，这里只作条款层面的说明。
四、24 小时里真正要做的五件事
把时间线翻译成动作，24 小时窗口里其实只有五步。顺序比工具重要。
第一步，确认影响范围。需要回答三个问题：哪些产品、哪些版本、哪些客户。版本要精确到构建号，而不是只写“3.x”。如果交付时没有记录构建号与客户清单的对应关系，这一步会直接吃掉整个窗口。
第二步，判定属于哪一类。是已被实际利用的漏洞，还是严重安全事件，抑或两者兼有。判定依据要留下书面记录，包括情报来源、验证过程、排除理由。这里不需要追求“最终结论”，但要能解释为什么按某一类处理。
第三步，起草早期预警。预警阶段需要说明受影响产品、在哪些成员国提供、已知的利用情况。严重事件还要说明是否怀疑由恶意行为引起。不要在这一步追求根因分析，先把确定的事实写清楚。
第四步，主备会签并提交。提交人、复核人、法务或合规负责人应当在平时就固定下来，并明确谁有权在联系不上管理层时先行提交。窗口只有 24 小时，层层审批是最常见的延误来源。
第五步，留痕并启动用户通告。平台回执、提交内容、内部决策记录都要归档。用户通告与监管通报是并行的两条义务，不能等监管流程走完再通知客户。通告模板应当提前准备好中英两版，包含受影响版本、风险说明、临时缓解措施、修复计划和联系方式。
我们在项目里踩过的坑，基本都集中在这五步的衔接处。有一次交付的版本号与构建号对不上，客户报障时只能确认“大概是上半年那批”，花了半天才对上具体构建；后来改成构建时写入提交哈希，SBOM 与安装包同源归档，发货单记录构建号，定位时间才降下来。还有一次只设了一个平台联系人，对方在国外出差，演练时差点错过 24 小时节点；现在固定主备两人，每季度做一次桌面演练，模拟“某个基础库爆出在野利用”，从知悉到预警草稿控制在半个工作日内。这些都是内部目标，具体时限以项目约定为准，不构成对外承诺。
五、SBOM 不是一张 Excel：要能和构建对上
CRA 附件一第二部分第 1 项要求制造商识别并记录产品中的组件与漏洞，包括以常用且机器可读的格式编制软件物料清单，至少覆盖产品的顶层依赖。很多团队把这句话理解成“整理一份依赖清单”，于是用表格手工维护，结果每次发版都对不上，出事时也不敢拿它做判断。
可用的 SBOM 至少要满足四个条件。第一，机器可读，常用格式是 SPDX 或 CycloneDX，字段能被工具解析，而不是截图或 PDF。第二，与构建绑定，每次对外构建生成一份，记录构建号、提交哈希、生成时间，SBOM 随安装包一起归档。第三，覆盖运行时实际加载的组件，不只列直接依赖；传递依赖往往才是漏洞来源。第四，有明确的保管期限和读取方式，法规要求技术文档在投放市场后至少保存 10 年，或支持期更长时以支持期为准，SBOM 作为技术文档的一部分应当按同一口径管理。
SBOM 的价值不在“交差”，而在缩短三个时间：确认某个组件是否在受影响版本里、确认哪些客户受影响、确认修复后哪些构建需要重新发布。如果这三个问题不能在数小时内回答，SBOM 就只是文档，不是能力。建议把 SBOM 生成接进 CI：构建成功即产出，缺少 SBOM 的构建不允许发布；同时保留一份“组件—版本—构建—客户”的索引，避免事发时在多个系统之间手工拼接。
还要注意第三方组件的责任边界。CRA 要求制造商对集成进产品的第三方组件做尽职调查，确保它们不会削弱产品的网络安全。作为组件或软件供应商，你未必是最终产品的制造商，但客户会把同样的要求沿着供应链传下来：要 SBOM、要漏洞处理策略、要支持期声明。提前准备这些材料，比在投标或验收阶段被动补要省力得多。
六、支持期与合同：把“以后再说”变成条款
CRA 第 13 条第 8 款要求制造商确定支持期，并在支持期内有效处理漏洞。支持期通常至少五年，如果产品的预期使用期短于五年，可以与预期使用期一致；确定支持期时考虑的因素要写进技术文档。对工业设备、边缘网关、行业软件来说，现场使用年限往往超过五年，照抄“五年”并不一定够，需要结合产品性质、客户预期和同类产品的通常支持年限来判断。
支持期一旦写进合同，就不只是技术承诺，而是成本和责任的分配。我们建议至少把五件事写清楚：支持期的起算日与终止日；安全更新的交付通道与频率；漏洞接收的联系方式与响应流程；发生第 14 条事项时双方的配合义务；以及支持期结束后的延保或迁移安排。法规要求安全更新不向用户另行收费，具体范围与条件以法规原文和合同约定为准，超出支持期的服务则可以另行约定。
非欧盟制造商还会遇到授权代表的问题。CRA 第 18 条的措辞是制造商“可以”指定授权代表，并不是一律强制；但如果没有任何欧盟实体，平台上报、监管联络、技术文档留存这些事就容易落到进口商或经销商身上，渠道关系会变得被动。实务上更稳妥的做法，是在合同里明确谁担任授权代表、承担哪些事项、费用如何分摊，而不是等到客户来问“你们的欧代是谁”。同时要区分两个容易混淆的角色：平台上的“指定代表”只是操作账号角色，法规下的“授权代表”是承担法定义务的法律角色，两者不是一回事。
还有一个触发点值得写进版本管理流程：实质性修改。一次看似普通的更新，如果改变了认证凭据的保存方式、日志中敏感数据的存储方式、远程维护通道的开放范围，就可能被认定为实质性修改，从而需要重新评估合规状态。把“是否构成实质性修改”做成发版检查表的一栏，比事后争论更有效。
七、一套可交付的“CRA 交付包”
把上面的要求落到交付物，我们通常给出口项目准备五份材料。它们不追求篇幅，追求的是事发当天能直接拿出来用。
- 产品与版本清单：产品名称、型号、固件或软件版本、构建号、首次投放欧盟市场的日期、对应客户或渠道。
- SBOM：机器可读格式，覆盖顶层依赖与运行时组件，与构建号、安装包哈希绑定，注明生成时间与保管位置。
- 支持期声明：起算日、终止日、判定依据、更新通道、支持期结束后的安排。
- 漏洞通报联络单：主备联系人、平台账号持有人、协调 CSIRT 选择依据、授权代表或进口商联系人、用户通告责任人。
- 用户通告模板：中英两版，包含受影响版本、风险说明、临时缓解、修复计划与联系方式。
验收不看文档厚度，看五个指标。第一，给定一个组件和版本，能否在半天内回答“哪些构建、哪些客户受影响”；第二，模拟一次在野利用漏洞，从知悉到预警草稿能否在一个工作日内完成；第三，对外构建的 SBOM 覆盖率是否达到全部；第四，通报材料的内部评审一次通过率；第五，用户通告能否在监管通报提交后的一个工作日内发出。前四项是内部管理指标，第五项是内部目标，法规对用户通知的要求是“及时”，具体时限以主管机关解释和合同约定为准。
如果从零开始，两周可以完成第一版：第一周做交付物盘点、范围判定、版本与客户映射；第二周做 SBOM 接入、账号与角色配置、一次桌面演练和模板定稿。真正耗时的是数据对齐，不是写文档。把这件事当成一次交付流程改造，比当成一次合规冲刺更容易落地。
八、边界与成本：哪些话现在不能说满
第一，本文是公开信息整理，不构成法律意见。产品是否落入 CRA 范围、某一改动是否构成实质性修改、某一事件是否达到“严重”门槛，都要结合法规原文、委员会指南和具体事实判断，必要时咨询专业律师。
第二，纯云端服务不要急着对号入座。CRA 主要管“投放市场”的产品，纯 SaaS 一般不在范围内；但如果云端功能是产品不可分割的远程数据处理方案，就需要按指南逐项评估。把“云”当作天然豁免，和把“云”当作天然在范围内，都是偷懒。
第三，协调标准还没有全部落地。欧盟委员会 2025 年 2 月通过标准化请求 M/606（C(2025) 618），委托制定 41 项协调标准，横向的 prEN 40000 系列仍在推进，截至 2026 年 11 月尚未在欧盟官方公报上刊登。没有刊登，就没有“符合协调标准即推定符合”的效力，但这不等于义务延后：法律义务来自法规正文和附件一，标准只是证明路径。现在就可以按附件一搭技术文档，不必等标准定稿。
第四，开源软件的角色要分清。非商业性支持的开源项目本身不承担制造商义务；一旦以商业方式提供，或者被集成进商业产品，责任就沿着供应链传导。开源软件维护者（steward）的第 14 条相关通报义务自 2027 年 12 月 11 日起适用，和制造商的 2026 年 9 月 11 日不是同一个起点。
成本方面，主要投入在四块：工程侧的 SBOM 接入与版本映射、安全侧的漏洞处理流程与演练、法务侧的合同与授权代表安排、以及测试与文档维护。没有一项可以完全外包，因为出事后 24 小时内能拍板的人必须在组织内部。把预算花在“平时能演练、事发能提交”的能力上，比买一套只生成报告的工具更实际。
九、常见问题
只卖软件、不卖硬件，也要管吗？软件同样属于“带数字元素的产品”。判断关键是有没有在欧盟市场提供、是否具备直接或间接联网能力，以及交付形态是否构成投放市场。
纯 SaaS 要不要按 CRA 准备？一般不在范围内。但如果云侧功能是产品不可分割的一部分，或者产品本身依赖远程数据处理才能实现预期用途，就需要按委员会指南评估。
2027 年之前卖出去的老产品怎么办？在未发生实质性修改的情况下，先适用第 14 条通报义务；全面义务从 2027 年 12 月 11 日起适用。存量产品同样要有版本清单和联络通道。
24 小时内必须交完整报告吗？不需要。24 小时内提交的是早期预警，说明已知事实；72 小时内补充正式通报；最终报告按漏洞和事件分别计算。
没有欧盟实体，怎么提交？通过 ENISA 的单一报告平台，使用个人 EU Login 账号并开启多因素认证。授权代表可以指定，也可以不指定，但接收方选择和合同责任要提前明确。
附：口径与来源
法规依据：Regulation (EU) 2024/2847（Cyber Resilience Act），第 13 条、第 14 条、第 18 条、第 64 条，附件一第二部分第 1 项。适用时点：第 14 条自 2026 年 9 月 11 日适用，法案其余主要义务自 2027 年 12 月 11 日适用。委员会实施指南：C(2026) 5252，2026 年 7 月 27 日发布，不具法律约束力。通报平台：ENISA CRA Single Reporting Platform，2026 年 9 月 11 日上线。标准化：委员会标准化请求 M/606（C(2025) 618），41 项协调标准，prEN 40000 系列截至 2026 年 11 月尚未在欧盟官方公报刊登。存量产品与通报路由的解读参考了 Taylor Wessing 与 JD Supra 上 2026 年 9 月的公开分析。本文为公开信息整理，不构成法律意见；具体适用以法规原文、委员会指南及主管机关解释为准。
