欧盟《网络韧性法案》CRA实施指南总结报告- 大数跨境

ASPICE汽车软件开发流程学习基地

2026-11-11

欧盟《网络韧性法案》（CRA）实施指南总结报告

【文件基本信息与法律效力说明】
法律依据：欧洲议会和欧盟理事会 Regulation (EU) 2024/2847（网络韧性法案，Cyber Resilience Act）
文件属性：欧盟委员会 C(2026) 5252 final 附件（ANNEX，共 84 页，涵盖第 1 至 9 章全部 257 个段落及 67 个编号实务示例）
规制范围：在商业活动中投放欧盟市场的所有具备直接或间接数据连接的数字元素产品（PDE）及其远程数据处理解决方案（RDPS）
司法效力声明：根据《欧盟运行条约》（TFEU），本实施指南属于非约束性行政解释文件，对欧盟立法的终局权威解释权仅属于欧盟法院（CJEU）。

概述

条例 (EU) 2024/2847（CRA）于 2024 年 10 月 23 日由欧洲议会和理事会正式通过，并于 2024 年 12 月 10 日正式生效。该条例属于欧盟新立法框架（New Legislative Framework, NLF）下的横向产品安全法律，为投放欧盟市场的具备数字连接能力的软硬件产品设定了覆盖全生命周期的网络安全要求。

依据 CRA 第 26(1) 条授权，欧盟委员会制定并发布了实施指南 C(2026) 5252 final 附件，用以指导经济运营者、开源社区及合格评定机构对法规进行统一适法。本报告严格依循官方指南的结构框架，对适用范围界定、开源软件治理、重大修改判定、支持期机制、产品安全分类、风险评估与尽职调查、远程数据处理解决方案（RDPS）、第 14 条强制报告义务以及跨法衔接规则进行逐章梳理。

第一章：立法背景、法律性质与实施时间轴（对照第 1 章）

1.1 指南的法律定位与效力边界

指南第 1 章（第 1–9 段）对指导文件的法律属性与解释边界作出规定：

·法定授权：指南依据 CRA 第 26(1) 条制定，旨在对法案的关键概念、开源软件适用、重大修改、支持期确立及合格评定程序提供操作指导。

·非约束性地位：指南属于非约束性行政文件（Non-binding guidance）。指南第 8 段明确提示，根据《欧盟运行条约》，对欧盟立法的终局权威解释权仅属于欧盟法院（CJEU）。

·与实施问答（FAQs）的关系：本指南在委员会 2025 年 12 月发布的实施问答（FAQs）基础上，进一步阐明法案条文背后的立法原意，建立系统的工程与法律判定准则。

1.2 关键实施里程碑与时间轴

CRA 条例设置了分阶段适用的过渡期安排，核心时间节点如下：

图示：CRA 关键时间节点与实施里程碑时间表

时间节点	里程碑事件	法律依据与适用范围说明
2024-10-23	条例正式通过	欧洲议会与理事会正式签署通过 Regulation (EU) 2024/2847
2024-12-10	条例正式生效 (Entry into force)	公布后第 20 天生效，法案整体过渡期为 36 个月
2025-12-03	委员会发布实施常见问答 (FAQs)	指导经济运营者提前开展合规准备工作
2026-06-11	公告机构条款适用 (18 个月)	第 IV 章关于合格评定机构的指定、通知与监管规则开始适用
2026-07-27	委员会通过实施指南	正式通过 Document C(2026) 5252 final ANNEX
2026-09-11	第 14 条报告义务适用 (21 个月)	强制适用于市场上所有受控产品（无论何时投放），涵盖积极利用漏洞与严重事件
2027-12-11	CRA 全面生效实施 (36 个月)	基本网络安全要求、CE 标志、合格评定、技术文档、支持期与售后维护全面强制
2028-06-11	既有证书过渡期届满 (42 个月)	依据 RED 等既有立法签发的欧盟型式检验证书在 CRA 下的认可期届满（第 69(1) 条）

第二章：数字元素产品（PDE）与“投放市场”的认定边界（对照第 2 章）

第 2 章（第 10–39 段，示例 1–12）对受控对象范畴及市场投放行为作出了具体界定。

