CRA 第 14 条报告义务已于 2026 年 9 月 11 日开始适用，而且并不只针对新产品。对于已经进入欧盟市场的存量产品，制造商同样需要建立漏洞影响分析、24/72 小时报告和跨团队响应能力。
不少企业把 2027 年 12 月 11 日当作 CRA（Cyber Resilience Act，网络韧性法案）的“生死线”，觉得还有一年多可以慢慢准备。但这个理解漏掉了两个关键点：
.avif)
CRA 2024 年底就已经生效，但条款是分阶段落地的：
从 2026 年 9 月 11 日起，一旦触发报告条件，流程是这样的：
报告通过 ENISA 的 SRP（Single Reporting Platform，单一报告平台）提交。这里最大的误区是以为“24 小时”要把漏洞修完、调查报告写完。其实不是——CRA 允许分阶段报告，先报已知信息，后续再补充。真正的压力在于，计时器从企业“知悉”问题的那一刻启动，而不是等补丁做好或调查结束。假设你的安全团队得知某个第三方组件出现漏洞，且有可靠证据表明攻击者正在利用。你需要立刻回答：
如果这些问题平时没有答案，等漏洞真来了，24 小时根本不够翻代码、查版本、找负责人。这也是为什么产品清单、SBOM（软件物料清单）、版本与组件的映射关系，在 CRA 框架下不再是“合规 paperwork”——它们是应急时刻的导航图。没有这些，你连“这个漏洞到底影响了谁”都回答不上来。
.avif)
另一个常见错觉：“我们现在欧洲卖的都是几年前开发的货，等 2027 年新品按 CRA 做就行。”
不对。CRA 对 2027 年前已上市的产品确实有过渡安排，不会因为法规全面适用就自动要求全部重做合规。但第 14 条报告义务不享受这个豁免——只要产品在 CRA 适用范围内，无论什么时候进入欧盟市场，从 2026 年 9 月 11 日起就已经承担报告义务。
比如你 2024 年就在欧洲卖了一款智能网关，它当然不是按 CRA 标准设计的，但如果哪天爆出符合报告条件的漏洞，制造商照样要在 24 小时内启动流程。所以，报告义务首先冲击的是你的存量产品，而不是还在实验室里的新品。
.avif)
没必要立即搞完整套 CRA 合规，但以下三件事不能再拖：
明确信息从哪来、谁做判断、谁启动 24/72 小时流程、谁通过 SRP 提交，研发/安全/法务/管理层怎么协同。最好做一次桌面演练：假设某个第三方组件突然被利用，从安全团队收到消息到提交早期预警，完整走一遍，看看 24 小时机制是否真的跑得起来。
至少搞清楚：哪些产品已经卖进欧洲？有哪些主要型号和固件版本？哪个团队负责？用了哪些关键第三方组件？不用一上来就建复杂系统，但至少要有一份能持续维护的产品台账。否则漏洞发生时，你连“这个漏洞影响哪些欧洲产品”都要临时找人确认。
逐步把产品、固件版本、第三方组件、SBOM 和漏洞之间的关系理清楚，让安全团队收到漏洞信息后能快速定位受影响范围，而不是每次都靠研发团队逐个项目排查。
做完这些，再按产品类别和生命周期，为 2027 年 12 月的全面适用倒排完整的合规计划。那时候要准备的远不止报告——还包括安全设计、风险评估、漏洞处理、安全更新、技术文档、合格评定和全生命周期的安全维护。
CRA 的处罚不低：部分核心违规最高可罚 1500 万欧元或全球年营业额 2.5%（取较高者）。但对进入欧洲市场的企业来说，更现实的压力来自客户和供应链：CRA 准备情况和漏洞响应能力，可能成为供应商审核和采购评估的重要因素。
如果只盯着 2027 年 12 月，你会觉得还有一年多。但对已经在欧盟市场有产品的企业来说，第 14 条报告义务已从 2026 年 9 月 11 日开始适用。从现在开始，一旦出现符合报告条件的漏洞或严重安全事件，企业就要面对明确的报告时限。24 小时能不能启动判断，72 小时能不能确认影响范围，取决于企业是否已经把产品、版本、组件和漏洞之间的关系理清楚。
