EUCC，全称 European Common Criteria-based Cybersecurity Certification Scheme，即欧盟基于通用准则的网络安全认证方案。它是欧盟《Cybersecurity Act》（Regulation (EU) 2019/881）框架下首个正式落地的欧洲网络安全认证方案，由 Commission Implementing Regulation (EU) 2024/482 建立，并自 2025年2月27日 起可签发 EUCC 证书。

EUCC 适用于 ICT 产品，包括硬件、软件、芯片、安全元件、智能卡、防火墙、路由器、交换机、操作系统、数据库、加密存储、检测响应平台、SIEM、IDS/IPS 等。对于计划进入欧洲市场的网络安全产品、物联网设备、工业设备、安全芯片和关键基础设施相关产品，EUCC 正在成为重要的第三方安全评估路径。

从实施角度看，EUCC 不是一个把产品安全能力转化为可评估、可复核、可追溯证据链的过程。

---

一、EUCC认证的核心标准体系

EUCC 基于 Common Criteria，也就是通用准则体系。其主要技术基础包括：

• ISO/IEC 15408：IT安全评估准则，也就是 Common Criteria。
• ISO/IEC 18045：IT安全评估方法，也就是 Common Evaluation Methodology，简称 CEM。
• Regulation (EU) 2019/881：欧盟网络安全法案，建立欧盟网络安全认证框架。
• Implementing Regulation (EU) 2024/482：正式建立 EUCC 认证方案。
• ENISA EUCC Scheme Documents：包括 EUCC 实施文件、SotA 文件、指南和技术领域要求。

EUCC 的认证对象是明确边界内的 TOE，即 Target of Evaluation，被评估对象。

例如：

• 防火墙产品的 TOE 可能是防火墙设备、固件、管理接口、访问控制模块和审计模块。
• 安全芯片的 TOE 可能是芯片硬件、安全存储、加密运算模块、密钥管理模块和防篡改机制。
• 数据库产品的 TOE 可能是数据库服务端、权限控制、审计、加密、备份恢复和安全管理接口。

TOE 定义清楚后，认证才知道“评估什么、不评估什么、证书覆盖什么”。

---

二、EUCC认证等级：Substantial 与 High

EUCC 认证提供两个保障等级：

EUCC等级	对应含义	常见适用场景
substantial	中高风险场景下的安全保障	网络设备、软件产品、普通ICT安全产品
high	高风险场景下的更高保障	安全芯片、安全元件、智能卡、高安全等级产品

EUCC 中的 substantial 和 high 与 Common Criteria 的脆弱性分析组件 AVA_VAN 有映射关系：

• substantial：通常对应 AVA_VAN.1 或 AVA_VAN.2。
• high：通常对应 AVA_VAN.3、AVA_VAN.4 或 AVA_VAN.5。

AVA_VAN 等级越高，实验室对产品进行脆弱性分析和攻击路径验证的深度越高。对于 high 等级，评估通常会更加关注攻击潜力、攻击复杂度、攻击者能力假设、脆弱性利用路径和残余风险。

---

三、EUCC认证涉及哪些角色

一个完整 EUCC 项目通常涉及以下角色：

角色	作用
申请人 Applicant	通常是产品制造商、供应商或证书申请主体
证书持有人 Holder	获证后承担证书维护和漏洞管理义务
认证机构 Certification Body	审核评估结果并签发 EUCC 证书
ITSEF实验室	执行文档审查、产品测试、脆弱性分析等技术评估
国家网络安全认证主管机构	监督本国认证机构和认证实施
ENISA	维护欧盟网络安全认证框架、EUCC信息和证书库

企业在项目启动时，应先明确申请主体、证书持有人、产品开发商是否一致。如果产品由多个主体参与开发，例如硬件厂商、软件厂商、云平台服务商、第三方组件供应商，还需要提前梳理责任边界和材料提供责任。

---

四、EUCC认证实施流程详解

结合实际项目，EUCC 可以拆分为 10 个主要步骤。

1. 产品适用性分析

这一阶段要判断产品是否适合走 EUCC 路径。

重点确认：

• 产品是否属于 ICT 产品；
• 是否已有适用的 Protection Profile，简称 PP；
• 是否涉及 EUCC 的特定技术领域；
• 产品目标客户是否要求 substantial 或 high；
• 是否与 CRA、NIS2、行业采购或关键基础设施要求相关；
• 现有产品成熟度是否能支撑评估。

如果产品是安全芯片、智能卡、安全元件，还需要重点关注 EUCC 中关于 smart cards and similar devices 的技术领域要求和 SotA 文件。

