设备制造商与机器制造商如何转向符合 CRA 认证的连接解决方案
**《网络弹性法案》( CRA) **规定，对于开发和维护工业设备及机器中通讯连接部分的制造商，需承担长期的安全与维护责任。在我们前两篇文章中（《[CRA 正在重新定义工业连接](https://www.hms-networks.cn/tech-blog/blogpost/hms-blog/2026/04/07/cra-is-redefining-industrial-connectivity)》和[《网络弹性法案》：一场痛苦但必要的行业重塑](https://www.hms-networks.cn/tech-blog/blogpost/hms-blog/2026/04/23/cyber-resilience-act-is-painful--but-necessary)），我们探讨了这些责任的具体内容，以及为什么尽管 CRA 引入了新的预期、流程和生命周期义务，它仍然必不可少。
本系列的第三篇文章，我们将从“为什么要实现CRA”转向“如何实现CRA”。
本文将解释：为什么老旧连接技术难以达到 CRA 合规要求？以及如果设备制造商和机器制造商将旧方案更换为**现代化的、符合CRA标准的连接方案**，合规之路将如何变得事半功倍？
 
### 1. 为什么老旧连接技术难以实现 CRA 合规？

 
首先我们要问一个关键问题：**究竟是什么原因让旧有的连接方案难以对齐 CRA 的要求？**
老旧方案、内部自研方案或定制化连接方案在设计之初从未考虑过 CRA。大多数方案构建时，重点在于功能性，而非网络安全、文档记录或生命周期义务。CRA 暴露了这些方案中难以（甚至有时无法）通过追溯补救的缺口。
 
![CRA-compliance-legacy-connectivity-struggles](https://developer.qcloudimg.com/http-save/yehe-12480681/e0169fae4aff20c4d6241a91c95b7849.png)
 
**图1. **老旧连接技术在设计上并未考虑 CRA 所要求的长期安全、文档记录和生命周期义务。
以下是 HMS多年来遇到的常见问题：
#### 文档缺失或不完整

旧的连接协议栈通常缺乏：
- 设计文档
- 测试报告
- 版本历史
- 软件物料清单 (SBOM)
- 补丁记录
- 安全决策的证明

而 CRA 要求提供所有这些内容。

#### 维护主体不明确

随着时间的推移，职责往往会发生偏移。如果没有明确的责任人：
- 无人为长期的 CRA 义务负责
- 更新和漏洞处理变得断断续续
- 生命周期证据零散或缺失

#### 资源或专业知识有限

CRA 要求结构化的安全工程和持续的文档化工作。许多团队缺乏：
- 专业安全知识
- 用于持续维护的带宽
- 将“原生安全设计”流程追溯应用到旧协议栈中的资源

#### 来源或维护不明的依赖项

老旧连接方案通常包含：
- 来源不明的开源组件
- 不再维护的协议库
- 从前任团队继承的代码

CRA 要求完整的可追溯性，这在处理旧依赖项时很难实现。

#### 待更新的存量产品规模巨大

当 CRA 必须应用于整个产品组合时，上述挑战会被成倍放大。
在工业自动化领域，产品生命周期很长，设备和机器通常在产线运行 15-20 年甚至更久。因此，CRA 合规很少仅限于单一的新设计。
设备和机器制造商往往面临：
- 更新多个在售产品代际
- 维护客户仍有需求的旧型号
- 使老旧产品对齐现代 CRA 要求

与此同时，更新包含核心产品软件功能的“主机应用程序”本身就是一项重大任务。如果在此基础上还要承担老旧通讯连接部分的全面 CRA 符合性工作，内部资源很快就会捉肘见襟。

#### 连接往往是CRA落地中最难的部分

虽然 CRA 适用于完整的设备或机器，但在实践中，连接部分通常是实现合规过程中最复杂、最耗费资源的部分。
它涉及：
- 协议栈
- 安全更新机制
- 漏洞处理流程
- 生命周期文档
- 依赖项跟踪

由于大量的 CRA 要求都集中在这一领域，外包连接部分的 CRA 符合性工作可以显著减轻整体合规压力。

#### 架构并非为现代安全设计

旧的协议栈可能缺乏：
- 安全启动
- 固件签名
- 更新验证
- 回滚保护
- 版本可追溯性

在生命周期后期补齐这些功能不仅成本高昂，有时在技术上也行不通。
**简而言之：**老旧连接方案成了瓶颈，因为它当初的设计目标根本无法满足 CRA 现在的预期。

### 2. 现代化的兼容CRA连接方案能简化哪些工作？

传统连接使CRA合规变得困难，但现代化、符合CRA标准的连接解决方案可以简化大部分工作。
![CRA-compliance-workload](https://developer.qcloudimg.com/http-save/yehe-12480681/0ffd5c79d9d5648e9d705294df703318.png)
**图2. ** 替换老旧连接方案，可将大部分与 CRA 相关的安全及维护工作量从制造商身上转移。
在深入细节前，值得思考的是：
#### 替换方案如何让合规变简单？

用现代化、符合CRA标准的通讯模块或网关取代自研或过时的连接，制造商可以将大部分运营和安全工作量向外转移。
 
有了现成解决方案，CRA的核心职责由专门为长期安全和合规打造的产品和流程的供应商承担。 
突然之间，以下工作对制造商来说变得容易得多：
 
#### 更快、更安全的安全性更新

现代连接方案包含定义明确的更新机制、文档化流程和标准化的发布周期。补丁交付更迅速、更安全且质量可控。
#### 减少内部安全流程工作

制造商无需在内部建立和维护安全开发流程，而是依靠已经运行合规流程并提供必要证明的连接供应商。
#### 职责边界清晰

有了CRA兼容的连接解决方案，责任划分明确：
- 供应商负责通讯协议栈的安全
- 制造商负责产品集成和系统级决策

这消除了歧义，减少了内部协调成本。

#### 一种面向未来的方法

现代方案旨在满足不断发展的标准。随着 CRA 指南、协调标准和市场预期的演变，制造商将受益于供应商的持续支持，而无需独自应对变化。

#### 3.通过替换老旧连接方案，制造商可规避的高强度任务

转向CRA兼容的连接方案可以消除大量的技术和组织工作。以下是制造商可以避开的最耗资源的任务：
#### 维护协议安全性更新

老旧协议栈需要持续更新以实现：
- 工业协议
- 加密库
- 安全原语
- 通信接口

兼容CRA方案的将这一维护重担全部转嫁给了供应商。
#### 漏洞监测

制造商不再需要亲自追踪：
- 通用漏洞披露 (CVE)
- 开源项目安全通告
- 供应商安全告示
- 协议层漏洞

连接供应商会处理所有的漏洞监测与通报。

#### 构建并验证安全更新机制

安全启动、固件签名、更新验证、回滚保护和审计追踪都变成了供应商的职责。

#### 每次变动后的重新认证

自研协议栈的任何重大更新都可能触发重新测试或认证。而成熟方案在中心侧管理这些开销，减少了重复劳动。

#### 管理供应商证据

制造商不再需要从数十家芯片、操作系统或库供应商那里收集 CRA 声明。通讯组件本身就提供了所需的全部 CRA 文档。
#### 从实际角度看：

替换老旧连接意味着制造商不再需要亲自维护通讯安全。相反，他们采用了一种解决方案，能够实现：
- 安全更新
- 生命周期文档
- 漏洞监控

 
这让团队能够专注于产品功能集成，而非通讯维护。

### 4.制造商仍然拥有（且始终拥有）的责任

减少CRA的工作量并不意味着转嫁全部责任。^2^
即使是最好的连接方案也无法消除所有的 CRA 义务。设备制造商对整机产品的 CRA 合规性负有最终责任。
![CRA-compliance-Shared-responsibilities](https://developer.qcloudimg.com/http-save/yehe-12480681/23eb782e903db5b077a1fcc0d7f18765.png)
**图3.**有效的 CRA 合规依赖于明确定义的责任划分。
改变的是工作量的分配。使连接部分达到 CRA 合规要求所需的大部分工作可以由供应商完成，而制造商保留对整体产品的责任。 
制造商仍需负责以下内容：
#### 产品级集成

必须正确集成连接组件，包括：
- 配置
- 电气设计
- 固件交互
- 系统行为

这始终是制造商的工作。

#### 系统级风险评估

CRA 要求制造商了解完整产品在预期环境中的行为，包括：
- 网络行为
- 用户场景
- 安全交互

#### 客户沟通

制造商必须提供：
- 安全文档
- 更新沟通
- 生命周期政策
- 用户责任说明

在 CRA 框架下，整个生命周期的透明度是强制性的。
**总之，** 现成的连接解决方案显著降低了CRA的技术复杂性，但它不能取代制造商在安全产品交付中的角色。

### 结论：实现CRA合规的切实可行路径

这为准备应对 CRA 的制造商提出了最后一个问题：
**一条现实且可持续的合规路径是什么样的？**

老旧连接方案之所以让合规变得困难，是因为它在设计基因里就没有“长期安全、文档化和生命周期责任”。
将其替换为现代化的、兼容CRA的方案可以卸下许多繁重的义务^3^，包括：
- 协议维护
- 漏洞监测
- 安全更新机制
- 重复认证
- 依赖项文档管理

虽然制造商仍需掌控系统级安全和产品集成，但使用CRA兼容的连接解决方案提供了**更可靠、更高效且更可持续的合规路径。**
在下一篇文章中，我们将探讨**为什么 CRA 义务正迫使组织重新思考连接部分的架构、归属和维护，以及为什么这将演变成一个战略决策。**


### CRA资源与连接解决方案

无论您是在更新现有设备还是设计新产品，正确的连接策略都是应对 CRA 的关键。了解更多关于《网络弹性法案》的信息，探索 Anybus 网关及嵌入式解决方案，助您构建安全、可维护且面向未来的设备。


设备制造商与机器制造商如何转向符合 CRA 认证的连接解决方案《网络弹性法案》( CRA) 规定，对于开发和维护工业设备及机器中通讯连接部分的制造商，需承担长期的安全与维护责任。在我们前两篇文章中（《CRA 正在重新定义工业连接》和《网络弹性法案》：一场痛苦但必要的行业重塑），我们探讨了这些责任的具体内容，以及为什么尽管 CRA 引入了新的预期、流程和生命周期义务，它仍然必不可少。本系列的第三篇文章，我们将从“为什么要实现CRA”转向“如何实现CRA”。本文将解释：为什么老旧连接技术难以达到 CRA 合规要求？以及如果设备制造商和机器制造商将旧方案更换为现代化的、符合CRA标准的连接方案，合规之路将如何变得事半功倍？

替换老旧连接方案，加速实现 CRA 合规

《网络弹性法案》( CRA) 规定，对于开发和维护工业设备及机器中通讯连接部分的制造商，需承担长期的安全与维护责任。本文将解释：为什么老旧连接技术难以达到 CRA 合规要求？以及如果设备制造商和机器制造商将旧方案更换为现代化的、符合CRA标准的连接方案，合规之路将如何变得事半功倍？

安全

物联网

网络与通信

《网络弹性法案》(CRA)要求设备制造商对连接组件承担长期安全与维护责任。老旧连接方案因缺乏安全设计和完整文档，CRA合规难度大。采用现代化CRA兼容连接解决方案，可将协议维护、漏洞监测等繁重任务转移给供应商，简化合规流程。制造商可专注于系统集成与产品级安全，确保整机合规。这为工业设备制造商提供了高效、可持续的CRA合规路径。

网络安全

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《网络弹性法案》(CRA)要求设备制造商对连接组件承担长期安全与维护责任。老旧连接方案因缺乏安全设计和完整文档，CRA合规难度大。采用现代化CRA兼容连接解决方案，可将协议维护、漏洞监测等繁重任务转移给供应商，简化合规流程。制造商可专注于系统集成与产品级安全，确保整机合规。这为工业设备制造商提供了高效、可持续的CRA合...

替换老旧连接方案，加速实现 CRA 合规-腾讯云开发者社区-腾讯云

替换老旧连接方案，加速实现 CRA 合规

替换老旧连接方案，加速实现 CRA 合规

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