现代 IoT 产品很少完全由单一公司独立开发。蜂窝通信模块、无线调制解调器、连接协议栈以及安全组件，通常由专业供应商开发，再由 OEM 集成为最终产品。CRA 在制定时已经考虑到了这种供应链结构。它并不要求 OEM 接管供应商内部的安全运营工作，但它会将所有被集成的组件视为同一产品的一部分，而这个产品只对应一个最终负责的制造商 —— 即将产品投放市场的 OEM。而这，正是如今许多 IoT OEM 在 CRA 下真正面临的核心矛盾。
对于 IoT OEM 而言，CRA 的供应链责任最终集中在六个方面。其中五项在法规中定义相对明确，另一项 —— 供应商尽职调查（due diligence）—— 则仍然保留较大解释空间，并很可能在后续实施细则与监管实践中逐渐明确。这一点非常重要。因为：
CRA 文本定义的是法律底线。在此基础上，ENISA 指导文件、欧盟委员会建议以及 EN 18031 标准，正在逐渐形成新的监管预期，包括：
当 OEM 将第三方连接模块集成进产品时，CRA 会将其视为：
一个产品，一个最终责任主体。
如果模块供应商本身也直接向欧盟市场销售模块，那么它同样可能属于 CRA 下的制造商。但最终产品责任仍然属于 OEM。
这带来了一个现实问题：OEM 的合规能力，往往高度依赖供应商配合。但 CRA 并不会因此降低 OEM 的责任。
OEM 无法：
因此，供应商合同会成为：
CRA 责任与 OEM 实际执行能力之间的运营桥梁。
越来越多的供应商协议需要明确：
这些内容不能再依赖默认理解，而需要明确写入合同。
CRA 第 13(8) 条要求至少五年的安全支持周期。但模块供应商的产品路线图通常独立于 OEM 产品生命周期。这意味着：OEM 产品仍处于 CRA 支持周期内时，模块供应商可能已经停止支持。这是 CRA 带来的最困难运营问题之一。
此时 OEM 通常只剩下三种昂贵选择：
法律上可能成立，但从长期监管角度看风险会越来越高。
通常并不可行。OEM 往往无法获得源码，也无法真正长期接管模块攻击面。
架构上最干净，运营上最昂贵。因为这通常意味着：
为了降低 CRA 下的长期风险，越来越多 OEM 开始在产品设计初期就加入：
原因很简单：在早期阶段为“可替换性”进行设计，远比后期围绕生命周期约束进行重构成本低得多。
无论供应商合同如何约定，有三项责任 OEM 无法转移。
根据 CRA 第 14 条，“becoming aware”不仅包括“已经知道”，还包括 OEM “合理情况下应当知道”。如果某个模块内部软件组件的 CVE 已经公开存在于 NVD 中，监管机构未必会接受：
“供应商还没有通知我们”
作为延迟行动的理由。
即使供应商协议中写明“供应商负责 CRA 合规”，这也只能转移商业责任，而无法转移监管责任。监管机构最终追责的仍然是 OEM。
OEM 在 CRA 第 14 条下的报告义务，是按照 OEM 自身的法定时限计算的。如果供应商需要六周才能提供补丁，而 OEM 在六周后才开始履行报告义务，那么合规风险实际上从第一天就已经产生，而不是第六周。
真正的问题已经不再是：
“未来应该逐步做哪些事情？”
而是：
“哪些能力必须在 2026 年之前建立完成？”
以下三项已经构成最低运营基线。
建议采用：
仅满足“顶层依赖”很快就会变得不够。
至少需要包括：
三者缺一不可。
真正困难的，并不是承诺“五年”。而是供应商是否真的能够在运营上支撑五年。
这些能力虽然尚未被 CRA 明确强制要求，但已经逐渐成为明显监管预期。
OEM 越来越需要能够回答：
“哪些已部署设备运行着哪些模块固件版本，以及它们受到哪些已知 CVE 影响？”
如果缺乏这种可见性，CRA 第 14 条时钟可能已经开始，而 OEM 甚至还无法确定影响范围。
OEM 不能完全依赖供应商通知。最低限度通常包括监控：
在集成之前，OEM 越来越需要对以下内容形成可审计评估：
OEM 与供应商需要在事故发生前提前明确：
对于多数 OEM：
因为真正依赖基础设施建设的能力，往往最需要时间。
组织是否能够在 48 小时内回答下面这个问题：
“这台设备当前运行的是哪个模块固件版本？它受到哪些已知漏洞影响？”
如果不能，那么整个运营合规体系很可能仍然不完整。
CRA 并不会根本改变 IoT 产品的工程实现方式。它改变的是：
谁对最终产品的安全结果承担责任。
那些能够在 2026 年 9 月之前真正建立供应链可见性的 OEM，很可能会成为最先获得监管机构、客户以及采购体系信任的一批企业。
