2026年9月欧盟CRA报告义务生效：采购联网设备前，买家要向供应商确认什么？
联网设备的合规不再止于“出厂时安全”。买家还要确认：产品上市后谁监控漏洞、谁在24小时内报告、谁负责修复，以及安全更新能持续多久。
欧盟《网络韧性法》（CRA）覆盖“带数字元素的产品”，常见例子包括联网摄像机、工业网关、智能家电、路由器、控制器和带软件的机械设备。欧盟委员会确认，从2026年9月11日起，制造商要报告已被主动利用的漏洞和造成严重影响的安全事件。
为什么报告义务会改变采购流程？
时间要求很短
制造商发现相关问题后，通常需要在24小时内提交预警，并在72小时内提交完整通知。对买家来说，真正的风险是：供应商没有持续监控机制，等客户先发现问题时，法定时钟已经开始走。
“能做硬件”不等于“能维护软件”
不少设备供应商擅长生产，却把固件交给外包团队。买家应确认源代码、签名密钥、升级服务器和漏洞处理职责掌握在谁手里，避免产品交付后无人能够修复。
CRA采购五项检查表
| 检查项 | 买家应确认什么 | 可接受证据 |
|---|---|---|
| 安全联系人 | 事件发生后谁在24小时内响应 | 专用邮箱、值班与升级流程 |
| 漏洞处理 | 如何接收、评估和关闭漏洞 | 漏洞披露政策、工单样例 |
| 更新机制 | 更新是否签名、可回滚 | 更新流程、测试记录 |
| 支持期限 | 安全更新提供到哪一天 | 产品支持声明、合同条款 |
| 软件清单 | 产品用了哪些第三方组件 | SBOM或等效组件清单 |
RFQ和合同应该怎么写？
RFQ阶段
- 说明产品是否联网、是否远程管理；
- 要求列出主要软件组件和云端依赖；
- 询问安全更新方式与预计支持年限；
- 要求说明严重事件的内部升级路径。
合同阶段
合同应明确通知时限、修复优先级、补丁交付方式、停产后的支持期限，以及供应商更换关键软件组件时是否需要提前告知。不要只写“产品应符合CRA”，因为这句话无法分配实际工作。
验收阶段
除了功能测试，还应验证默认密码、访问控制、更新签名、日志、恢复出厂设置和离线升级。测试发现的问题要有关闭记录，不能只在邮件里说“已处理”。
海外买家最容易忽略的三个问题
- 产品由中国工厂制造，但欧盟市场上的品牌方可能才是法律意义上的制造商；
- 云服务停止可能让设备失去功能，合同要处理服务连续性；
- 一个漏洞可能来自第三方开源组件，供应商仍需具备识别和响应能力。
适用边界
不同产品可能同时受到CRA、无线设备、机械、医疗器械或其他行业规则约束。本文提供采购管理框架，不替代产品分类、合格评定或欧盟法律意见。
FAQ
CRA是不是只管软件公司？
不是。只要实体产品包含数字功能并满足适用条件，硬件制造商、品牌方和进口商都可能受到影响。
买家一定要拿到完整源代码吗？
不一定。多数采购可先要求SBOM、更新承诺、漏洞处理流程和必要的托管安排，是否需要源代码取决于风险和业务连续性要求。
现在最先应该改什么？
先在RFQ中增加“安全更新年限、漏洞联系人、事件通知时限、组件清单”四个字段。
联网设备的采购目标不能只是按时交货，而应包括整个支持周期内可持续修复。
真正可采购的“安全产品”，是供应商在问题出现后仍能被找到、能及时报告、能交付补丁的产品。
参考来源
Compliance with connected devices is no longer limited to "security at the factory." Buyers also need to confirm: who monitors vulnerabilities after the product is launched, who reports them within 24 hours, who is responsible for fixing them, and how long security updates will last.
The EU's Cyber Resilience Act (CRA) covers "products with digital elements," common examples including connected cameras, industrial gateways, smart appliances, routers, controllers, and machinery with software. The European Commission has confirmed that from September 11, 2026, manufacturers must report vulnerabilities that have been actively exploited and security incidents that have caused serious impact.
Why will reporting obligations change the procurement process?
Short timeframes
Manufacturers typically need to submit an alert within 24 hours and a full notification within 72 hours after discovering a problem. For buyers, the real risk is that suppliers lack a continuous monitoring mechanism, and by the time customers discover the problem, the legal timeline has already begun.
"Being able to make hardware" does not equal "being able to maintain software"
Many equipment suppliers are skilled at manufacturing but outsource firmware development. Buyers should confirm who has control over the source code, signing keys, upgrade servers, and vulnerability handling responsibilities to avoid situations where no one can fix the issues after product delivery.
CRA Procurement Five-Point Checklist
| Checklist | What should the buyer confirm? | Acceptable evidence |
|---|---|---|
| Security Contact | Who responds within 24 hours of an incident? | Dedicated email address, on-call and escalation process |
| Vulnerability Handling | How to receive, assess, and close vulnerabilities? | Vulnerability disclosure policy, ticket example |
| Update Mechanism | Are updates signed and rollback possible? | Update process, test records |
| Support Period | Until what date are security updates provided? | Product support statement, contract terms |
| Software Inventory | Which third-party components does the product use? | SBOM or equivalent component list |
How should RFQs and contracts be written?
RFQ Phase
- Specify whether the product is connected to the internet and remotely managed;
- Require a list of major software components and cloud dependencies;
- Inquire about security update methods and expected support periods;
- Require a description of the internal upgrade path for critical incidents.
Contract Phase
The contract should clearly specify notification deadlines, fix priorities, patch delivery methods, post-discontinuation support periods, and whether advance notice is required when the supplier replaces critical software components. Do not simply state "the product should comply with CRA," as this statement does not provide concrete work.
Acceptance Phase
In addition to functional testing, verify default passwords, access controls, update signatures, logs, factory reset, and offline upgrades. Issues discovered during testing must be documented and closed; do not simply state "resolved" in emails.
Three Issues Overseas Buyers Often Overlook
- The product is manufactured in a Chinese factory, but the brand owner in the EU market may be the legal manufacturer.
- Cloud service outages may render the device unusable; contracts must address service continuity.
- A vulnerability may originate from a third-party open-source component; the supplier still needs the ability to identify and respond to it.
Applicable Boundaries
Different products may be subject to CRA, wireless equipment, machinery, medical devices, or other industry regulations simultaneously. This document provides a procurement management framework and does not replace product classification, conformity assessment, or EU legal advice.
FAQ
Does the CRA only regulate software companies?
No. Hardware manufacturers, brand owners, and importers may all be affected as long as the physical product contains digital functionality and meets applicable conditions.
Does the Buyer Always Need Complete Source Code?
Not necessarily. Most procurements can begin by requesting an SBOM, updated commitments, vulnerability handling procedures, and necessary hosting arrangements. Whether source code is needed depends on risk and business continuity requirements.
What Should Be Changed First?
First, add four fields to the RFQ: "Security Update Years," "Vulnerability Contact Person," "Incident Notification Deadline," and "Component List."
The procurement goal for networked devices should not only be on-time delivery, but should include sustainable remediation throughout the entire support cycle.
A truly procureable "security product" is one where the supplier can still be found after an issue occurs, can report it promptly, and can deliver patches.