图示：数字元素产品（PDE）定义与数据连接测试

2.1 数字元素产品（PDE）的法定构成

根据 CRA 第 3(1) 条，“数字元素产品”（Product with Digital Elements, PDE）是指：“任何软件或硬件产品及其远程数据处理解决方案（RDPS），包括单独投放市场的软件或硬件组件”。

受控产品包含以下四类物理与逻辑形态：

·独立软件（Standalone Software）：以物理介质或数字下载形式分发的应用程序、操作系统、固件、驱动程序等；

·嵌入软件的硬件产品：内置执行代码的消费电子、IoT 设备、联网家电、工业可编程逻辑控制器（PLC）等；

·独立硬件组件：微控制器、具备数字通信接口的芯片组、集成电路（ASIC/FPGA）及主板等；

·协同运行的软硬件组合：单独供应但专为协同工作而设计的软硬件单元组合。

2.2 “数据连接”测试（Data Connection Test）

CRA 第 2(1) 条规定，受控产品必须具有或可合理预见具有直接或间接的逻辑或物理数据连接。指南第 22–24 段明确了技术判定要件：

·“数据”的定义要件：指由发送方按照特定协议有意编码为离散二进制符号（0 与 1），并能被接收方解码恢复的信息。

·排除纯电平与模拟触发信号：仅用于供电、纯模拟电平驱动、或仅通过通断触发物理动作的电信号（如传统双金属片恒温器开合继电器、机械开关），不承载数字编码数据，不构成 CRA 意义上的数据连接。只有存在逻辑通信协议（如 I2C、SPI、UART、USB、TCP/IP、BLE 等）时，方落入监管范畴。

2.3 “投放市场”（Placing on the Market）的界定标准

图示：投放市场认定与软件、SaaS 及 Web 应用的界限

根据第 3(21) 与 3(22) 条，投放市场是指在商业活动过程中，为在欧盟市场上分销或使用而首次提供产品。

·独立软件投放时点：软件开发完成并在欧盟首次开放供用户获取（下载、分发、销售）时即告投放。同一软件版本的多个副本被视为在同一时间整体投放市场，不受各个最终用户实际获取时间的影响。

·副本与变体的区分：“副本”指同一编译版本的拷贝，投放时点一致；“变体”若因适配不同操作系统（Windows vs Linux）、不同芯片架构（x86 vs ARM）或功能裁剪而存在代码与功能差异，属于独立产品，须分别履行合规评定（第 13 段）。

·计算机代码分发属性：软件包含机器码与源代码。但公开托管平台上的个人代码共享、开发阶段未完工代码、教学与技术文档示例代码，通常缺乏商业分发意图，不构成投放市场（第 17–19 段）。面向客户提供有偿商业源码许可（如商用 SDK）属于投放市场，但供应方不对客户后续自行编译与二次修改的合规性负责（示例 7）。

2.4 软件、SaaS 与 Web 应用的定界规则

·落入 PDE 范围：提供给最终用户并在用户自有电子信息系统上安装或运行的软件，包括本地客户端应用、移动 App、浏览器扩展插件，以及基于 Web 技术打包的本地执行桌面应用（如 Electron 应用）。

·免于 PDE 范围：纯粹在远端服务器执行、用户仅通过通用浏览器访问的 Web 应用与 SaaS 平台，以及信息展示类静态网站，不属于 PDE。

·混合架构：若用户侧运行本地客户端，而客户端依赖后台专有云服务实现功能，则本地客户端属于 PDE；该后台云服务若满足远程数据处理解决方案（RDPS）的定义，作为该产品的组成部分一并受控（第 8 章）。

2.5 软硬件组合、复杂系统与既有设计产品

图示：软硬件组合、复杂工业系统与既有设计产品（Legacy Products）

·软硬件组合判定：判断依据是该软件对于实现硬件产品的预期用途是否必要，而非软件的交付形式（预装或后续下载）。运行、配置或控制硬件所必需的配套软件与硬件共同构成单一 PDE（示例 8、9）。

·复杂工业系统：具备长生命周期、依赖既有架构与互操作标准的工业自动化系统仍属于 PDE。序言 55 指出，若某些基本安全要求与复杂系统性质不兼容，制造商应采用基于风险的方法，记录客观技术限制，实施替代性或补偿性安全控制，并定期评估。

