一、真实场景：24小时倒计时已经开始
假设你是一家智能路由器厂商，今天（9月15日周一）上午10点，安全团队突然发现：你们的某款路由器固件有个严重漏洞，黑客已经在暗网发布了攻击工具，多个用户报告设备被用来发起DDoS攻击。
按以往的处理方式，你可能需要一周时间：先确认问题、评估影响、制定方案、通知经销商、准备公告。
但现在不行了。从你"知道"这个漏洞被利用的那一刻起，必须在24小时内向欧盟监管机构提交早期预警报告。考虑到北京和布鲁塞尔有7小时时差，实际可用时间可能只有18-20小时。你需要在这段时间内完成技术确认、法务审核、翻译、通过ENISA的平台提交报告——而这一切必须跨越时差、语言和多个部门的协作。
这不是演习，而是从2026年9月11日起，每一家在欧盟卖联网产品的中国企业都可能遇到的真实情况。
二、到底哪些企业和产品受影响？
产品范围比你想的要广。
只要产品能联网——不管是直接联网还是间接连接设备、网络、数据——都可能被纳入监管。硬件、软件、固件、云服务，甚至单独销售的芯片、模组、SDK这些数字组件，都可能有独立的报告责任。
举几个例子：
- 路由器厂商要报告路由器的漏洞
- 给路由器供货的Wi-Fi芯片商，如果芯片单独在欧盟卖，也要报告芯片漏洞
- 提供远程管理云服务的，要报告服务层面的安全事件
时间节点很关键。
很多人以为CRA是2027年的事，这是个危险的误解。虽然大部分产品安全要求要到2027年12月才开始执行，但漏洞报告义务从2026年9月11日就生效了，而且明确覆盖之前已经卖到欧盟的旧产品。
换句话说，你不能等到2027年再准备，必须现在就盘点所有在售和已售产品的漏洞管理能力。
谁是责任主体？
这个问题比较复杂，不是看你在哪生产，而是看你在市场上扮演什么角色：
情况1：自有品牌出口 - 你以自己的品牌在欧盟卖产品，你就是制造商，承担全部责任。
情况2：OEM/ODM代工 - 你给欧洲品牌商代工，产品用他们的牌子卖，那么品牌商是法律上的制造商。但你仍然要向他们提供漏洞信息、补丁和技术文件，实际上还是深度参与。
情况3：卖组件 - 你单独向欧盟卖物联网模组、芯片这类组件，你可能对组件本身的漏洞负责，即使它最终被别人集成到终端产品里。
情况4：品牌转移 - 如果进口商或分销商用自己的品牌卖你的产品，或者对产品做了实质性修改（比如定制固件），他们可能变成制造商。
所以你必须搞清楚：每款产品、每个版本、在每个欧盟国家、通过哪个进口商或分销商销售、谁是法律上的责任主体。
三、必须报告的两类事件
第一类：主动被利用的漏洞(AEV)
什么时候要报？ 有可靠证据表明黑客已经在恶意利用你产品的漏洞。
注意："发现漏洞"本身不需要立即报告。如果漏洞是通过安全测试、漏洞赏金计划发现的，没有恶意利用的证据，按正常的漏洞披露流程处理就行。
但一旦有证据显示漏洞被恶意利用了——比如威胁情报显示有野外攻击、用户报告异常行为、发现恶意代码样本——就必须启动报告流程。
报告时限：
- 24小时内：提交早期预警
- 72小时内：提交产品详情、漏洞技术信息、利用情况及缓解措施
- 修复后14天内：提交最终报告
第二类：严重安全事件(SI)
什么时候要报？ 事件严重影响产品的可用性、真实性、完整性或保密性，或可能导致恶意代码执行。
典型场景包括：大规模数据泄露、供应链攻击导致固件被植入后门、云平台遭受持续入侵等。
报告时限：
- 24小时内：提交早期预警，说明是否疑似违法或恶意行为
- 72小时内：提交事件性质、初步评估及已采取措施
- 首次报告后1个月内：提交最终报告
报告提交和信息传播
所有报告通过ENISA的"CRA单一报告平台"(SRP)提交。根据最新消息，平台已于2026年9月11日上线，界面是英文，需要用个人EU Login账号登录并开启多因素认证，首发版本暂时没有API接口。
重要：你提交的报告不是完全保密的。
报告提交后会同时送到相关的计算机安全事件响应团队(CSIRT)和ENISA，CSIRT会向其他成员国的CSIRT共享信息。在特殊情况下，监管机构可能要求公开严重事件。修复后的漏洞信息可能经你同意后进入欧盟漏洞数据库。
所以在报告时要采用"最小必要信息"原则，只提供法定要求的信息，把详细的技术分析、客户信息、源代码等敏感材料作为受限的补充材料，并明确标注保密要求。
四、中国企业面临的实际挑战
挑战1：24小时时限对组织能力的考验
这是最直接的挑战。24小时听起来不短，但考虑到：
- 北京和布鲁塞尔有7小时时差
- 如果漏洞在周五晚上发现，24小时后是周六
- 春节、国庆等中国法定假期与欧盟工作日不同步
- 需要安全团队确认→产品团队评估→法务审核→通知欧盟代表→协调渠道商
- 需要在技术还没完全确认时就提交"早期预警"
建议做法： 建立7×24小时的产品安全事件响应团队(PSIRT)，明确"知悉时间"的定义（比如威胁情报系统首次告警时间，要有UTC时间戳记录）。把内部通报时限设为4小时以内，给外部24小时期限留出缓冲。
挑战2：供应链透明度不足
CRA要求你识别和记录组件漏洞，建立协调漏洞披露政策，维护软件物料清单(SBOM)。
但现实是：一个智能网关可能用了开源Linux内核、第三方Wi-Fi芯片的闭源驱动、云服务商的SDK、多个开源加密库。当某个OpenSSL版本爆出严重漏洞，你需要快速确认：
- 哪些产品、哪些固件版本用了受影响的版本？
- 在你的产品环境中这个漏洞能不能被利用？
- 有没有野外利用证据（决定要不要报AEV）？
- 怎么通知所有受影响用户？
- 补丁什么时候能出来？
常见的问题：
- 供应商不及时通知漏洞，你只能从公开渠道知道
- 同一组件被集成到几十个型号和多个固件分支，影响范围难以快速确定
- 旧版本产品缺少完整的构建环境和依赖清单
- 某些开源组件已无人维护，拿不到官方补丁
建议做法： 建立完整的SBOM管理体系，至少包括顶层依赖的组件名称、版本、来源和已知漏洞。与关键供应商签合同时，明确要求4小时内通报漏洞、提供SBOM和补丁的义务。对开源组件建立定期扫描和版本升级机制。
挑战3：旧产品的长期支持成本
CRA要求支持期原则上至少5年；每个安全更新应至少保持可获得10年或支持期剩余时间（取较长者）。
假设你在2022-2025年间向欧盟卖了5代智能路由器，每代有3-4个硬件版本和十几个固件分支。按CRA要求：
- 所有产品从今天(9月11日)起就受报告义务约束
- 2022年的产品至少要支持到2027年
- 2025年9月发布的一个安全补丁，要保持可获得状态到2035年
- 你需要为所有在支持期内的产品维护：OTA升级服务器、固件仓库、用户通知渠道、技术文档、客服支持
这直接影响你的产品策略：
- 要不要继续在欧盟卖利润率低的旧产品？
- 要不要主动召回无法经济地提供长期支持的产品？
- 怎么规划产品终止支持(EOL)和替换方案？
挑战4：违规的代价不只是罚款
很多企业只关注罚款金额（最高1500万欧元或全球年营业额2.5%），但更直接的市场影响包括：
- 限制销售：监管机构可以禁止你继续卖特定型号或所有产品
- 撤市与召回：要求你从市场召回已售产品，成本远高于罚款
- 品牌声誉损害：公开的违规记录影响后续市场准入和客户信任
- 连锁反应：欧盟的违规记录可能影响其他市场（如英国、澳大利亚）的合规评估
而且，微型和小型企业仅在"24小时早期预警逾期"这一项有窄范围的从轻处理，并不意味着可以免除报告、修复、文档或用户通知义务。
五、现在就要做的事情
既然9月11日开始生效，企业必须立即采取行动。我把它分成三个优先级：
紧急任务（本周内完成）
1. 指定负责人和建立响应团队
- 指定一名高管（CSO或CTO）负责CRA合规
- 组建跨部门的产品安全事件响应团队(PSIRT)
- 确保团队有7×24小时响应能力，指定替补联系人
2. 准备报告账号
- 为报告人员准备EU Login账号
- 设置多因素认证
- 熟悉SRP平台操作（已于9月11日上线）
3. 完成产品盘点
列出所有在欧盟市场销售或已售的产品，至少包括：
- 产品名称、型号、固件/软件版本
- 品牌（自有品牌还是OEM/ODM）
- 销售国家和数量
- 进口商、分销商和授权代表信息
- 当前支持状态和计划终止日期
- 明确每款产品的法律责任主体
4. 准备报告模板
为24小时、72小时和最终报告准备英文模板，至少包括：
- 制造商信息和产品基本信息
- 事件发现/知悉的日期和时间（UTC）
- 事件性质和严重性评估
- 漏洞类型和影响
- 已采取的措施
- 用户防护建议
5. 建立应急流程
- 定义"知悉时间"的准确判断标准（建议用威胁情报系统首次告警的UTC时间戳）
- 制定"发现→分类→报告→修复→用户通知"的标准操作程序(SOP)
- 建立SRP平台不可用时的应急流程（先联系指定CSIRT，平台恢复后补交）
近期任务（1-3个月内完成）
6. 建立漏洞管理体系
- 设置公开的漏洞披露入口（security@域名或专门网页）
- 制定并发布协调漏洞披露(CVD)政策
- 统一使用产品版本号、CVE/CWE/CVSS标识符、SBOM格式
- 建立漏洞数据库，记录历史漏洞和修复措施
7. 提升供应链透明度
- 生成至少顶层依赖的SBOM（建议用SPDX或CycloneDX格式）
- 对关键供应商进行漏洞通知和补丁能力审计
- 建立开源组件的版本跟踪和自动扫描机制
- 为旧产品补充构建环境和依赖清单
8. 更新合同
在与品牌商、进口商、分销商及关键供应商的合同中加入：
- 4小时内部升级和通报条款
- SBOM提供义务
- 漏洞通知和补丁交付时限
- 召回和修复的成本分担
- 审计和文档访问权
9. 实战演练
进行至少一次完整的桌面演练，覆盖：
- 不同时区和假期场景
- 不同严重程度和产品范围
- SRP平台操作和信息填写
- 内部升级和外部沟通
- 时间节点记录和合规证据保存
中期任务（2027年12月前完成）
10. 满足全面产品安全要求
- 完成CRA附件I的风险评估和技术文档
- 实现安全默认配置、签名更新、回滚保护和安全卸载功能
- 判断产品是否属于重要或关键类别（如工业防火墙、智能卡、HSM等），必要时安排第三方评估
- 完成符合性声明和CE标志
11. 建立生命周期管理
- 明确每款产品的支持期（至少5年）、更新保留期（10年）和EOL日期
- 建立用户注册和通知机制
- 为长期支持建立可持续的OTA基础设施和客服资源
12. 整合多规合规
将CRA与其他欧盟法规的事件报告要求做映射：
- GDPR（个人数据泄露72小时报告）
- NIS2指令（关键基础设施网络安全事件报告）
- DORA（金融领域数字运营韧性）
- 客户合同中的事件报告条款
不要以为提交一次CRA报告就完事了，实际上可能需要向不同监管机构提交不同格式的报告。
六、给企业的建议
最容易犯的错误是把CRA当成"2027年的事"，等到2027年再调整产品设计。但实际上，从今天（9月11日）开始，所有已在欧盟市场的产品就必须遵守漏洞报告义务。如果你现在还没有建立24小时响应能力、没有完成产品盘点、没有明确责任主体、没有准备报告模板，一旦发生需要报告的事件，几乎不可能在24小时内完成合规。
最优先的不是重新设计所有产品，而是：
1. 把责任归属搞清楚（谁是制造商，谁负责报告）
2. 把24/72小时流程跑通（组织、系统、模板）
3. 把在售和已售产品清单建起来（哪些产品在哪卖了多少）
4. 把SBOM和供应链漏洞通知机制建起来（出问题能快速定位）
5. 把SRP账号和应急联系方式准备好（平台能立即用）
关于信息保密，不要以为向监管机构报告的信息会严格保密。CSIRT会向其他成员国传播，特殊情况下可能要求公开。所以报告时只提供法定要求的最小必要信息，敏感材料另外标注保密要求。同时，涉及客户日志、个人信息的数据传输，还要符合中国《数据出境安全评估办法》和《个人信息保护法》。
关于旧产品，如果某些旧产品无法经济地提供长期支持，要尽早评估是否主动停止销售或召回，不要等到出事再被动应对。
最后需要提醒：欧委会发布的FAQ是非约束性解释，具体产品分类、报告程序和成员国执法尺度可能有差异。制定合规方案时，建议结合欧盟当地律师或专业合规机构进行确认，特别是对于重要或关键类别产品、大规模销售产品和高风险场景。
从明天开始，24小时倒计时随时可能启动。你准备好了吗？
