如果你卖的是智能摄像头、智能门锁、智能插座、蓝牙设备，或者需要APP连接和远程控制的产品，2026年9月11日这个时间点值得单独看一下。

但先把一件事说清楚：

9月11日不是CRA全部要求突然开始执行的日期。

欧盟《Cyber Resilience Act》（CRA）已经于2024年12月10日生效，但其主要产品义务要到2027年12月11日全面适用；提前在2026年9月11日开始执行的是Article 14规定的报告义务。

也就是说，这一阶段卖家真正要提前准备的，不是突然给所有智能硬件重新做一次“CRA认证”。

更现实的问题是：

如果产品真的出现了被攻击者利用的漏洞或者严重安全事件，公司内部有没有能力在24小时内把事情送到正确的人手里？

因为从制造商“知情”开始，时间就已经在走了。

一、先把两个日期分清：2026年9月11日和2027年12月11日不是一回事

CRA的实施不是“一刀切”。

现在最值得卖家记住的是两个节点。

2026年9月11日

开始适用的是：

Article 14报告义务。

制造商发现符合条件的：

主动被利用漏洞

或者：

对产品安全产生影响的严重事件

以后，需要按照CRA规定进行报告。

2027年12月11日

CRA主要产品义务全面适用。

包括网络安全基本要求、网络安全风险评估、技术文档、合格评定等更完整的产品合规体系。

还有一点容易被忽略：

不要因为产品是在2027年12月11日以前已经卖出去的，就默认9月11日开始的报告义务和它无关。

欧盟委员会目前明确说明，CRA报告义务适用于已经在欧盟市场提供的“具有数字元素的产品”，其中包括2027年12月11日前已经投放市场的相关产品。

所以这一次真正要检查的是：

哪些现有产品已经进入报告机制需要覆盖的范围。

二、哪些产品需要先检查？重点不是“有没有Wi-Fi”

CRA管的不是单纯“带Wi-Fi的硬件”。

它针对的是欧盟市场上的products with digital elements，也就是具有数字元素的产品。

欧盟委员会对这一概念的说明包括硬件、软件以及相关远程数据处理方案；如果产品的预期用途或者合理可预见的用途中，存在与设备或网络之间的直接或间接数据连接，就可能进入CRA范围。

所以普通跨境卖家可以先把下面几类SKU筛出来。

比如：

Wi-Fi连接产品

智能插座、路由器、智能灯具、联网摄像头等。

Bluetooth产品

智能穿戴、蓝牙控制硬件、和手机进行数据交互的设备等。

APP控制产品

智能门锁、摄像头、智能家居控制设备、远程控制产品等。

还有一个容易被忽略的类别：

软件本身。

CRA并不是只管“有一个实体盒子的电子产品”，软件产品本身也可能属于具有数字元素的产品。

所以筛SKU的时候，不建议只做一列：

有没有Wi-Fi？

更值得增加的问题是：

这个产品是否依赖数字连接、软件或者远程数据处理来完成某项功能？

当然，最终是否进入CRA范围，还需要继续看产品结构以及法规中的具体排除情况。欧盟委员会也明确指出，部分已经由其他欧盟法律覆盖的产品存在排除情形。

三、中国卖家特别要查清：谁才是CRA里的“制造商”

这个问题在OEM模式里特别容易被想当然。

很多品牌方第一反应是：

“产品是工厂做的，网络安全当然也是工厂负责。”

但CRA里的“manufacturer”，并不能简单翻译成：

谁负责开机器生产。

欧盟委员会对制造商的定义包括：自己开发或制造具有数字元素的产品，或者委托别人为自己设计、开发、制造产品，并且以自己的名称或商标进行市场投放的自然人或法人。

举一个很常见的跨境模式。

中国OEM工厂负责：

研发、打样、生产。

但最终商品使用的是：

Brand X

包装是Brand X。

Listing是Brand X。

产品以Brand X的名义进入欧洲市场。

这时候就不能简单把：

实际工厂

和：