·既有设计产品（Legacy Products）：在 2027 年 12 月 11 日之后投放市场但沿用此前设计制造的产品（第 37–39 段，示例 12），无须进行重新设计（Redesign）。制造商须依据第 13(2) 条开展网络安全风险评估，编制技术文档证明现有措施足以确保适当安全水平，出具 EU 符合性声明，加施 CE 标志，并建立漏洞处理流程。

第三章：自由与开源软件（FOSS）的特别制度与责任机制（对照第 3 章）

指南第 3 章（第 40–89 段，示例 13–34）明确了开源软件适用 CRA 的具体条件，通过责任归属测试与商业化判断准则界定监管边界。

图示：开源软件（FOSS）定义要件与责任归属测试

3.1 FOSS 的法定双重要件

根据 CRA 第 3(48) 条，构成自由与开源软件（FOSS）须同时满足两项累计条件：

·许可要件：采用自由与开源许可协议，授予用户自由获取、运行、修改和重新分发的权利；

·源码公开要件：源代码必须向公众公开共享（可在上游或下游公开）。

【反向排除说明】
若软件采用开源许可，但源代码仅向特定付费商业客户提供、不对公众公开，则不属于 CRA 意义上的 FOSS，须按常规商业专有软件进行监管。

3.2 维护者与贡献者的责任界限

指南第 43–49 段确立了开源责任归属原则，将规制对象限定于“处于其责任之下”提供软件的主体：

·维护者（Maintainers）：对开源项目行使主要控制权、决定版本发布分支与路线图治理的个人或实体，软件处于其责任之下。

·贡献者（Contributors）：仅向开源项目提交代码补丁、合并请求或修复建议者。技术层面的提交权限（Commit access）本身不足以确立法律责任（示例 13）。普通代码贡献者不承担 CRA 义务。

3.3 判断 FOSS 是否“投放市场”的七大准则

处于其责任之下的 FOSS 是否受 CRA 约束，取决于其是否在商业活动过程中提供。指南第 50–68 段规定了七项判定准则：

图示：判断 FOSS 是否属于“投放市场”的七大准则矩阵

评估准则	裁定标准与测试逻辑	典型场景与法律结论
3.2.1 收取价格	就软件本身（含预编译二进制安装包）收取对价，即构成商业投放。	源码公开但预编译二进制文件收费下载：该主体属于制造商，承担完整合规义务。
3.2.2 变现其他服务 / 数据	借助免费软件展示广告、收取交易佣金，或以收集处理个人数据为使用前提（非仅为安全互操作目的）。	免费开源 App 植入商业广告或强制收集非必要个人数据：构成商业活动投放。
3.2.3 支持服务	提供付费咨询、培训或运维，本身不构成投放；决定性因素是获取软件本身是否以付费为前提。自然人仅收回合理生活开支不属商业活动。	免费发布软件但提供付费定制支持：软件未投放市场；纯成本补偿不构成商业投放。
3.2.4 接受捐赠	自愿捐赠且无营利分红意图的，不构成商业活动，即使捐赠金额超过开发成本。	开发者通过平台接受赞助打赏：免于监管。若捐赠构成获取专有更新的前置条件，则视为变相收费。
3.2.5 外部资助	来自公共科研基金、企业基金会的资助或赞助，不改变软件的非商业性质。	接受公共研究资金资助开发开源项目：不属于投放市场。
3.2.6 非营利实体	扣除合理成本后收益全部用于非营利法定宗旨的法人，其发布的免费 FOSS 不构成投放。	开源基金会组织发布的非营利开源项目：不构成商业投放。
3.2.7 他方下游集成	第三方企业将开源代码集成至商业产品中，不改变上游 FOSS 的非商业性质。	商业集成商承担整机合规与尽职调查责任；上游开源项目原作者不承担责任。

3.4 开源软件管理者（Steward）的法律地位

图示：开源软件管理者（Steward）制度与下游责任机制

针对开源基金会等支撑机构，CRA 第 3(14) 条设立了“开源软件管理者”（Open-Source Software Steward）制度。依据第 24(3) 条，其法定义务根据支持类型实行梯度调节：

