从 2026 年 8 月 31 日算起，距离欧盟《网络弹性法案》（CRA）漏洞通报义务正式生效的 2026 年 9 月 11 日，只剩 11 天。这是 CRA 自 2024 年 12 月 10 日生效以来第一个强制执行的时间节点，也是对所有在欧盟市场销售"含数字元素产品"的制造商而言，第一个与日常运营直接挂钩的硬性要求。
不少企业已经读过法规条文，但仍有三个疑问没有解决：什么样的漏洞需要通报？具体怎么报？来不及报会怎样？本文结合 CRA 第 14 条原文与行业实践，把通报义务的合规要求完整梳理一遍，并说明为什么 9.11 只是 CRA 合规的起点，而不是终点。
一、通报义务在 CRA 框架中的位置
CRA（Regulation (EU) 2024/2847）是欧盟乃至全球首个对硬件和软件产品提出全生命周期网络安全要求的法规。它的监管对象是"含数字元素的产品"------通俗地说，只要产品包含软件，或可以通过网络被远程访问、控制，就在监管范围内。IoT 设备、网络设备、工业控制系统、医疗设备、汽车电子、消费电子均在列，而固件作为嵌入式设备的核心，是 CRA 审查的焦点。
CRA 的核心原则是"默认安全"（Security by Default）：安全能力不是可选项，而是产品的出厂默认配置。围绕这一原则，CRA 为制造商规定了五项核心义务：安全设计、漏洞管理、SBOM 提供与管理、安全更新支持、合规文档与证据留存。其中，第 14 条规定的漏洞通报义务，是漏洞管理中时效要求最高、程序约束最严格的一环。
值得强调的是，这条义务沿着供应链传导：制造商（包括 OEM/ODM 代工厂）承担首要责任，进口商、分销商承担核查义务，软件供应商则需要向下游提供组件的安全信息（如 SBOM）。换言之，通报义务不是品牌商一家的事。
二、哪些情况必须通报：两类触发条件
CRA 的通报义务不是"凡漏洞必报"。法规把触发范围限定在两类情形：
情形一：已被积极利用的漏洞。 判断标准是"有可靠证据表明漏洞正在被利用"，典型场景包括：
- 有可靠证据表明攻击者正在利用该漏洞；
- 出现公开的利用代码或攻击工具；
- 漏洞已被用于实际攻击；
- 制造商监测到自身产品正在被攻击。
需要注意：仅有理论分析或 PoC 代码、没有实际利用证据的漏洞，不属于强制通报范围。
情形二：严重安全事件。 包括三类：
- 已造成实际损害，如用户数据泄露、服务中断、设备被控；
- 有可能造成大规模影响，如攻击方式可复制、影响范围广；
- 涉及关键基础设施的事件。
判断"是否已被积极利用"，是通报实操中的第一道难题。它要求企业具备持续的漏洞监测与情报获取能力，而不是等事件发生后才临时研判。在这一点上，艾体宝 CRA 合规落地实践中通常采用双路径：固件层通过艾体宝 ONEKEY 持续监测组件漏洞，源码与开源组件层通过艾体宝 Mend.io 持续跟踪依赖组件的安全状态------当"值得通报"的漏洞出现时，企业才能在第一时间判断它是否影响自己的产品。
三、通报的三段式时限：24 小时、72 小时、最终报告
CRA 第 14 条将通报动作拆解为三个阶段，倒计时从制造商"知晓"漏洞的那一刻开始：
| 阶段 | 时限 | 提交内容 |
|---|---|---|
| 早期预警 | 24 小时内，不得无故延迟 | 漏洞已被利用的事实、涉及的成员国（如适用） |
| 正式通报 | 72 小时内 | 漏洞基本情况、利用方式、影响范围、临时或永久缓解措施、用户可采取的措施 |
| 最终报告 | 被积极利用的漏洞：纠正或缓解措施可用后 14 天内；严重安全事件：72 小时通报后 1 个月内 | 漏洞/事件的严重性与影响、恶意利用行为者信息（如有）、安全更新或纠正措施详情 |
"知晓"的来源有四类：
- 自主检测发现；
- 用户或安全研究员反馈；
- 第三方安全公告；
- 外部漏洞情报源（如 CVE、ENISA、CERT 等）。
这意味着法规要求的是"知晓即启动"，而不是"查清再上报"。24 小时内只需要说明漏洞已被利用的事实，法规为信息补充留出了分阶段的空间，但没有给"等研究清楚再说"留空间。
ONEKEY 的一项行业调查显示，有 24% 的组织对漏洞及安全事件的报告感到力不从心。原因高度一致：漏洞信息分散在研发、安全、运维各部门，缺乏统一的追踪机制；风险等级与修复进度不可视化；仍依赖手工汇总和邮件沟通。在 24/72 小时的时限面前，这样的管理方式几乎不可能达标。
四、向谁通报：ENISA 单一报告平台
所有通报都通过欧盟网络与信息安全局（ENISA）搭建的单一报告平台（SRP）提交，无需向多个成员国机构分别上报------一次提交即可完成全部监管报备。这一设计显著降低了企业的多国合规负担，但也意味着：提交的内容将成为各成员国监管机构共同评估的依据，材料质量比以往任何时候都更重要。
五、不合规的后果
未履行通报义务的代价分为三层：
- 行政处罚：最高可处 1500 万欧元或企业全球年营业额 2.5% 的罚款（以较高者为准）；
- 市场准入：涉事产品可能被强制退出欧盟市场，并被要求召回；
- 商业信誉：品牌可能被列入监管黑名单，未来所有新产品上市都将面临更严格的审查。
对于已将产品铺货到欧洲渠道的企业，产品下架意味着库存与渠道的直接损失；对于计划出海的企业，合规记录将直接决定进入市场的成本。
六、9.11 只是起点：CRA 是长期合规过程
不少企业把 CRA 当作"一次性项目"------突击准备、通过检查、团队解散。这种理解偏离了法规的设计逻辑。看完整时间线：
| 时间节点 | 要求 |
|---|---|
| 2024 年 12 月 10 日 | CRA 正式生效 |
| 2026 年 9 月 11 日 | 漏洞通报义务生效，企业须建立完整的漏洞监控、研判、通报流程 |
| 2027 年 12 月 11 日 | CRA 所有要求全面适用：SBOM 交付、安全设计、全生命周期漏洞管理等 |
9.11 之后，义务并没有结束，而是贯穿产品全生命周期：新漏洞会持续披露，监测、研判与（触发时的）通报要持续进行；产品版本迭代，SBOM 要持续维护；安全更新要在支持期内持续提供；合规证据要持续留存，以备监管核查或第三方认证------关键产品（如防火墙、加密模块）必须通过欧盟授权的第三方合格评定机构认证。
因此，CRA 真正考验的不是"赶在节点前交材料"的能力，而是企业是否拥有一套覆盖"组件可见、漏洞可控、证据可证"的 CRA 合规闭环。这也决定了工具选型的方向：一次性扫描工具只能解决时点问题，持续监测、自动化证据沉淀与流程集成，才是长期合规的关键。
七、最后 11 天，企业可以做什么
在生效前的窗口期，企业至少可以完成五项准备：
- 梳理通报决策流程：明确四类"知晓"来源（自主监测、外部反馈、第三方公告、漏洞情报）的责任人与判断标准，确保漏洞出现时，有人能在第一时间做出"是否通报"的判断；
- 准备通报材料模板：24 小时早期预警、72 小时正式通报、最终报告三个阶段的材料框架预先备好，事件发生时照单填写，而不是从零起草；
- 确认 ENISA 平台注册状态：确保通报通道在事件发生前可用；
- 核对漏洞监测覆盖：固件类产品确认组件漏洞的持续监测能力（如艾体宝 ONEKEY 的固件分析与 7×24 监控），软件类产品确认源码与开源组件的持续监测（如艾体宝 Mend.io 的 SCA 持续监测与零日漏洞响应），避免出现"从外部公告才得知自己产品有漏洞"的被动局面；
- 做一次通报演练：模拟一起高危漏洞事件，把从发现、研判到起草通报的全流程走一遍，暴露跨部门协作与材料准备上的问题。
合规的时间节点不会改变，但合规能力可以积累。从现在开始建立机制，好过事件发生时被动应对。
常见问题 Q&A
Q1：PoC 代码或理论分析的漏洞，也会触发通报义务吗？
不会。CRA 通报义务仅针对"已被积极利用的漏洞"和"严重安全事件"两类情形。仅有理论分析或 PoC 代码、没有实际利用证据的，不属于强制通报范围。
Q2：24 小时早期预警只能提供有限信息，后续补充会被处罚吗？
不会。法规采用三段式设计：24 小时内只需说明漏洞已被利用的事实与涉及的成员国，详细信息在 72 小时正式通报和最终报告中补充。分阶段补充是法规的正常机制，真正的风险是延误或隐瞒不报。
Q3：第三方开源组件的漏洞，需要我们通报吗？
需要评估。制造商对产品的整体安全负首要责任，即使漏洞来自开源组件或供应商组件，也要完成评估、修复，触发通报条件时同样要履行通报流程。这也是 CRA 强调 SBOM 与供应链管理的原因。
Q4：通报义务对已上市的老产品适用吗？
适用。CRA 的安全义务覆盖产品全生命周期，已上市产品同样需要持续履行漏洞管理、安全更新支持等义务，出现符合触发条件的漏洞时同样执行通报流程。
Q5：从零开始建立通报能力，需要多久？
流程本身（决策机制、材料模板、平台注册）可以在数周内建立，但支撑通报的监测、研判与证据能力需要持续建设。行业实践（如艾体宝 CRA 合规落地方案）通常采用"评估---试点---规模化"三步路径，12-16 周建立核心能力，之后转入持续运营。
Q6：通报义务与 2027 年 12 月的全面合规是什么关系？
通报义务是第一个生效的强制节点。2027 年 12 月 11 日起，CRA 全部要求（SBOM 交付、安全设计、全生命周期漏洞管理等）全面适用。以通报义务落地为切入点，逐步建立覆盖产品全生命周期的合规体系，可以避免 2027 年再次突击应对。