Robanchor

OTA固件更新与《网络弹性法案》:作为服务义务的补丁管理

2026-03-14

OTA更新不再仅仅是便利——它们是一项法律义务

当一家中国机器人制造商将机械臂或自主移动机器人运入欧盟时,该设备上的固件现在受《网络弹性法案》(CRA)约束。该法规作为欧盟法规(EU)2024/2847在欧盟官方公报上发布,将空中下载(OTA)更新从一项令客户满意的功能转变为一项可能决定市场准入的合规义务。对于正在欧洲建立的服务网络,实际后果很明确:打补丁不是偶尔的修复,而是一项必须规划、记录并以安全为重执行的持续服务。

CRA不仅要求修复漏洞;还要求更新机制本身必须是安全的。该法规附件一第一部分第2(d)点要求数字元素的设计应“限制攻击面”并“最小化事件的影响”。更具体地说,第2(f)点要求及时提供安全更新,并且更新机制必须是安全的。这意味着,如果OTA系统允许未签名的固件或可能被中间人攻击中断,即使更新内容正确,也不符合要求。

CRA对更新机制的要求

该法规对OTA更新提出了几项具体的安全要求。根据附件一第一部分第2(f)点,制造商必须确保更新“由安全机制支持”,以防止安装未经授权的固件。这意味着更新包必须进行加密签名,验证更新来源,并在安装前进行完整性检查。此外,更新过程不得引入新的漏洞——例如,不得允许回滚到具有已知严重漏洞的版本,除非明确授权并记录。

CRA第13(8)条增加了另一层要求:制造商必须确保可利用的漏洞通过免费提供安全更新得到“有效缓解”。该法规没有规定固定的时间窗口,但要求漏洞发现后“不得无故延迟”提供更新。对于服务网络,这带来了后勤挑战:如何将关键补丁推送到分布在多个欧盟成员国的数百台机器人,而每台机器人的连接性和维护计划各不相同?

此外,第13(9)条要求制造商记录并告知用户更新,包括其安全影响。这意味着每次OTA更新都必须附带发布说明,解释修复了什么以及为什么。对于第三方服务提供商,这些文档成为服务记录的一部分,可被国家市场监督机构审计。

运送易受攻击的固件:谁负责?

CRA显著转移了责任。根据第13(1)条,制造商必须确保产品在市场上销售时没有已知的可利用漏洞。这是一项严格义务:如果机器人以具有已知严重漏洞的固件版本发货,即使该漏洞是在产品设计后披露的,制造商也构成违约。唯一的抗辩是漏洞在投放市场时未知,但举证责任在于制造商。

对于服务网络,这种责任具有连锁效应。如果制造商依赖当地合作伙伴执行更新,制造商仍对产品的安全负责。然而,如果服务提供商未能正确执行更新,或安装了引入新漏洞的更新,则可能根据一般合同法承担责任。CRA不直接监管服务提供商,但确实要求制造商确保“产品附带安全安装和使用所需的信息和说明”(附件一第一部分第2(i)点)。这意味着服务网络必须能够访问详细的技术文档,并严格遵守制造商的更新程序。

在实践中,这意味着服务合同应明确定义谁负责监控漏洞披露,谁决定何时推送更新,以及谁承担更新失败的成本。CRA没有规定具体的分工,但确实要求制造商有一个“协调披露”漏洞的流程(第13(5)条)。服务网络可以作为制造商在现场的耳目,报告事件并验证补丁是否正确应用。

OTA与物理服务更新:比较

虽然OTA更新通常是修补固件的最有效方式,但并非总是可行。有些机器人在隔离网络中运行,有些具有需要物理干预的安全关键功能,有些硬件不支持安全的OTA。下表从服务和合规角度比较了两种方法。

方面 OTA更新 物理服务更新
部署速度 可以同时推送到许多设备,通常几小时内完成 需要安排技术人员访问;对于大型车队可能需要数天或数周
更新机制的安全性 必须实现加密签名、安全通道和完整性检查(CRA附件一第一部分2(f)) 物理访问降低了远程拦截的风险,但需要安全处理更新介质并验证技术人员身份
文档和审计跟踪 自动记录更新尝试、成功/失败和设备状态;更容易提供合规证据 需要手动记录;存在人为错误或不完整记录的风险
每次更新的成本 初始基础设施投资后边际成本低 高:差旅时间、人工和潜在停机时间
对安全关键系统的适用性 可能需要额外验证;某些安全功能可能需要物理存在来验证 当技术人员必须目视检查机器人或需要故障安全时,首选
符合CRA免费更新要求 更容易免费提供更新,因为没有差旅成本 可以免费,但人工成本必须由制造商或服务合同承担

OTA和物理更新之间的选择不是二元的。许多制造商采用混合方法:OTA用于非关键固件,物理访问用于重大升级或安全相关补丁。对于服务网络,这意味着在这两个领域都建立能力,但要清楚OTA是合规的默认选择,因为它更快且更可审计。

对服务网络的实际影响

对于正在欧洲建立的本地服务网络,CRA创造了一个新的收入来源:补丁管理服务。制造商可能外包漏洞数据库的监控、更新包的准备以及成功安装的验证。然而,这需要超越传统维修的技术专业知识和法律意识。

首先,网络必须能够访问制造商的漏洞披露流程。CRA要求制造商维护一个“单一联系点”用于漏洞报告(第13(5)条),但不要求他们与第三方共享。因此,服务合同应包括制造商通知服务提供商相关漏洞并提供必要补丁的条款。

其次,网络必须能够验证更新是真实的且未被篡改。这意味着技术人员需要理解加密签名,并能在安装前检查它们。在实践中,这可能涉及使用仅接受签名固件的安全引导加载程序,但技术人员仍必须确认更新包与制造商的发布说明匹配。

第三,网络必须保持细致的记录。根据第13(9)条,制造商必须告知用户更新,但服务提供商可能需要记录更新应用于特定设备的时间、结果。这不仅是为了合规,也是为了责任保护:如果机器人在更新后发生故障,服务提供商必须能够证明更新是正确执行的。

最后,网络必须为制造商倒闭或停止支持产品的可能性做好准备。CRA要求制造商在产品“预期寿命”内提供安全更新(第13(8)条),但如果制造商消失,责任可能落在进口商或分销商身上。服务网络可以介入提供更新,但它必须有这样做的合法权利,这再次表明需要明确的合同。

来源

  • EUR-Lex — Regulation (EU) 2024/2847 — https://eur-lex.europa.eu/eli/reg/2024/2847/oj (accessed 2026-03-14)
  • European Commission — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/ (accessed 2026-03-14)