·仅提供非技术支持：如商标运营、行为准则制定、社区活动组织：无须履行强制漏洞报告，仅需建立内部网络安全政策向维护者通报信息。

·提供 IT 基础设施：如提供代码托管、版本控制、签名私钥管理：在获悉影响产品安全的严重网络安全事件时，须通报 ENISA 与主导 CSIRT。

·提供核心工程资源：如指派工程师主导代码审查、合并与安全版本发布：须就其知悉的被积极利用漏洞向 ENISA 和 CSIRT 报告，并视情通知用户。

第四章：重大修改判定、备件豁免与软件更新（对照第 4 章）

指南第 4 章（第 90–124 段，示例 35–50）依据第 3(30) 条与序言 39，规定了产品变更时判断是否构成重大修改的法定标准。

图示：重大修改判定要件（第 3(30) 条）与物理维修豁免

4.1 重大修改的法定定义

根据 CRA 第 3(30) 条，重大修改（Substantial Modification）是指产品投放市场后发生的变更，且满足下列条件之一：

·条件一：影响产品对附件 I 第一部分所列基本网络安全要求的符合性；或

·条件二：导致产品在风险评估中所确定的预期用途（Intended purpose）发生改变。

4.2 物理维修、维护与翻新的定性

依据序言 42 及可持续产品生态设计法规，日常维护、翻新与维修不必然构成重大修改。因原零部件停产而采用性能更优的新型兼容元件进行维修替换（示例 35），只要其安全协议、控制逻辑未变且未超出原评估用途，不属于重大修改。

4.3 备件豁免规则（第 2(6) 条）

图示：备件豁免规则与软件更新分类判定标准

CRA 第 2(6) 条豁免了用于替换已上市产品中相同组件的备件：

·评估要件：“相同”（Identical）的判断聚焦于网络安全特性，包括加密算法、通信协议、微码签名验证机制与访问控制；在安全特性一致的前提下，工艺微调不影响豁免。

·过渡期安排：为 2027 年 12 月 11 日前已上市设备供应的相同备件，同样免于受 CRA 约束。

4.4 软件更新：安全补丁 vs 功能变更（第 104–113 段）

依据序言 39，判断依据在于更新是否引入了现有风险评估未覆盖的新威胁或上升的风险水平，而非代码修改规模。

·通常不构成重大修改（安全加固类）：修复已知漏洞（输入验证、越界写入、认证绕过，示例 46）；收紧默认密码策略、强制多因素认证（MFA）；停用过时加密套件并切换为系统已支持的更高强度算法（示例 48）。

·通常构成重大修改（功能突变与架构漂移）：变更整体预期用途（如车载数据显示屏通过升级获得远程车辆动力控制权限，示例 40）；引入未评估的高危功能（明文日志存储凭据、永久免密凭证，示例 44、45）；将原由本地执行的密钥生成与加密运算变更为依赖远程第三方 KMS 服务（示例 49、50），实质性改变了信任边界。

4.5 重大修改的法律后果与主体责任转移

图示：重大修改法律后果与主体责任转移矩阵

实施主体情形	法定法律后果	义务范围与责任划分
由第三方实施 (Articles 21 & 22)	对产品实施重大修改并投放市场的第三方，在法律上被视为该产品的制造商。	若修改不影响未变动部分的安全，第三方仅就受修改波及的部分适用第 13、14 条；原厂责任在未改动部分存续。
由原制造商实施 (Recital 41, Blue Guide)	实施重大修改后投放的产品属于 CRA 下的“新产品”，构成一次新的投放市场行为。	必须重新开展合格评定、更新技术文档、重新签署 EU 符合性声明并施加 CE 标志。
与“集成”的区分 (Paragraph 120)	将第三方组件组装成自有品牌的新产品，属于产品集成，而非对他人产品的重大修改。	集成商为新产品的法定制造商，须对整机合规负责，并对集成组件行使第 13(5) 条尽职调查。

第五章：支持期的确定机制与全生命周期维护（对照第 5 章）

指南第 5 章（第 125–135 段，示例 51–56）明确了支持期的法定确立因素、透明度要求以及重大修改对支持期的复合影响。

