产品卖出去之后发现漏洞，24小时内要能报上去

一家做智能门锁和配套App的中国厂商，产品卖到德国和荷兰。某个周五晚上，海外安全研究员在社交平台上发帖说，某型号门锁的配网模块存在漏洞，已经有人在利用。研发负责人第一反应是“下周一开会排期修”。但按欧盟现行规则，这个周末就可能是法定报告时限内。

以上是假设场景，对应的是一项已经开始执行的义务。

已经发生的事

【事实】欧盟委员会数字战略网站“Cyber Resilience Act – Reporting obligations”页面写明：自2026年9月11日起，制造商须报告影响带数字元素产品安全的“被积极利用的漏洞”和“严重事件”；须在知悉后24小时内提交早期预警，72小时内提交完整通报；被积极利用的漏洞，最终报告不迟于纠正措施可用后14天；严重事件的最终报告在72小时通报后一个月内提交。开源软件管理者（stewards）的报告义务依第71条第2款自2027年12月11日起适用。

【事实】同一页面说明，制造商只需通过“CRA单一报告平台（SRP）”报告一次，通报发给其主要营业地所在国的CSIRT（计算机安全事件响应团队），除特别例外情况外同时提供给ENISA；首个接收的CSIRT会把通报转给产品已上市的其他成员国CSIRT。委员会于2025年12月11日通过了一项授权法案，规定CSIRT基于网络安全理由推迟转发的条件。

【事实】ENISA的SRP页面写明：SRP由ENISA开发、运营和维护，自2026年9月11日起制造商须通过它提交上述强制通报；平台于2026年10月20日升级到1.2.1版，邀请次要“指定代表（AR）”或备份人员的流程有变；ENISA为指定代表发布了注册、提交与更新通报等指南，最近更新在2026年9月9日至10日。

变化的机制：漏洞响应从“售后”前移到“产线”

24小时这个时限决定了：企业不可能在知悉漏洞之后再去弄清“这个模块用在哪些型号、卖到了哪些国家、谁有权在平台上提交”。这些信息必须在产品上市前就准备好。也就是说，合规压力会倒推到研发和生产的几个环节：

• 组件清单：每个型号用了哪些软件组件和版本，出了问题能在几小时内查到影响范围。
• 市场清单：每个型号在哪些成员国上市，因为通报会被转给这些国家的CSIRT。
• 账号与值班：平台上谁是主指定代表、谁是备份，周末和节假日有没有人能提交。

【推演】对出口欧盟的中小制造商，这项义务的实际成本主要不在报告本身，而在“知道自己卖了什么”。如果企业平时就有完整的组件和型号台账，24小时预警是一次填表；如果没有，就是一次全员排查。受益方是能快速定位影响范围的厂商和下游客户；承担成本的是缺少软件物料管理的硬件企业。可能失败的环节是“知悉”时刻的认定：一线客服或社媒运营先看到了消息却没上报，时钟可能已经开始走。何时算“知悉”的具体判断，应以委员会指南和法律意见为准，本文不作结论。

对生产的影响

• 软件组件管理变成出厂条件之一，不再只是研发团队的内部习惯。
• 产品型号、软件版本和销售国家需要能互相关联查询。
• 安全响应需要明确的对外通报责任人，而且这个人要提前在平台上注册好。

建议试验：做一次“周五晚上”演练

【建议试验】选一款在欧盟销售的产品，假设周五20:00收到一条可信的漏洞被利用报告。投入：研发、产品、法务、客服各1人，半天时间。判断指标：多长时间能列出受影响型号、软件版本和上市国家；能否在不依赖某一个人的情况下登录SRP并起草早期预警。失败条件：超过12小时仍无法确定影响范围，或唯一的平台账号持有人联系不上。演练只用于内部检验，不向平台提交任何真实通报。

边界

本文只讨论报告义务，不涉及CRA的其他要求（如产品安全设计要求和合格评定），也不构成法律意见。法规全文（第2024/2847号条例）本次未能直接读取EUR-Lex原文，相关日期和流程以欧盟委员会与ENISA官方页面为核验依据。企业是否属于“制造商”、产品是否属于“带数字元素的产品”，需结合具体情况判断。

参考资料

• European Commission, Shaping Europe's digital future: Cyber Resilience Act – Reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting （核验日期：2026-11-04）
• ENISA: Single Reporting Platform (SRP). https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp （核验日期：2026-11-04）