2. TOE边界定义

TOE 边界是 EUCC 项目的基础。

需要明确：

• 产品名称；
• 产品型号；
• 硬件版本；
• 软件版本；
• 固件版本；
• 管理平台是否纳入；
• 云端服务是否纳入；
• 第三方组件是否纳入；
• 外部认证服务器是否纳入；
• 外部日志服务器是否纳入；
• 运行环境和依赖条件；
• 哪些接口属于认证范围；
• 哪些功能不属于认证范围。

例如，一款防火墙产品可以把本地防火墙设备、Web管理界面、CLI接口、访问控制模块和日志审计模块纳入 TOE，但把外部日志平台、云端授权系统和第三方身份认证服务器排除在 TOE 外。

TOE 边界越清晰，后续评估争议越少。

3. 确定安全声明与认证等级

EUCC 不是评估“所有安全能力”，而是评估产品声明的安全能力。

企业需要确定：

• 目标保障等级是 substantial 还是 high；
• 是否声明符合某个 PP；
• 选择哪些 SFR；
• 选择哪些 SAR；
• 产品要抵御哪些威胁；
• 产品使用环境有哪些假设；
• 管理员、用户、攻击者角色如何定义。

这一阶段的输出会直接进入 ST。

4. 编制Security Target

ST，即 Security Target，是 EUCC/CC 项目最核心的文件。

ST 通常包括：

• ST 引言；
• TOE 引言；
• TOE 描述；
• 符合性声明；
• 安全问题定义；
• 威胁；
• 假设；
• 组织安全策略；
• 安全目标；
• 扩展组件定义；
• SFR 安全功能要求；
• SAR 安全保障要求；
• TOE 安全功能摘要；
• 安全目标与安全要求的合理性说明。

ST 可以理解为产品的“正式安全声明书”。实验室后续会围绕 ST 做评估，证书范围也会围绕 ST 展开。

EUCC 还要求公开版或脱敏版 ST 能够真实反映完整 ST 的安全属性，不能删除理解 TOE 安全特性所必需的信息。

5. 安全功能开发分析

这一阶段要把产品安全功能从“功能描述”转换成“评估可理解的安全机制”。

常见安全功能包括：

• 身份认证；
• 访问控制；
• 权限管理；
• 安全审计；
• 加密通信；
• 密钥管理；
• 安全启动；
• 安全更新；
• 安全存储；
• 接口保护；
• 安全状态保持；
• 随机数生成；
• 防篡改；
• 安全管理；
• 用户数据保护。

例如，防火墙产品不能只写“支持访问控制”，而要说明策略匹配逻辑、默认策略、冲突处理、接口方向、协议字段、规则优先级、日志记录和异常处理。

6. 准备指导文档

EUCC 很重视产品能否被安全安装、安全配置和安全使用。

指导文档通常包括：

• 安装指南；
• 初始化配置指南；
• 管理员指南；
• 用户指南；
• 安全配置指南；
• 运行环境要求；
• 默认配置说明；
• 默认账号和口令策略；
• 证书配置说明；
• 密钥配置说明；
• 日志配置说明；
• 备份恢复说明；
• 升级和补丁说明；
• 安全交付和验收说明；
• 已知限制和安全注意事项。

如果 ST 中假设产品必须部署在受控网络环境中，或者必须由受信任管理员操作，那么这些要求必须在指导文档中体现。

7. 生命周期安全材料准备

EUCC 不只看产品样品，还看产品生命周期控制。

常见材料包括：

• 开发流程说明；
• 配置管理流程；
• 版本控制说明；
• 缺陷管理流程；
• 变更管理流程；
• 构建环境说明；
• 发布流程说明；
• 交付流程说明；
• 漏洞管理流程；
• 补丁管理流程；
• 供应链组件管理；
• 第三方库管理；
• 开源组件清单；
• 开发环境安全控制；
• 生产环境安全控制。

对于 high 等级或安全芯片类产品，生命周期控制会更严格，可能涉及开发场所、生产场所、密钥材料、交付链路和人员访问控制。

8. 实验室文档审查

ITSEF 实验室会对提交材料进行审查。

常见审查点包括：

• TOE 边界是否清晰；
• ST 逻辑是否一致；
• SFR/SAR 选择是否合理；
• 产品版本是否一致；
• 设计文档是否支撑安全功能；
• 指导文档是否覆盖安全使用要求；
• 测试材料是否覆盖安全功能；
• 配置管理是否保证版本可追溯；
• 漏洞管理流程是否满足 EUCC 要求。