图示：支持期确定机制与五年基准保障

5.1 支持期的法定确立准则（第 13(8) 条）

制造商须为产品确立支持期（Support Period），在支持期内持续处理漏洞并提供安全更新：

·法定考量因素：用户合理期望；产品性质与使用场景；涉及产品使用寿命的相关欧盟法律（如 ESPR）；比例原则。

·五年基准属性：法条规定支持期通常不少于五年，除非产品预期使用时间短于五年。五年属于法定兜底保障（Safeguard），并非默认上限；预期服役超过五年的耐久型产品应设定更长支持期（序言 60）。

5.2 迭代软件与第 13(10) 条灵活性机制

针对持续迭代发布的软件产品，若满足以下两项条件，制造商可仅对最新版本提供漏洞修补，免除对旧版本的维护责任：

·条件一：用户能够免费升级至最新投放的版本；

·条件二：升级不要求用户更换底层硬件设备或承担额外适配成本。常规配置微调、依赖升级和例行测试不构成额外成本；迫使更换计算设施的升级属于额外成本。

5.3 支持期透明度与到期通知（第 13(19) 条）

图示：支持期透明度要求、版本管理实践与重大修改影响

·售前告知义务：销售前须以清晰方式标明支持期的具体终止日期（至少精确到年份与月份，如 Supported until: 2032-12）。

·届满提示：支持期届满后，在技术可行且产品性质允许的前提下，应向用户显示到期提示通知。

5.4 重大修改对支持期的影响（第 5.1 节）

·非自动重置：重大修改须重新评估支持期，但不必然导致支持期自动重置或延长。

·底层寿命要素检验：若修改仅涉及应用层功能，硬件物理耐用性未变，支持期与原产品剩余使用时间一致（示例 54、55）；若硬件平台重构显著延长了物理服役寿命，须重新计算并确立新的支持期（示例 56）。

第六章：产品安全分级、核心功能测试与合格评定路径（对照第 6 章）

指南第 6 章（第 136–155 段，示例 57–65）依据产品风险程度建立了四级监管体系，确立了以“核心功能”为准绳的定级测试方法。

图示：重要与关键数字元素产品四级架构与合格评定要求

6.1 四级产品监管架构

安全风险分类	法律依据	代表性典型产品举例	合格评定程序路径
默认类 (Default)	未列入附件 III 或 IV 的所有其他 PDE	智能家居传感器、多媒体软件、办公软件、联网玩具等	内部控制程序（模块 A，即自我评定），亦可自愿选择第三方评估。
重要类 I (Class I)	第 7(1) 条附件 III	身份管理系统、密码管理器、网络浏览器、路由器、VPN 客户端等	双轨制：完整适用已公告协调标准可走模块 A 自评；否则强制第三方评估。
重要类 II (Class II)	第 7(1) 条附件 III	操作系统、虚拟化系统、工业防火墙、PKI 签发系统、可编程逻辑控制器等	强制第三方合格评定（模块 B+C 型式试验，或模块 H 全面质量保证），或欧洲认证。
关键类 (Critical)	第 8(1) 条附件 IV	智能电网核心硬件、智能卡安全芯片、硬件安全模块（HSM）等	强制第三方合格评定；技术描述细化至实施条例 (EU) 2025/2392。

【第 32(5) 条开源特惠规定】
对于属于重要类 I 或重要类 II、但在商业活动中作为 FOSS 投放市场的软件，依据第 32(5) 条，制造商可以直接采用默认类的评定程序（即模块 A 内部自评）。

6.2 “核心功能”（Core Functionality）唯一性测试

图示：核心功能测试判定方法与三大边界情形

·定义：产品的主要特征与技术能力，若缺少该能力产品将无法实现其主要预期用途。

·唯一性规则：出于合规分类目的，一个产品只能被界定为具有唯一一个核心功能（第 144 段）。

·集成高等级组件不提升整机定级：智能手机虽集成了操作系统（重要类 II）与密码模块（重要类 I），但整机核心功能为通用个人计算终端，整机仍按默认类评定（示例 58）。

·反规避原则：技术文档、使用说明与销售宣传关于核心功能的描述须保持一致，禁止通过虚假陈述规避严格评定程序（第 143 段）。