CRA意义上的制造商

直接画等号。

尤其是品牌方委托别人开发制造、最终又以自己的名称或商标销售时，更应该把主体身份提前确认。

进口商、经销商本身也有CRA义务。例如，进口商或经销商发现产品存在漏洞或不符合相关要求时，需要采取相应措施，并在适用情况下通知制造商或监管机构。

而且还有一个很重要的情况：

如果进口商或经销商直接以自己的名称或商标投放产品，或者对产品做了符合CRA定义的重大修改，它可能会被视为制造商，并承担相应的制造商义务。

所以卖家现在真正应该确认的是：

谁以自己的名字或者商标，把这个产品投放到欧盟市场？

这个主体后面的网络安全责任链路才有意义。

四、不是发现一个Bug，就马上开始24小时倒计时

这里也非常容易被标题吓到。

CRA并不是规定：

所有Bug都必须在24小时内上报。

9月11日起重点触发强制报告的是两类情况。

第一类：主动被利用漏洞

CRA对“actively exploited vulnerability”的定义，比“发现一个漏洞”严格得多。

它指的是：

存在可靠证据表明，恶意行为者已经在未经系统所有者许可的情况下实际利用了这个漏洞。

也就是说：

研发团队在内部测试中发现一个问题，

和：

攻击者已经实际利用这个问题攻击设备，

不是一回事。

第二类：严重安全事件

CRA规定，如果事件已经造成或者可能造成产品保护重要数据或功能的可用性、真实性、完整性、保密性受到严重影响，或者导致、可能导致恶意代码被引入或执行，就可能被认定为严重事件。

所以正常的：

产品死机；

蓝牙偶尔连不上；

APP页面显示错误；

普通售后功能投诉，

并不能因为“属于智能产品”就直接等于CRA强制安全报告事件。

真正需要的是：

有人能够判断事件的性质。

这也是为什么CRA不可能只交给客服部门处理。

五、真正麻烦的是：一旦符合条件，24小时马上开始算

如果制造商已经知悉一个符合CRA Article 14条件的主动被利用漏洞或者严重安全事件，接下来不是：

“先开个会，下周再看看。”

CRA给出了明确的时间节点。

第一步：24小时

制造商需要在知情后不无故拖延，并且最迟24小时内提交Early Warning，也就是初步预警。

第二步：72小时

在知情后最迟72小时，需要进一步提交主要通知。

对于漏洞，需要提供目前能够掌握的产品、漏洞性质、利用情况以及已经采取或可供用户采取的缓解措施等信息；对于严重事件，则需要提供事件性质、初步评估和纠正或缓解措施等。

第三步：最终报告

如果是主动被利用漏洞：

在纠正或缓解措施可用之后，最终报告最迟应在14天内提交。

如果是严重安全事件：

最终报告应在72小时事件通知提交之后1个月内完成。

这些通知通过CRA **Single Reporting Platform（SRP）**进行。欧盟委员会目前表示，该平台将于2026年9月11日报告义务开始适用时投入运行；报告会进入相应CSIRT流程，并按规则提供给ENISA。

所以这里真正值得卖家警惕的不是：

“24小时特别短。”

而是：

谁算“知情”？消息什么时候真正到达负责主体？

法规计算的是制造商知情以后。

如果用户已经向客服报了安全问题，

客服放在工单里三天没人看；

技术团队知道异常，但没有向合规或管理人员升级；

工厂已经发现漏洞，但品牌方双方没有约定上报机制，

这才是实际操作里最容易出问题的地方。

六、发现问题以后，还不只是“报给欧盟”

Article 14还有一个卖家很容易忽略的动作：

用户通知。

制造商知悉主动被利用漏洞或者严重安全事件以后，需要向受影响的产品用户提供相关信息；必要时还要告诉用户可以采取哪些风险缓解或纠正措施。在适当情况下，通知范围还可能扩展到所有用户。

这意味着企业内部至少还要想清楚几个现实问题。

比如：

哪些用户受到影响？

