9月11日，欧盟《网络弹性法案》（Cyber Resilience Act，业内简称 CRA）第14条的制造商报告义务正式强制执行。到今天，这条红线已经跑了38天。
圈内流传最广的说法是：CRA 要等到2027年12月才全面适用，现在不用急。于是大量做智能家居、消费电子、工业控制设备出海的企业，把合规排期整体推到了明年。这个判断错在把两件事当成了一件事——「全部条款适用」和「报告义务生效」根本不是同一个时间点，而真正开始计时的，恰恰是中间那一段。它既没有过渡期，也没有新旧产品豁免。
一、三段节奏里，跑起来的是中间那段
CRA 的落地节奏分三段：2024年12月10日法案生效，企业可以提前启动产品安全架构调整和合规体系搭建；2026年9月11日第14条制造商报告义务强制执行；2027年12月11日全部条款适用，新投放欧盟市场的产品必须完成全流程合规、加贴 CE 标识后方可上市。
麻烦的地方在于，2026年9月这一段的触发条件是「在售」，不是「新上市」。按欧盟委员会的口径，所有在2026年9月11日之后仍在欧盟市场流通、在售、提供服务的数字产品，无论上市年份，都要履行漏洞与事件报告义务。这意味着你在2021年出的那批网关，只要今天还挂在渠道上卖，就已经进了监管范围。老库存不是安全区，恰恰是最容易被遗忘的雷区。
还有一个更硬的规定：如果企业当前存在未修复的高风险漏洞，且修复计划跨越9月11日，即便这个漏洞是在新规生效前发现的，9月11日之后也必须依法向 ENISA 和成员国 CSIRT 上报，不上报同样触发处罚。换句话说，历史遗留漏洞不会因为时间早就被豁免，反而因为已知未修而更容易被认定。
二、先确认身份：你是不是 CRA 意义上的制造商
适用主体覆盖所有将含数字元素产品投放、流通于欧盟市场的制造商，不受企业所在地限制，中国出口企业全部纳入监管范畴。判定标准很宽：只要产品包含软件或硬件数字元素，能够直接或间接连接设备或网络，就在范围内。哪怕是只对接网关、不直接联网的嵌入式设备，也拿不到豁免。
具体品类可以这么粗分：全品类联网消费电子（智能家电、可穿戴设备、智能玩具、摄像头）、网络通信设备（路由器、防火墙、网关、交换机）、IoT 智能硬件（智能家居终端、智能电表、共享设备）、工业设备（工控终端、嵌入式固件、带数字芯片的工业组件）、商用软件与独立芯片（商用办公软件、安全芯片、TEE 可信执行环境）。真正能谈豁免的只有整车、专业医疗设备、航空航海装备这些已有专项欧盟法规覆盖的品类，而且还要结合行业规则个案判断。
开源软件的处理相对克制：只有在市场上提供、用于商业活动分发或使用的自由开源软件才落入 CRA；未被制造商货币化的开源产品不视为商业活动；单纯向非自身负责的开源项目贡献源码的开发者不适用。法案同时引入了「开源软件管理者」（open-source software stewards）这一新类别。做开源方案二次开发的企业，这里有一个可以争取的空间，但前提是你能证明 monetisation 的实际状态。
对于中国出口商，最容易踩的坑是 OEM/ODM 的责任归属。欧盟那头的客户通常是进口商或分销商，一旦出事，第一责任人是制造商。而贴牌方只要是以自己的品牌投放欧盟市场，通常就会被认定为制造商，责任甩不回方案商。很多工厂在合同里默认「软件问题由方案商负责」，这句话在 CRA 面前基本无效。
三、24小时、72小时、14天或一个月：三段时限怎么拆
报告义务针对两类事件：被积极利用的安全漏洞（actively exploited vulnerabilities），以及影响产品安全的严重安全事件（severe incidents）。时效分三段严格执行：
第一段，早期预警。发现风险后24小时内提交。第二段，完整通知。72小时内提交。第三段，最终报告。漏洞类事件在修复措施可用后不迟于14天提交，严重安全事件在一个月内提交。
提交通道是 CRA 单一报告平台（SRP），制造商只报一次。通知对象是主要营业地所在成员国的 CSIRT，除特别例外情形外，信息同时提供给 ENISA。最初接收通知的 CSIRT 会立即把通知分享给产品已投放所在领土上的其他所有 CSIRT。也就是说，一次上报，全欧同步，没有「只在小国报一下就算了」的操作空间。
这里要泼一盆冷水：24小时不是24个工作小时，也不会因为时差对中国企业额外宽限。多数工厂的漏洞响应链是「客户投诉→业务转达→研发确认→法务判断→上报」，这条链走完通常要三到五天。也就是说，只要真的触发，几乎必然超时。所以唯一可行的解法不是事后提速，而是把判断权前移——预先定义什么算「被积极利用」，让一线人员有权直接触发上报，法务和研发并行介入，而不是串行签字。
四、罚款不是最痛的，下架才是
违规企业最高可处1500万欧元或全球年营业额2.5%的罚款，相关产品还可能被强制下架或召回。对多数中小出海企业来说，1500万欧元是天花板而不是典型值，真正致命的是下架。亚马逊、OTTO 以及欧洲本土渠道一旦下架，Listing 权重归零、库存周转停摆、客户索赔接踵而来，损失往往远超罚款本身。
所以备证的目标要重新定义：不是「避免罚款」，而是「在72小时内交出一份足以让监管不启动下架程序的材料」。这两个目标对应的准备工作完全不同——前者靠法务，后者靠工程和文档。
五、五道自查关：从现在补还来得及
第一关，产品清点与归类判定。把所有在欧盟在售 SKU 拉一张表，逐条标三个字段：是否含数字元素、是否能直接或间接联网、是否属于已有专项法规覆盖的品类。这张表要能对应到报关品名和客户渠道，别只存在研发部门。
第二关，漏洞接收与监测通道。必须有一个对外公开的漏洞接收入口（安全邮箱或 PSIRT 页面），并且有人每天看。没有入口，就谈不上「发现后24小时」，因为起算点会被认定为「应当知晓」的时间。
第三关，24/72小时上报预案与责任人。写死一份 Runbook：谁有权判定「被积极利用」、谁负责 SRP 提交、备用联系人是谁、节假日怎么轮值。预案里要把 CSIRT 的选择（主要营业地所在国）提前确认好，不要事发当天才研究。
第四关，SBOM 清单与漏洞处理政策。这两份文件是监管核查时最容易要求出示的。SBOM 要能覆盖到固件和第三方组件层级，漏洞处理政策要写清楚接收、验证、修复、披露的闭环。多数企业现在搭的是「纸面体系」，核查时经不起问。
第五关，生命周期风险评估。按 CRA 第13条第2款的要求，风险评估要覆盖规划、设计、开发、生产、交付、维护六个阶段，并且要把远程数据处理和支持功能一并纳入，而不只是设计开发阶段的识别与分析。评估报告要能证明每个阶段都做了风险处置，这是2027年12月全流程合规的前置作业。
最后说一个判断：CRA 对中国出海企业的真正冲击，不在于罚款数字，而在于它把「网络安全」从技术部门的内部事项，变成了有法定时限、有强制通道、有跨域联动的对外披露义务。谁先把漏洞响应从「研发流程」改造成「合规流程」，谁就能在下一轮欧盟客户尽调里拿到主动权。反过来，等到客户来要 SBOM 和上报记录时才动手，那时候补的不是文档，是信用。