6.3 边缘情形的三大判定范式

·实质超出（Substantially exceeds）：安全编排自动化响应系统（SOAR）具备 SIEM 的日志能力，但核心在于自动化响应，实质超出 SIEM，不归入该类（示例 59）。

·实质不足（Substantially falls short）：简单日志采集图表工具不具备数据关联分析与告警能力，实质不足以构成 SIEM，不归入该类（示例 60）。

·仅为增强补充：附加功能仅为了补充或增强既有核心能力时，产品分类维持不变。

6.4 合格评定程序的选择路径与符合性推定边界

图示：评定程序选择与符合性推定（Presumption of Conformity）边界

【自评资格与符合性推定边界的区别】
重要类 I 产品走模块 A 内部自评的资格取决于协调标准是否覆盖其“核心功能”相关风险；
而第 27(1) 条的“符合性推定”仅及于标准实际覆盖的具体风险。若产品搭载了标准未覆盖的附加高危通信功能，未覆盖部分不享有法律推定，须单独在技术文档中论证安全控制措施（示例 64、65）。

第七章：网络安全风险评估、供应链尽职调查与 SBOM（对照第 7 章）

指南第 7 章（第 156–177 段，示例 66–67）确立了基于风险的设计原则，规定了第 13(2) 条风险评估与第 13(5) 条供应链尽职调查的实施机制。

图示：网络安全风险评估流程与基于风险的设计义务

7.1 风险评估的客观法定纪律（第 13(2) 条）

·排除主观商业容忍度：企业内部风险偏好、商业策略或预算限制，不能作为认定风险已妥善处理的依据。

·残余风险客观可接受：残余风险的存在不意味着可由制造商自行决定接受；只有在采取充分措施使残余风险处于合理受控状态后，方可投放市场。

·禁止转嫁设计缺陷给用户：制造商不得通过用户协议免责条款或提示要求用户在封闭网络中运行，以弥补产品自身缺乏鉴权等设计缺陷。用户信息仅为辅助运维，不能豁免产品内建安全义务。

7.2 附件 I 第一部分第 (1) 项基于风险的设计义务

附件 I 第一部分第 (1) 项要求产品须以基于风险的方式进行设计、开发与生产，以确保适当的安全水平。该条款属于兜底性实质要求，用于覆盖其他具体条款未充分涉及的特定风险。

7.3 供应链尽职调查与 SBOM（第 13(5) 条）

图示：供应链尽职调查要求与产品族（Product Families）合规文档复用

·尽职调查要求：明确产品对组件的功能与安全要求；核实组件安全文档及合规证明；留存尽职调查记录。

·软件物料清单（SBOM）：附件 I 第二部分第 (1) 点要求编制机器可读的软件物料清单（推荐采用 SPDX 或 CycloneDX 格式），覆盖顶层及直接下层依赖。

7.4 “产品族”（Product Families）合规文档复用（第 172–177 段）

凡是共享核心硬件架构、运行相似基础固件、面向同一预期用途且面临相同网络安全威胁特征的型号系列，构成一个产品族。产品族内各变体可复用单一风险评估、单一技术文档及单一合格评定程序，并签署统一的 EU 符合性声明。外形颜色、外壳材质或不影响安全特性的硬件微调，无须拆分评定。

第八章：远程数据处理解决方案（RDPS）的技术落地（对照第 8 章）

指南第 8 章（第 178–208 段，涵盖第 8.3 节用例）依据第 3(2) 条规定了远程数据处理解决方案（RDPS）的判定要件。

图示：远程数据处理解决方案（RDPS）三项累计判定测试与决策矩阵

8.1 RDPS 的三项累计测试

根据 CRA 第 3(2) 条，远程数据处理构成 RDPS 须同时满足三项条件：

·在远处进行（At a distance）：处理发生在用户自有环境或运行环境之外（云端或边缘计算节点）；

·缺失导致产品无法执行某项功能：功能不限于核心功能，包含指令下发、数据同步、用户引导、参数配置、更新分发、访问控制等；

·软件由制造商设计开发或在其责任下开发：须为该制造商定制、按其规格构建的软件模块，而非第三方通用标准服务；实际服务器运营方是谁不具决定性。