你有没有能力联系这些用户？

产品具体哪个版本受到影响？

有没有补丁、升级方案或者临时风险缓解措施？

由谁来写用户通知？

平台卖家还会多一个现实问题：

很多终端消费者的联系方式掌握在平台端，而不是品牌自己手里。

所以未来真正发生网络安全事件时：

报告监管机构

和：

通知用户

其实是两条需要同时准备的工作线。

这也是为什么产品版本、软件版本、销售市场、用户范围这些数据，不能平时完全不管，出事以后再临时找。

七、9月11日前，卖家先把这5件事定下来

现阶段不需要把CRA所有2027年的产品义务一次性做完。

但如果有联网产品，我建议至少把下面五件事情先确定。

01｜列出联网SKU

先把产品池筛出来。

哪些产品有：

Wi-Fi；

Bluetooth；

APP控制；

云端或远程功能；

软件依赖。

先知道哪些SKU值得进一步检查。

02｜确认制造商主体

不要在表格里简单写：

“工厂负责。”

至少把：

品牌主体；

实际工厂；

进口商；

经销商；

欧盟相关主体

之间的角色关系确认清楚。

03｜确认技术联系人

一旦出现漏洞：

谁能找研发？

谁能找工厂？

谁能够判断：

这是普通Bug，

还是已经进入网络安全事件层面？

如果真正负责CRA的人连工程师联系方式都没有，24小时流程几乎一定会变得很被动。

04｜建立内部24小时升级机制

最好把信息路径写出来。

比如：

客服 / 平台反馈 / 用户

↓

技术人员

↓

网络安全或合规负责人

↓

负责CRA报告的主体

CRA要求Early Warning在制造商知情后最迟24小时提交。

所以内部流程需要解决的是：

安全问题不能在公司里躺两天。

05｜提前熟悉报告流程

至少提前确定：

谁负责提交？

产品基础信息放在哪里？

需要找哪些技术人员提供判断？

SRP怎么走？

出现事件以后由谁通知用户？

不要等真正进入24小时倒计时时，再第一次讨论这些问题。

八、9月11日前，最该解决的是“发现问题以后怎么办”

CRA还有很多更完整的产品义务。

网络安全风险评估。

技术文件。

漏洞处理。

合格评定。

用户信息。

支持周期。

这些主要要求会随着2027年12月11日全面适用节点进一步进入企业日常产品合规体系。

但眼下离卖家最近的9月11日，应该先抓住三个判断。

第一

9月11日开始的是Article 14报告义务。

不要误解成所有CRA主要产品要求都在这一天全面适用。

第二

联网产品先查范围，再查自己的角色。

Wi-Fi、蓝牙、APP控制只是常见场景。

真正的判断仍然是：

它是不是CRA范围内的具有数字元素产品，以及谁是法规意义上的制造商。

第三

24小时最终是公司内部流程问题。

法规规定24小时。

但决定你能不能做到的，是：

客服有没有升级机制；

品牌和工厂有没有技术联系人；

谁负责判断事件；

谁负责报告；

产品资料能不能迅速拿出来。

所以我觉得现阶段CRA准备最应该落到三个东西：

产品清单

责任人

事件流程

先把这三个东西跑通，比只转发一份CRA法规PDF有用得多。

下一篇｜09 EUDR

下一篇继续《欧洲卖家经营手册》第一季第二阶段：

2026—2027必须开始准备的新变化。

CRA重点在：

产品网络安全出了问题以后，

谁发现、谁判断、谁处理、谁报告。

下一篇会把视角转到另外一条完全不同的供应链问题：

卖木制家具去欧洲，2026年底前先查清这件事

重点不准备泛讲一遍EUDR。

会直接站在家具、木制品卖家的实际经营角度拆：

产品到底有没有落入EUDR商品范围；

木材来源要追到什么程度；

供应商能不能提供资料；

小微企业和其他企业时间节点有什么区别；

如果品牌只是从工厂采购成品家具，哪些数据仍然要提前向上游追。