实质性修改 (Art. 20)
概述
对含数字元素产品的实质性修改 (Substantial Modification) 可能导致进行修改的人被视为新的制造商，从而必须承担 Art. 10 项下的全部制造商义务。Art. 20 CRA 定义了何时修改被视为"实质性的"以及由此产生的后果。
法律依据
Art. 20 CRA： 对已投放市场的含数字元素产品进行实质性修改的任何自然人或法人，应被视为本法规意义上的制造商。
Art. 3 No. 31 CRA： 实质性修改的定义。
定义：实质性修改
如果同时满足以下所有条件，则修改被视为实质性的：
- 修改影响产品的网络安全
- 修改超出原制造商预期的维护和安全更新范围
- 修改使现有的合格评定不再有效
决策树
产品投放市场后是否被修改？
+-- 否 --> 无影响
+-- 是 --> 修改是否影响网络安全？
+-- 否 --> 非实质性修改
+-- 是 --> 修改是否超出预期更新范围？
+-- 否 --> 非实质性修改（常规更新）
+-- 是 --> 现有合格评定是否失效？
+-- 否 --> 非实质性修改
+-- 是 --> 实质性修改
--> 进行修改的人成为制造商示例
非实质性修改
- 制造商提供的安全补丁和缺陷修复
- 在预期设置范围内的配置变更
- 将依赖项更新到补丁版本（例如 1.2.3 --> 1.2.4）
- 部署参数的调整
- 语言包或本地化
实质性修改（潜在）
- 更改认证机制（例如，密码 --> OAuth --> 自定义实现）
- 移除安全功能（例如，禁用加密）
- 更改网络架构，打开新的攻击向量
- 集成新的安全相关组件（例如，自定义加密栈）
- 移植到新平台，具有不同的安全模型
- 核心依赖项的主版本升级，改变了安全属性
实质性修改的后果
进行实质性修改的人必须：
1. 承担制造商义务（Art. 10）
- 进行网络安全风险评估（针对修改部分）
- 创建/更新技术文档（Annex VII）
- 确保漏洞处理（Annex I 第二部分）
- 定义支持期
2. 进行新的合格评定
- 进行产品分类（也针对修改部分）
- 选择适当的合格评定程序
- 标准产品的 Module A
- I/II 类产品的 Module B+C
- II 类产品的 Module H
- 关键产品的 EUCC
3. 新的欧盟符合性声明
- 为修改后的产品发布欧盟符合性声明
- 粘贴 CE 标志（以自己的名义）
4. ENISA 报告义务
- 报告修改后产品中的漏洞（Art. 14）
- 遵守 24小时/72小时/14天期限
BAUER GROUP 流程
对第三方产品进行任何修改前的审查
| 步骤 | 操作 | 负责人 |
|---|---|---|
| 1 | 记录修改（修改了什么？） | 开发团队 |
| 2 | 评估网络安全相关性 | CISO |
| 3 | 检查修改是否在制造商的预期范围内 | 产品管理 |
| 4 | 检查合格评定是否仍然有效 | CISO |
| 5 | 决定：是否为实质性修改 | CISO + 管理层 |
| 6 | 记录决定（附理由） | CISO |
如果"是——实质性修改"
| 步骤 | 操作 |
|---|---|
| 7 | 进行风险评估（模板） |
| 8 | 进行产品分类 |
| 9 | 进行合格评定 |
| 10 | 创建技术文档 |
| 11 | 发布欧盟符合性声明 |
| 12 | 定义支持期 |
文档
每个修改决定都需记录：
- 修改描述 -- 修改了什么，为什么
- 网络安全分析 -- 对安全的影响是什么
- 实质性评估 -- 附理由的决定
- 措施 -- 采取了哪些步骤（或为何不需要采取措施）
- 负责人和日期
文档义务
修改非实质性的决定也必须记录。在争议情况下，BAUER GROUP 必须能够证明已进行了审查。