8.2 RDPS 判定决策矩阵

三项条件判定组合	法定性质与合规处置要求
测试 ② 为【是】 + 测试 ③ 为【是】	正式构成 RDPS：属于产品不可分割的一部分。必须纳入产品风险评估，在技术文档中详尽描述，随同整机一并进行合格评定，并履行漏洞处理义务。
测试 ② 为【是】 + 测试 ③ 为【否】	不构成 RDPS，属于“第三方组件 / 外部依赖”：如产品依赖通用的公有云网盘存储。制造商须在产品本地侧采取强认证与传输加密等缓解措施，并对云厂商履行尽职调查。
测试 ② 为【否】	不构成 RDPS：纯粹用于事后统计分析且不影响设备任何即时运行的远端遥测分析，不构成 RDPS。

【排除边界说明】
企业内部 IT 系统（HR、财务、CRM、CI/CD 构建流水线）以及信息展示类官网，不属于 RDPS。RDPS 仅指软件与接口本身，承载该处理的服务器硬件设施不受 CRA 管辖。

8.3 官方行业用例剖析（第 8.3 节）

图示：RDPS 技术要求与官方五类行业用例解析

用例行业场景	是否构成 RDPS	官方理由与合规处理要求
手机银行应用 (8.3.1)	是 (银行专用接口)	银行接口为认证、提交支付与转账指令所必需，且由金融机构定制开发，属于 RDPS。后台总账系统属于外部依赖，App 须在本地端通过签名校验防范风险。
智能温控器 (8.3.2)	是 (运行于第三方 IaaS)	温控器依赖云端微服务执行智能调度，软件由厂商定制开发，属于 RDPS。对底层云厂商（IaaS）的尽职调查可通过索取 NIS 2 合规证明或欧洲网络安全认证证书实现。
电子书阅读器 (8.3.3)	否 (第三方 SaaS 存储)	阅读器虽可借助公有网盘备份，但网盘属于标准化第三方公有服务，非厂商定制，不属于 RDPS。按第三方组件处理，在本地端保障通信安全。
工业机械臂 (8.3.4)	是 (云端机器视觉算法)	云端实时轨迹规划算法由厂商开发，缺少该处理机械臂无法执行抓取，属于 RDPS。基本安全要求必须涵盖该视觉运算模块。
蜂窝通信网络 (8.3.5)	否 (通信管道)	运营商网络仅提供连接通道，既非 RDPS 亦非第三方组件。设备商无须对电信运营商进行供应链尽职调查。

第九章：强制报告机制、漏洞处理支柱与行业立法衔接（对照第 9 章）

指南第 9 章（第 209–257 段）对第 14 条强制报告义务、漏洞处理要求及与其他立法的衔接规则进行了详细规定。

图示：第 14 条强制报告义务与三级时限要求

9.1 第 14 条强制报告义务与三级时限

制造商须向指定的主导 CSIRT 协调机构与欧盟网络安全局（ENISA）双轨报送被积极利用的漏洞及严重安全事件：

·24 小时（早期预警）：获悉后毫不迟延，最迟 24 小时内提交早期预警，确认事件性质；

·72 小时（详细通知）：补充详细技术分析、受影响产品批次及初步处置措施；

·最终报告（Final Report）：被积极利用漏洞在缓解措施就绪后 14 天内提交；严重安全事件在 72 小时通知发出后 1 个月内提交。

【提前适用与追溯效力】
第 14 条报告义务于 2026 年 9 月 11 日提前适用，且适用于市场上所有流通中的产品（包含 2027 年 12 月 11 日前已投放的产品，以及支持期已届满的产品）。“知悉”（Awareness）标准与 GDPR 保持一致，指初步研判后达到合理确定性。

9.2 漏洞处理的三大核心支柱（附件 I 第二部分）

图示：漏洞处理三大支柱：上游协作、KEV 禁令与定期动态测试

·上游通报与修复共享：发现所集成组件存在漏洞须通报上游维护者；开发出修复方案的，应以机器可读、开源许可兼容形式回馈共享（第 13(6) 条）。