这个阶段经常出现多轮问题单。企业需要根据实验室意见补充材料、修改 ST、澄清产品行为或补充测试证据。

9. 实验室测试与脆弱性分析

实验室会基于 ST、CEM 和适用 SotA 文件执行技术评估。

测试活动可能包括：

• 安全功能独立测试；
• 接口测试；
• 权限绕过测试；
• 异常输入测试；
• 默认配置检查；
• 安全通信检查；
• 加密机制检查；
• 日志审计检查；
• 安全更新测试；
• 配置导入导出测试；
• 脆弱性扫描；
• 已知漏洞分析；
• 攻击路径验证；
• 攻击潜力计算。

对于 high 等级，脆弱性分析通常更深入。实验室会结合公开漏洞、产品架构、接口暴露面、攻击者能力假设和 AVA_VAN 要求判断产品是否存在不可接受风险。

10. 认证决定、发证与后续监督

实验室完成评估后，会形成评估技术报告。认证机构基于评估结果作出认证决定，符合要求后签发 EUCC 证书。

获证后并不意味着工作结束。证书持有人还需要持续履行：

• 漏洞监测；
• 漏洞接收；
• 漏洞影响分析；
• 补丁管理；
• 证书变更管理；
• 与认证机构和主管机构配合；
• 必要时接受监督活动。

EUCC 要求证书持有人建立并维护漏洞管理程序，并公开接收漏洞信息的方法。相关文档通常需要在证书到期后继续保存一段时间，以满足追溯要求。

---

五、EUCC认证常见问题

1. EUCC和CC认证是什么关系？

EUCC 是欧盟基于 Common Criteria 建立的网络安全认证方案。它沿用了 CC 的核心标准和评估方法，但证书在欧盟网络安全认证框架下签发，目标是实现欧盟范围内统一认可。

2. EUCC和EAL是不是一回事？

不是完全一回事。传统 CC 项目中常用 EAL 表达评估保障级。EUCC 使用 substantial 和 high 两个保障等级，并与 AVA_VAN 脆弱性分析组件进行映射。项目中仍会大量使用 CC 的 SFR、SAR、ST、TOE、PP 等概念。

3. EUCC认证周期多久？

周期取决于产品复杂度、保障等级、文档成熟度、实验室资源和整改次数。软件产品、网络设备、安全芯片的周期差异很大。通常，ST 编制、文档准备、实验室审查、测试整改和认证决定都会影响总周期。

4. 产品版本变更后证书还有效吗？

不一定。证书覆盖的是特定 TOE、版本和配置。如果产品发生安全功能、架构、依赖组件、运行环境或漏洞修复方面的重大变化，可能需要进行证书维护、补充评估或重新认证。

---

六、EUCC与CRA的衔接

EUCC 与 CRA 的关系需要重点关注。

CRA 是欧盟网络韧性法案，面向带有数字元素的产品。对于部分重要类和关键类数字产品，CRA 会提出更高的符合性评估要求。EUCC 作为欧盟已经落地的网络安全认证方案，在适用场景下可能成为企业证明产品满足网络安全要求的重要路径。

例如，安全芯片、安全元件、智能计量网关、防火墙、路由器、加密设备、工业物联网设备等产品，如果同时面对 CRA、客户招标和欧盟市场准入要求，就应把 EUCC 纳入整体合规路线图中考虑。

---

结语：EUCC认证的关键不是“拿证”，而是证据链

EUCC 认证真正难的地方，不是某一次测试，而是把产品安全能力用标准化语言讲清楚，并通过设计、开发、测试、配置管理、指导文档、漏洞管理和实验室评估形成完整证据链。

对于企业来说，越早明确 TOE 边界、ST 安全目标、认证等级、材料清单和实验室沟通机制，越能减少后期反复整改，提高认证效率。

浙江望安科技有限公司长期专注欧盟 EUCC、CRA、Common Criteria、IT 产品信息安全认证和物联网设备网络安全合规服务，可为防火墙、路由器、交换机、操作系统、数据库、安全芯片、安全元件、智能卡、智能计量网关、工业物联网设备及网络安全产品企业提供 EUCC 认证适用性分析、TOE 边界梳理、安全目标 ST 编制辅导、差距分析、技术文档准备、测试整改支持、漏洞管理流程建设、实验室沟通和第三方评估对接服务。

欢迎登入浙江望安科技有限公司官网，了解更多出海合规资讯~