1.8 实质性修改与备件 (Art. 3(30)、21–22)
1.8.1 概述
对含数字元素产品的实质性修改，使被修改的产品在 CRA 意义上成为新产品。将其在市场上提供的行为构成重新投放市场——无论修改由原制造商还是第三方作出。
该概念在四种情形下具有决定意义：
| # | 情形 | 法律依据 |
|---|---|---|
| a | 进口商或分销商对已投放市场的产品作实质性修改 → 视为其制造商 | Art. 21 |
| b | 任何其他自然人或法人对产品作实质性修改并将其提供于市场 → 视为其制造商 | Art. 22 |
| c | 任何人在 2027.12.11 之后对 2027.12.11 之前投放市场的产品作实质性修改并将其投放市场 → 视为其制造商 | Art. 69(2) |
| d | 制造商判断 2027.12.11 之后所作变更是否需要新的合规评估 —— 迭代式软件开发中的日常情形 | Art. 32 |
法律依据
Art. 3(30) CRA： 「『实质性修改』指含数字元素产品投放市场后发生的、影响该产品符合附件 I 第一部分基本网络安全要求的变更，或导致该产品所评估之预期用途发生改变的变更。」
CRA 鉴于条款 39： 当某项变更改变了网络安全风险水平，且该被改变的或额外的风险未被制造商在其风险评估中考虑，从而也未反映在其对基本要求的落实中时，产品即被实质性修改。
Art. 21、22 CRA： 对进口商、分销商及其他人的后果。
1.8.2 定义：实质性修改
已更正的判定标准
本手册的早期版本列出了三个累积条件（涉及网络安全 且 超出预期更新范围 且 使合规评估失效）。该标准比法律更严格，会把应报告的变更误判为非实质性。
Art. 3(30) CRA 规定了两个择一要件。满足其一即为实质性修改。
产品投放市场之后的变更，若满足以下任一项，即构成实质性修改：
- 影响产品对附件 I 第一部分基本网络安全要求的符合性；或
- 导致产品被评估之预期用途发生改变。
鉴于条款 39 提供了第一要件的操作性解读：该变更改变了网络安全风险水平，且该被改变的或额外的风险未被制造商的风险评估所涵盖。
什么不是判定标准
- 不是变更的规模或复杂度。三行代码可能构成实质性修改；彻底重写未必构成。
- 不是版本号是否提升。
- 不是制造商是否将其称为「安全更新」—— 见 1.8.6。
- 不是其在抽象意义上是否可预见；关键在于风险是否实际被评估过。
1.8.3 决策树
产品投放市场后发生了某项变更
│
├── 该变更是否属于翻新、维护或维修，
│ 且预期用途、功能与风险水平均未受影响？
│ └── 是 → 非实质性修改（→ 1.8.4）
│
├── 该变更是否改变了产品被评估的预期用途？
│ └── 是 → 实质性修改
│
├── 该变更是否改变了网络安全风险水平？
│ ├── 否 → 非实质性修改
│ └── 是 ↓
│
├── 该被改变的或额外的风险，是否已在制造商的风险评估中
│ 被考虑，且缓解措施已落实并仍然有效？
│ ├── 是 → 非实质性修改
│ └── 否 → 实质性修改
│
└── 后果 → 重新投放市场（→ 1.8.7）1.8.4 物理维修、维护与翻新
对已投放市场产品进行物理改动的翻新、维护或维修——如 (EU) 2024/1781 法规 Art. 2 第 (18)、(19)、(20) 项所定义——不必然构成实质性修改（CRA 鉴于条款 42）。须逐案判断。
用性能更好的部件替换有缺陷或磨损的部件——因技术进步或原部件停产——本身不会触发实质性修改。只有在性能变化或维修后产品的运行方式：
- 影响其对基本要求的符合性，或
- 导致风险评估未涵盖的预期用途改变时，
才构成实质性修改。
示例： 制造商用性能更好的新内存模块替换服务器中的故障内存。对基本要求的符合性未受影响，新性能仍在风险评估所考虑的预期使用范围内。该服务器未被实质性修改。
1.8.5 备件 (Art. 2(6))
Art. 2(6) CRA 将用于替换相同组件且按相同规格制造的备件排除于 CRA 适用范围之外。鉴于条款 29 确认，这既涵盖 CRA 适用前提供之产品的备件，也涵盖本身已通过 CRA 合规评估的备件。
条件一 —— 作为备件供应
只有当部件专为维修或延长已投放市场产品（无论在 2027.12.11 之前或之后）的耐用性而供应时，豁免才成立。
| 符合 | 维修或维护目的从供应情境中可见——订单或商业报价中标明了产品或产品族，或供应通过售后或服务渠道进行。相关证据须备妥以供市场监管机构查阅。 |
| 不符合 | 作为独立产品供应、与既有产品的维护或维修无关。它按常规方式投放市场。 |
技术上可互换并不足够
某产品在技术上能够替换某组件，本身并不足以使其纳入豁免。缺少上述情境证据时，它就是普通的含数字元素产品。
条件二 —— 确实相同
部件是否「相同」，依其在产品中的功能角色以及可能与网络安全相关的特征判断。
| 差异 | 对豁免的影响 |
|---|---|
| 不影响安全特征或网络安全风险特征的差异——例如采用不同芯片组但协议与安全机制相同、固件未改变安全相关特征 | 豁免保留 |
| 算法、协议、加密机制、访问控制功能或其他安全相关特征的差异 | 不相同 —— 该部件本身即为含数字元素的产品 |
若备件并不相同
该替换件受 CRA 管辖。其合规性依其自身的预期用途评估——尤其包括其确保与既有产品（该产品本身可能在 CRA 适用前即已投放市场）兼容或互操作的功能。
若因该预期用途或技术约束而无法合理满足某些基本要求，制造商必须在网络安全风险评估中予以反映，实施替代性或补偿性风险缓解措施，并在技术文档与用户信息中记录约束、风险与措施——与复杂系统采用同一机制。
具体示例
| 情形 | 判定 |
|---|---|
| 控制器分别于 2026 年与 2028 年投放市场；两者的数字通信模块均发生故障；制造商供应按相同规格制造的相同替换模块 | 两种情形均豁免。 该维修不构成实质性修改。 |
| 2026 年投放的工业控制器通信芯片故障；制造商供应功能等效但加密实现不同、安全启动机制更新的新芯片 | 不豁免。 这些差异影响芯片的网络安全属性；它是受 CRA 管辖的含数字元素产品。 |
| 2028 年投放的智能楼宇控制器无线模块故障；替换模块采用不同芯片组，但通信协议与安全机制相同，固件未改变安全相关特征 | 豁免。 该模块可视为相同。 |
| 2027 年投放的工业自动化系统中 PLC 的 CPU 故障；制造商提供相同的替换 CPU 或完整的相同替换 PLC，均通过售后渠道供应并明确标明目标系统 | 两种情形均豁免。 无论替换的是产品内的组件，还是构成更大产品一部分的完整产品，豁免均适用。 |
1.8.6 作为实质性修改的软件更新
软件持续更新，因此这一问题在每次发布时都会出现。以下四种模式涵盖了大多数情形。
模式 1 —— 新功能改变预期用途 → 实质性
| 示例 | 理由 |
|---|---|
| 原本显示趋势与告警的监控仪表盘，获得了控制机器的能力——调整运行参数、故障后重启 | 预期用途从态势感知转向对其他设备的运行控制，超出风险评估的设想 |
| 个人信息管理程序获得了自动分析用户内容、构建行为画像并在无用户干预下自动决定内容优先级、抑制或推荐的能力 | 预期用途从用户主导的工具转变为自动决策系统 |
模式 2 —— 已预见并评估过的功能 → 非实质性
| 示例 | 理由 |
|---|---|
| 消息应用初始仅支持一对一消息；原始风险评估已涵盖群组消息（包括消息路由复杂度上升）、管理员控制与审核工具。后续更新启用了它们 | 该功能落在原始预期用途与风险评估之内 |
| 生产监控系统上市时仅启用只读仪表盘，自动控制功能虽已存在但被禁用；风险评估明确涵盖了其未来启用，包括闭环控制风险、操作员接管与安全失效状态。后续更新启用了它们 | 风险与保护措施已事先评估 |
这是提前评估的理由
明确预见某项计划功能——并描述其风险与缓解措施——的风险评估，可以使该功能日后启用不落入「实质性修改」范畴。这正是把路线图写入风险评估、而非逐个功能评估的具体理由。
模式 3 —— 变更很小，新风险显著 → 实质性
| 示例 | 理由 |
|---|---|
| 在本地存储认证令牌的「记住我」持久登录功能 | 范围有限，但引入了风险评估未考虑的令牌窃取、未授权访问与会话劫持风险 |
| 导出详细系统日志以便排障的日志与诊断功能 | 表面上很小，却导致敏感运行数据以未加密形式收集与存储，引入未经评估的数据暴露风险 |
模式 4 —— 安全更新 → 通常非实质性
依据鉴于条款 39，安全更新通常不是实质性修改，因为其主要目的是降低网络安全风险。即便更新带来重大技术变动亦然，也包括仅为缓解已识别漏洞而修改或限制功能的情形。
| 非实质性修改 | |
|---|---|
| 修正可能导致缓冲区溢出的输入校验错误，或修复因会话令牌校验不当而允许绕过认证的逻辑缺陷 | 内部实现发生变化；预期用途与暴露面未变 |
| 收紧防火墙规则、禁用未使用的网络端口、修改默认管理员口令策略、在已具备或已预见的前提下强制启用 MFA | 影响用户配置或访问方式，但仅服务于提升安全态势 |
| 禁用已弃用的加密算法并启用已支持的更强替代算法，前提是风险评估已涵盖全部加密选项并预见了弃用 | 该措施已被预见并评估；未引入新的外部依赖，未改变数据流 |
| 属于实质性修改 | |
|---|---|
| 本地文件加密产品被改为必须将所有文件上传至制造商运营的远程加密服务进行处理 | 虽出于安全动机，却从根本上改变了预期用途——产品不再执行本地加密 |
| 内部管理的密钥生命周期被替换为需使用第三方外部密钥管理服务的协议 | 依赖关系与数据流发生实质改变，新增了未经评估的外部接口 |
四因素判断
评估任何更新时，可（非穷尽地）考量其是否：
| # | 因素 |
|---|---|
| a | 引入新的威胁向量 —— 新增接口、通信通道、执行环境或外部依赖，威胁可借此实现 |
| b | 使新的攻击场景成为可能 —— 对产品或其处理的数据进行未授权访问、操纵、干扰或滥用的新途径 |
| c | 改变既有已识别攻击场景的发生可能性 —— 降低所需成本或专业门槛、增加对不可信主体的暴露、削弱既有保护措施 |
| d | 改变既有已识别攻击场景的潜在影响 —— 受影响数据或功能的范围、运营/安全/经济后果的严重程度，或检测、遏制与恢复的能力 |
若四项均不适用，且风险评估所依赖的假设与缓解措施仍然有效，则该更新不太可能构成实质性修改。若任一项适用，制造商必须重新评估网络安全风险，并判断基本要求是否仍被满足。
1.8.7 实质性修改的后果
被实质性修改的产品视为新产品，将其提供于市场构成重新投放市场。后续处理取决于由谁修改以及修改的波及范围。
由原制造商以外的人作出的修改
该人成为被修改产品的制造商——无论其是否参与过原始设计或投放市场。
| 修改的波及范围 | 修改者的义务 |
|---|---|
| 该修改未对产品整体的网络安全产生不利影响 | Art. 13 与 Art. 14 仅就被实质性修改的部分适用（Art. 22）。未受影响的方面可复用既有测试与文档；由修改者证明哪些部分无需更新。仍须出具符合性声明。 |
| 该修改确实对产品整体的网络安全产生不利影响——例如不再局限于某个特定组件或子系统 | 该产品被视为整体受 CRA 管辖的新产品。就产品整体承担完整的 Art. 13 与 Art. 14 义务。 |
原制造商的义务不因此免除
第三方对产品作实质性修改时，原制造商就其投放市场的原始产品所负义务继续适用。这确保了未变更部分在漏洞处理与合规上的连续性。
集成不是修改
不要混淆二者
将组件组装（包括对其加以修改）为新产品并以自有名称投放市场的公司，并非在实质性修改他人的产品。它是在投放一个新的含数字元素产品。它是该新产品的制造商，须就产品整体完整遵守 CRA。为便利自身合规，它可以依托各组件制造商的合规工作。
示例： 某公司采购通用微控制器模块与连接组件，开发专有固件与传感器套件，组装成互联农业监测产品并以自有名称投放市场。这是集成，不是实质性修改。
由原制造商作出的修改
原制造商仍是制造商，被实质性修改的产品视为重新投放市场。适用两条比例原则：
- 允许复用。 未受修改影响的方面可复用既有文档与测试结果。合规评估——以及在涉及公告机构时其评估——应聚焦于被实质性修改的部分。
- 2027 年前产品不会被拖入完全合规。 原制造商对 2027.12.11 之前投放市场产品所作的实质性修改，本身不要求将整个产品纳入完全 CRA 合规——除非该修改对产品整体网络安全产生不利影响。否则义务限于被实质性修改的部分。
无论判定结果如何均适用的义务
判定结果不会暂停基线义务
无论某次更新是否构成实质性修改，制造商仍须：
- 依附件 I 第二部分的漏洞处理要求，确保软件更新以及产品在其支持期内的安全；并
- 保持风险评估与技术文档准确、完整且持续更新（Art. 13(7)、Art. 31(2)）。
1.8.8 对支持期的影响
实质性修改要求依 Art. 13(8) 标准重新评估支持期，但不会自动重置或延长支持期。决定性问题在于该修改是否影响了最初确定预期使用时长的因素。规则与示例见 6.4 支持与生命周期。
1.8.9 判定为「是」之后的步骤
| 步骤 | 行动 |
|---|---|
| 1 | 进行或更新风险评估（模板）—— 若修改范围可控，则限定于被修改部分 |
| 2 | 重新检查产品分类 —— 预期用途改变可能改变核心功能 |
| 3 | 进行合规评估，聚焦被修改部分：模块 A、模块 B+C、模块 H 或 EUCC |
| 4 | 更新技术文档，复用未受影响的内容 |
| 5 | 出具新的 EU 符合性声明并加贴 CE 标志 |
| 6 | 重新评估并声明该修改版本的支持期 |
| 7 | 确认被修改产品的 Art. 14 报告覆盖范围 |
1.8.10 BAUER GROUP 的流程
每次发布前、以及修改第三方产品前的评估
| 步骤 | 行动 | 负责人 |
|---|---|---|
| 1 | 记录变更（改了什么、为什么） | 开发团队 |
| 2 | 判断预期用途是否改变 | 产品管理 |
| 3 | 应用四因素判断（1.8.6） | CISO |
| 4 | 检查被改变的风险是否已被现行风险评估涵盖 | CISO |
| 5 | 决定：是否为实质性修改 | CISO + 管理层 |
| 6 | 记录决定及其理由 | CISO |
1.8.11 文档
每次修改决定均须记录：
- 修改说明 —— 改了什么、为什么
- 预期用途检查 —— 未变，或如何改变
- 四因素分析 —— 威胁向量、攻击场景、可能性、影响
- 涵盖性检查 —— 被改变的风险是否已在风险评估中，缓解措施是否仍然有效
- 实质性判定 —— 决定及理由
- 措施 —— 启动了什么，或为何无需措施
- 负责人与日期
文档义务
判定某项修改不属于实质性修改，同样必须记录。发生争议时，BAUER GROUP 必须能够证明该审查确已进行——并且依 Art. 13(7) 与 Art. 31(2)，无论判定结果如何，风险评估与技术文档均已保持更新。
本页解释的来源与法律地位：欧盟委员会 CRA 指南。