·已知可利用漏洞（KEV）禁令：产品投放市场时严禁带有收录于欧洲漏洞数据库等权威库的已知可利用漏洞（KEV）。“可利用”指在真实生产运行条件下能被有效攻击（第 9.2.2 节）。

·定期有效测试与审查：定期审查外部新威胁输入，动态更新测试集并执行渗透与回归测试，非机械重复静态测试（附件 I 第二部分第 3 点）。

9.3 行业法规排除与既有证书效力

图示：与部门立法衔接及企业合规实施四步路线图

·汽车法规排除：受联合国 UNECE 体系条例 (EU) 2019/2144（汽车）及条例 (EU) 168/2013（两轮车）管辖的车辆及专供零部件排除在 CRA 外；但在公开市场零售的通用模组仍受 CRA 约束（第 9.3.1 节）。

·既有证书过渡期：依据无线电设备指令（RED 2014/53/EU 授权条例 (EU) 2022/30）或机械条例（(EU) 2023/1230）签发的 EU 型式检验证书，网络安全部分的效力法定认可维持至 2028 年 6 月 11 日（第 69(1) 条）。

第十章：合规落地实施要点与条文对照稽核表

依据官方指南全篇规定，合规实施应按照以下四个阶段展开：

·阶段一：界定范围与主体定性 —— 确认产品是否具备数据连接；区分本地运行 PDE 与纯云端 Web 服务；识别后台 RDPS 边界；界定开源主体角色。

·阶段二：定级与双层风险评估 —— 确定唯一核心功能划分安全类别；开展第 13(2) 条客观风险评估；执行第三方组件尽职调查并生成 SBOM。

·阶段三：技术文档与合格评定 —— 对标协调标准并论证覆盖缺口；选定模块 A 自评或第三方机构评定；签署符合性声明并加施 CE 标志。

·阶段四：上市后维持与应急响应 —— 明确并公示支持期（至少 5 年）；2026-09-11 前就绪 24h/72h 应急报告通道；执行 KEV 排查与持续漏洞更新。

全文逐章核心考点与条文对照稽核表

指南章节	核心条文依据	核心考点与判定法则	对应实务示例	PPT页码
第 1 章引言	第 26(1) 条 Recital 1–10	非约束性行政指导；终局司法解释权归 CJEU；与 2025 FAQs 的互补定位	—	Slide 03
第 2 章适用范围	第 3(1)、(21)、(22) 条第 2(1) 条	PDE 四大形态；数据连接测试（排除纯电平触发）；用户侧执行 vs SaaS；代码托管非投放	Examples 1–12	Slide 04–06
第 3 章开源软件	第 3(48)、3(14) 条第 24(1)–(3) 条	FOSS 双要件；维护者 vs 贡献者责任切割；商业投放七大准则；管理者 Steward 三级调节	Examples 13–34	Slide 07–09
第 4 章重大修改	第 3(30)、2(6) 条第 21、22 条	影响基本要求或预期用途；备件维修豁免（相同安全特性）；安全更新 vs 架构边界变动	Examples 35–51	Slide 10–12
第 5 章支持期	第 13(8)、(10)、(19) 条 Recital 60	以预期使用时间为基准；5 年底线保障；第 13(10) 条免除旧版修补的免费升级无额外成本要件	Examples 52–56	Slide 13–14
第 6 章产品分级	第 7、8 条附件 III、IV、第 32 条	四级架构（默认/重要I/重要II/关键）；唯一核心功能判定；SOAR/SIEM 边界；标准推定边界	Examples 57–65	Slide 15–17
第 7 章风险评估	第 13(2)、(5) 条附件 I 第 I、II 部分	残余风险客观性；严禁转嫁设计缺陷给用户；SBOM 规范；产品族 Product Families 复用	Examples 66–67	Slide 18–19
第 8 章远程处理	第 3(2) 条 Recital 11–15	RDPS 三项累计判定（远处/不可或缺/责任下定制）；接口控制；官方五大行业用例剖析	Section 8.3	Slide 20–21
第 9 章报告衔接	第 14、13(6)、69(1) 条附件 I 第 II 部分	第 14 条三级时限（24h/72h/最终报告，2026-09-11 提前适用）；KEV 禁令；汽车排除与 RED 证书衔接	Sections 9.1–9.3	Slide 22–24