网络韧性法案CRA与 EUCC 认证
衔接实施
全面总结报告：要求映射、评估边界与实施路径
覆盖法规逻辑、Common Criteria 技术要素、产品范围、漏洞治理与产业实施
图 1｜CRA 要求、EUCC 证据与符合性推定的关系
一句话结论 EUCC 可为 CRA 要求提供认证证据。按 CRA 第27条，推定仅及于证书实际覆盖的要求，并须满足适用的保障级别条件；技术映射本身不是法律意义上的最终覆盖认定。 |
报告结构
1 执行摘要与法规逻辑
2 EUCC/CC 机制与技术映射
3 漏洞处理要求
4 风险评估、TOE 范围与远程处理
5 关键/重要产品市场差异
6 产业实施策略
7 认证机构与时间安排
8 落地核对清单与结论。
1. 执行摘要｜目标、范围与核心判断
本报告梳理《网络韧性法案》（CRA）与欧盟网络安全认证（EUCC）的衔接方式，重点解释：哪些 CRA 要求可由 EUCC 技术评估提供证据，风险评估如何决定要求适用性，认证对象边界如何与上市产品范围对齐，以及如何通过 PP、ST 和漏洞管理流程弥合差距。
1.1 适用背景
CRA 为投放欧盟市场的数字元素产品设定横向网络安全要求。数字元素产品可包括软件或硬件产品、单独投放市场的组件，以及由制造商设计开发或负责、且缺失会阻止产品某项功能的远程数据处理方案。产品类别按风险区分；重要产品分为不同类别，关键产品接受更严格的安全审视。
制造商可通过适用的协调标准、共同规范、认可的合格评定程序或欧洲网络安全认证方案等方式证明符合要求。EUCC 是可选路径，而不是 CRA 合规的唯一或普遍强制方式。
核心结论
·符合性推定不是“有 EUCC 证书就覆盖全部 CRA”。CRA 第 27 条规定，推定仅适用于 EU 声明或证书（或其部分）所覆盖的 Annex I 基本网络安全要求；相关认证至少须达到“实质级（substantial）”保障水平。
·EUCC 认证不是强制合规途径。制造商仍可使用 CRA 允许的其他路径；即便选 EUCC，也需逐项说明映射及覆盖边界。
·CRA Annex I Part I 的适用性可由制造商风险评估支持；Part II 的漏洞处理义务不以风险评估为前提，须在所有适用情形下满足。
·技术覆盖之外还要核对“产品范围”：EUCC 的 TOE 可能小于上市产品；CRA 还可能把制造商设计/负责、缺失后会阻止产品某项功能的远程数据处理方案纳入产品范围。
·市场实施应优先复用和更新成熟 Protection Profiles（PP），特别是严格一致性 PP；没有 PP 的产品可采用 CRA 定制 ST/PP 等方式。
判断原则 符合 CRA 的主张应同时回答四个问题：要求是否覆盖、产品范围是否完整、远程处理是否处理、保证活动是否足够。技术映射用于组织证据，但不能代替正式合格评定与法律判断。 |
2. 两套框架的衔接：概念与 Part I 映射
EUCC 以 CC（Common Criteria）评估产品的安全功能与保障证据。TOE 是被评估对象边界；SFR 描述 TOE 应具备的安全功能；SAR 描述评估所需的保证活动。SPD（Security Problem Definition）界定资产、威胁、假设和运行环境，并支持确定 SFR/SAR。PP 给某类产品定义可复用基线；ST 则描述某一具体 TOE 的安全目标和要求。
CRA Annex I Part I：安全功能要求的映射框架
下表列出可用于组织技术论证的 CC 组件示例。代码为 CC 组件名；“扩展”表示为表达特定 CRA 功能而可能需要定义额外组件。所列映射不是排他清单；具体产品应结合风险、TOE 边界和等效技术措施逐项论证。
CRA 要求主题 |
对应 CC 技术要素示例（提案性映射） |
风险为基础的设计（I.1(1)） |
ASE_SPD.1、ASE_OBJ.1、ASE_REQ.1（SAR）：以 SPD/目标/需求论证风险与要求选择。 |
无已知可利用漏洞（I.1(2)(a)） |
AVA_VAN.1 漏洞调查；达到 substantial 或 high 的 EUCC 评估可提供该项的直接保证证据。 |
默认安全与重置（I.1(2)(b)） |
FMT_SMF.1（管理功能/恢复默认）；可考虑扩展 ADV_ARC.2 默认安全架构。可信管理员假设等需结合部署条件论证。 |
漏洞修复/安全更新（I.1(2)(c)） |
EUCC 补丁管理程序相关 SFR/SAR：默认自动更新、关闭选项、更新通知、暂缓机制等；应明确具体技术机制与评估活动。 |
访问控制与未授权访问报告（I.1(2)(d)） |
FIA_UID/FIA_UAU、FDP_ACC/FDP_ACF；FAU_GEN 配合 FAU_SAA 或 FAU_STG。 |
数据机密性/完整性（I.1(2)(e)–(f)） |
FDP_SDC、FCS_COP、FTP_ITC/FTP_TRP；完整性可用 FDP_SDI 与 FAU_GEN 等。 |
数据最小化（I.1(2)(g)） |
ADV_PDM.1 已处理数据最小化（扩展 SFR 示例）。 |
可用性与对其他服务影响（I.1(2)(h)–(i)） |
FRU_FLT、FPT_FLS；FPT_INI/FPT_TST；网络控制类产品可用 FDP_IFC/FDP_IFF 等。 |
攻击面、事件缓解/恢复（I.1(2)(j)–(k)） |
AVA_VAN.1、ADV_FSP.1、AGD_OPE.1；视风险加入 FPT_FLS/FPT_RCV、ADV_ARC/ADV_TDS。 |
日志与内部活动监测（I.1(2)(l)） |
FAU_GEN.1、FMT_SMF.1、FMT_SMR.1；报告提示定义记录事件及用户关闭机制。 |
永久删除与安全转移（I.1(2)(m)） |
FMT_SMF.1、FDP_RIP.1；转移可用 FDP_ETC.1/.2 和 FTP_ITC.1。 |
解释边界：如果某一 CRA 要求对应多个 SFR/SAR，应完整纳入相关要素，或说明替代等效技术措施；同时处理 CC 组件依赖，或论证为何不需要。风险分析可支持 Part I 要求不适用的理由。
3. Annex I Part II｜漏洞处理要求不可跳过
Part II 主要约束制造商漏洞管理流程。EUCC 可用 SAR、补丁机制与程序证据承接其中一部分要求；商业、组织性义务还需由政策、流程、合同声明和持续运营证据支撑。与 Part I 的区别是：Part II 不依赖制造商风险评估来决定是否适用。
Part II 要求主题 |
EUCC/CC 对应方式与限制 |
识别并记录漏洞/组件，含机器可读 SBOM（至少顶层依赖） |
ALC_FLR.1；可采用扩展 ALC_SBM.1（SBOM）。 |
及时处理漏洞并提供安全更新；可行时与功能更新分开 |
ALC_FLR.1 + 补丁技术机制；或 ALC_FLR.3/.4（其中 .4 扩展）。 |
定期测试与审查产品安全 |
ALC_PSR.1 周期性安全审查与测试。 |
更新发布后披露已修复漏洞及影响/严重性/修复指引 |
ALC_FLR.1；应公开漏洞说明、受影响产品识别信息、影响与修复指引；延迟公开须有正当理由。 |
建立并执行协调漏洞披露政策 |
单靠 SAR 不足；需提交并落实漏洞管理与披露程序。 |
便利外部漏洞报告，提供联络地址 |
ALC_FLR.2；同时维护并公布外部漏洞接收渠道。 |
安全分发更新，及时修复；适用时自动更新 |
ALC_FLR.1 + 补丁机制，或 ALC_FLR.3/.4 的相关组合。 |
安全更新免费提供（定制产品商务用户另行约定除外），附咨询信息 |
技术要素不能完全解决“免费”这一商业属性；应有明确声明与可审查证据，并接受持续监督。 |
读表要点
·ALC_SBM.1、ADV_PDM.1、ALC_FLR.4 等扩展组件需要明确其定义、评估活动和可验证证据，不应误作 CC 标准中已有的通用组件。
·多个 SAR 共同对应某项 CRA 要求时，应纳入全部必要要素，或以技术论证说明等效实现；同时处理组件依赖。
·协调披露政策、免费更新等需由流程、声明、合同/商业安排或持续监督等证据支撑；“完成 CC 评估”本身不能自动证明所有运营义务已履行。
判读原则 Part I：先做风险评估，再说明哪些要求适用及如何实现。Part II：不能以“风险较低/PP 未写”为由整体免除；发现缺口须以流程、证据、PP/ST 更新等方式补足。 |
4. 风险评估、产品范围与远程数据处理
4.1 风险评估：SPD 是桥梁，但需要补充说明
CRA 第 13 条要求制造商对产品进行网络安全风险评估，并在技术文档中说明 CRA Annex I Part I 的适用性及实施方式、Part II 漏洞处理方式。EUCC 中的 SPD 与 CRA 风险评估有相似之处：都围绕资产、威胁、环境、预期用途等确定安全要求。但 SPD 不一定逐项明示“为什么 CRA 某项不适用”，因此应补充适用性声明与理由文件，并保留从风险、威胁到 SFR/SAR 的可追踪链条。
4.2 范围：TOE 可能小于上市产品
·常见情况：只评估操作系统内核/驱动/安全库、软件库、硬件设备固件，或芯片中的安全元件，而 CRA 产品是完整软件/硬件产品。
·要么使 TOE 边界与 CRA 产品范围一致；要么依据 SPD、威胁与技术结构，证明较小 TOE 足以保护整个产品，包括未纳入 TOE 的部分。并非所有产品都能作出这种证明。
4.3 远程数据处理：当前 EUCC 的明显难点
CRA 定义中的远程数据处理，是由制造商设计开发或负责、且缺失会阻止产品某项功能的远端数据处理。典型风险场景包括云托管管理控制台、威胁数据库、后台服务；不支持产品功能的网站，以及由制造商责任范围外开发的云服务，不因此自动纳入 CRA 范围。当前 CC/EUCC 方法不便于直接评估云端解决方案；不少认证范围只覆盖产品与云服务间的安全通信，而未覆盖云服务本身。
风险分析与 CC 技术证据链（归纳绘制）
实施建议 优先在 EUCC 范围内纳入远程处理方案；若不可行，至少覆盖并论证安全接口，明确 SPD 假设/运行环境要求，并说明远程部分所采用的标准、共同规范或其他认证/评估方式。 |
5. 认证市场现状：关键产品与重要产品的差别
不同产品类别的认证成熟度、PP 使用方式、保证级别、范围边界和远程处理依赖均有差异。下表呈现典型规律；具体产品仍应核验所用 PP/ST 与实际部署架构。
维度 |
关键产品（CRA Annex IV） |
重要产品（CRA Annex III） |
典型对象 |
安全盒硬件设备、智能电表网关、智能卡/安全元件 |
CRA Annex III Class I/II；如身份管理、浏览器、口令管理器、恶意软件防护、VPN、网络设备、OS、SIEM、虚拟化等。 |
PP 使用与成熟度 |
高保障 PP 普遍；严格/可证明一致性常见；无 PP 认证案例很少 |
类别差异大；PP_APPSW 与 CPP_ND 是常见基础；部分类别无主流 PP。 |
覆盖程度（总体判断） |
直接映射覆盖较低，但 SPD/替代技术路径可能使 Part I 的间接覆盖较高；仍可能存在漏洞处理缺口。 |
典型 PP 存在多项 Part I 和 Part II 缺口；数据最小化、自动更新等并非传统 CC PP 的常规内容。 |
产品范围 / 云端 |
多数典型案例范围接近全产品；关键产品是否依赖远程处理仍须按具体产品核实。 |
部分 PP 覆盖完整产品，部分仅子集；远程管理控制台、威胁数据库等云服务常被排除在评估外。 |
主要实施约束 |
先基于风险分析说明 Part I 要求适用性；Part II 漏洞流程若缺失仍需补足。 |
exact conformance 常限制在 PP-compliant ST 里新增 SFR/SAR，可能必须更新 PP；逐产品修改不可行或不被允许。 |
关键市场信号
·关键产品：高保障、成熟技术域评估提供较强保证基础；在充分风险论证下，Part I 的部分差异可通过适用性分析解释，但不能据此推定 Part II 已覆盖。
·重要产品：CPP_ND、PP_APPSW 等常见 PP 可能在默认安全/重置、自动更新、数据最小化、韧性/恢复、数据删除、漏洞管理等方面存在缺口。
·重要产品类别与部署方式多样，逐案验证不可省略：应回到所用 PP/ST、TOE 与云端/本地架构确认实际覆盖。
可互操作性关键点 exact conformance 的 PP 往往不允许 ST 任意增补要求。因此，在需要增加 CRA 技术要素时，优先考虑由 PP 维护社区统一更新，而不是让每个制造商各自偏离 PP。 |
6. 产业实施策略：在统一性与灵活性之间平衡
PP 路径与独立 ST 路径
PP / ST 实施选项的权衡
选项 |
实施权衡 |
单独 CRA 定制 ST（不依赖 PP） |
灵活，可按产品纳入所需 SFR/SAR；但统一性较弱。市场普遍偏好 PP，独立 ST 的使用占比较低。 |
通用 CRA PP |
有利于统一，但技术中立型通用 PP 不易设计；可能过大复杂；与 exact conformance PP 不易互操作。 |
模块化 PP / PP-configuration |
可组合功能模块、兼顾部分灵活与协调；组合有限且管理复杂，与既有 PP 的互操作性仍有挑战。 |
功能/保证包（functional & assurance packages） |
可复用、灵活，与非 exact PP 互操作性较好，协调性中等；exact PP 通常仍需更新。 |
更新主流 PP（优先策略） |
在 PP 层完成映射、适用性与范围论证；若发现无法论证的 ESR/范围/远程处理缺口，更新 PP 并复认证。更符合成熟市场和 exact conformance 现实。 |
建议的两阶段流程
第一阶段｜PP 评估：对 Annex I Part I 做风险适用性判断并形成声明；逐项映射 SFR/SAR；检查 TOE 与产品范围；识别远程处理方案及其覆盖方式。由 CRA Notified Body 审查确认，公开提供 PP 用户复用。无缺口时，PP-compliant EUCC 认证可作为对应要求的证据。
第二阶段｜PP 更新：若发现 ESR 覆盖、TOE 范围或远程处理缺口，修改 SPD、SFR、SAR 或 TOE 边界；对远程处理补充信任假设、运行环境目标及安全通信要求；更新后重新认证，并提供 CRA 合规声明。
无 PP 路径：制造商对 ST 重复同样的三项核查；出现缺口需修订 ST。可采用 CRA 定制 PP/功能包，减少逐产品重复设计与审查。
7. 认证机构、治理与迁移安排
7.1 CAB 与 CRA 合格评定机构的协作
EUCC CAB（合格评定机构）具备 Common Criteria 评估经验，能够对安全目标、设计文档、实现、测试及漏洞分析开展验证。要将这种能力用于 CRA 合规判断，还需补充 CRA 专项训练，特别是 CRA 风险评估、Annex I 要求适用性、产品/远程处理范围与技术文档证据之间的关联。
·同时具备 EUCC CAB 与 CRA Notified Body 资质的机构，可承担 PP 更新方案审查、CRA 映射确认及证书覆盖声明复核等工作。
·治理重点应放在复用：将一次完成的 PP 级适用性判断、SFR/SAR 映射和范围分析公开供符合该 PP 的制造商使用，减少制造商与 CAB 重复逐产品分析。
7.2 关键迁移时间点
事项 |
实施含义 |
CRA / EUCC 时间点 |
CRA 于 2024 年 12 月 10 日生效，设 36 个月过渡期；EUCC 于 2024 年 1 月 31 日通过，并自 2025 年 2 月 27 日起适用。具体 CRA 义务仍按法规规定的分阶段日期执行。 |
CC 版本迁移 |
原文所述迁移政策：CC v3.1 R5 可用于产品与 PP 评估的起始日期不晚于 2024-06-30；其后基于 v3.1 的再评估/复评，可在初始认证日起最多 2 年内启动。 |
旧版 PP 使用边界 |
基于 CC:2022、且使用按 CC v3.1 认证 PP 的 ST，按迁移政策可接受至 2027-12-31。此为迁移政策日期，不应概括为所有旧版 PP 均可继续认证至该日。 |
PP 更新安排 |
主流 PP 应尽早评估 CRA 缺口，并在迁移窗口内完成适用性论证、必要更新与重新认证，避免在全面适用前集中积压。 |
7.3 建议的组织级工作流
建立跨法规、产品安全、研发、运维、法务与认证团队的责任矩阵；以产品清单和组件依赖为起点，形成要求映射表、风险评估、PP/ST 版本控制、TOE/云端范围图、SBOM、漏洞披露及更新证据台账。将 PP 更新、CAB 资源、测试周期和生命周期维护纳入年度认证计划。
资源规划 Common Criteria 认证通常周期较长、成本较高；补加 SFR/SAR、扩展评估范围或引入云端服务会增加制造商与 CAB 的投入。应尽早启动差距分析，并优先处理 exact conformance PP 与共享基础组件。 |
8. 落地核对清单与结论
给制造商、PP 作者与评估机构的核对清单
·产品识别：界定上市产品、组件、预期用途、运行环境以及 CRA 风险类别。
·要求覆盖：逐项列出 Annex I Part I 适用性、依据、SFR/SAR 对应和证据；Part II 漏洞处理义务单独核验。
·依赖与扩展：确认所选 CC 组件的依赖；识别扩展组件及其定义、评估活动和验证证据。
·边界一致：将 EUCC TOE 与 CRA 产品范围比较；TOE 较小时，论证其对完整产品（含未评估部分）的保护充分性。
·远程数据处理：识别 CRA 定义下的远端处理方案；优先纳入范围，无法纳入时至少评价接口、信任假设及替代评估路径。
·漏洞治理证据：SBOM、漏洞接收渠道、修复时限、补丁安全分发、定期测试、协调披露、修复信息公开、免费更新声明等分别留证。
·一致性方式：确认 PP 采用 Strict、Strict + Demonstrable 或 Exact；若为 Exact，不可任意增删改要求，新增 CRA 要素通常需在 PP 层处理。
·合规主张：把证书、PP/ST 版本、保障级别、覆盖的 CRA 要求、范围边界及限制写入可审查的声明与技术文档。
综合结论
EUCC 的结构化评估可以为 CRA 合规提供重要技术证据：SPD 支持风险分析，SFR/SAR 可映射到 CRA 安全和漏洞处理要求，CAB 评估能验证要求是否实现。但这种桥接不是自动的。应以“要求覆盖 + 产品范围 + 远程处理 + 保证证据”四项同时成立为目标，并通过更新主流 PP 实现协调一致。
适用边界
本文中的 SFR/SAR 对应属于技术分析框架，具体产品应以其适用法规、认证方案、协调标准、共同规范和有效证书为准。符合性推定只及于证书实际覆盖的要求；法规、实施规则与标准更新时，要求映射、PP/ST、技术文档及合格评定结论均应相应复核。本文为实施层面的总结，不替代个案法律审查或正式合格评定。
最终判断 不要把“取得 EUCC 证书”直接写成“已满足全部 CRA”。应明确：满足哪些 CRA 要求、哪些基于风险分析不适用、证书覆盖哪些组件/远程服务、未覆盖部分如何补充评估。 |
