本文件按照“法规事实—企业判断—项目行动”的顺序，系统解释欧盟通用准则网络安全认证方案EUCC。
对应PPT第 1 页｜封面与关键时间线
文件属性： 12页PPT静态图片均已嵌入Word；完整PPTX在文末以附件对象形式嵌入；Word与PPT元数据均不含作者署名。 |
02. 管理层结论：EUCC是产品安全保证工具，而非普遍强制认证
EUCC是欧盟网络安全认证框架下的具体产品认证方案。它的价值在于让ICT供应商以共同理解的评估方法展示产品安全保证水平，并使证书能在欧盟成员国范围内得到识别。[1] [3]
EUCC在默认法律状态下属于自愿认证。企业是否应启动认证，不应只看法规是否“强制”，还应结合产品的安全功能、目标市场、客户采购标准、行业规则、跨境销售安排和未来法规指定来判断。
管理层应同时避免两个误解：第一，EUCC只有Substantial和High两档保证等级，不等同于含Basic的通用三档框架；第二，EUCC证书不会自动完成CRA的全部市场准入义务。
管理建议： 以“产品—版本—预期用途—目标市场—保证等级—证书范围”为一个认证对象建立主数据台账。 |
对应PPT第 2 页｜管理层结论：EUCC是产品安全保证工具，而非普遍强制认证
03. 法律框架与关键时间线
EUCC的上位法律基础是Regulation (EU) 2019/881，即《网络安全法》。该框架授权欧盟委员会建立具体的欧洲网络安全认证方案。EUCC的直接实施法规是Commission Implementing Regulation (EU) 2024/482，而不是将2019/881本身称为EUCC法规。[1] [2]
实施条例于2024年2月7日发布，2024年2月27日生效；主体规则自2025年2月27日起适用。EUCC页面还记录了2024年12月和2025年12月的修订信息，因此新项目应以EUR-Lex最新合并文本与适用SotA文件为准。[2] [4]
CRA的时间线与EUCC不同。CRA于2024年12月10日生效，其漏洞与严重事件报告义务自2026年9月11日适用，主要市场准入义务自2027年12月11日适用。
法律文件 |
业务含义 |
Regulation (EU) 2019/881 |
建立欧盟网络安全认证框架，并规定认证默认自愿，除非其他欧盟或成员国法另有要求。 |
Commission Implementing Regulation (EU) 2024/482 |
规定EUCC范围、保证级别、认证参与者、证书、监督、SotA和保证连续性。 |
Regulation (EU) 2024/2847（CRA） |
为EUCC与产品网络安全市场准入规则的未来条件性衔接提供机制。 |
对应PPT第 3 页｜法律框架与关键时间线
04. 适用范围：哪些产品与客户应优先评估EUCC
EUCC适用于提交认证的ICT产品，包括硬件、软件、组件及其相关文档。保护轮廓也可以作为认证对象或作为产品认证的基准。EUCC不是“认证企业整体安全管理”的通用制度，认证范围必须落到具体产品、版本、配置、用途和运行环境。[2] [4]
欧盟委员会列示的典型产品包括芯片、智能卡和安全元件、硬件或软件防火墙、路由器、交换机、检测与响应平台、SIEM、IDS/IDP、数据二极管、操作系统、加密存储和数据库。[3]
企业应优先筛查安全功能明显、处于关键供应链、面向敏感或关键环境、需要跨境市场认可，或被客户采购要求列为安全认证前置条件的产品。
范围判断边界： “EUCC当前自愿”并不能得出“产品没有任何认证压力”。采购规范、行业法规、成员国要求或未来欧盟指定可能改变商业和合规优先级。 |
对应PPT第 4 页｜适用范围：哪些产品与客户应优先评估EUCC
05. 保证级别：Substantial与High究竟区别在哪里
EUCC以Common Criteria的AVA_VAN脆弱性分析家族来表达保证等级。Substantial对应AVA_VAN 1或2；High对应AVA_VAN 3、4或5。等级选择须与产品预期用途中的风险、攻击面、攻击者能力和事故影响相称。[2] [4]
保证级别表示评估与脆弱性分析的深度，并不表示产品永远没有漏洞。认证结论始终受Security Target、评估对象版本、配置、预期运行环境和证书具体范围限制。
High级别通常意味着更高的技术评估能力要求和国家认证机构的授权安排。项目开始前应核验拟合作的CB和ITSEF是否具备目标等级及相关技术域的有效范围。
维度 |
Substantial |
High |
AVA_VAN |
1或2 |
3、4或5 |
认证方式 |
第三方评估与认证；不允许企业自行声明替代。 |
第三方评估与认证；涉及更严格能力和授权要求。 |
选择关注点 |
常见安全保证需求与适当风险水平。 |
敏感/关键环境、更高攻击潜力与更严格抵抗能力需求。 |
对应PPT第 5 页｜保证级别：Substantial与High究竟区别在哪里
06. 认证路径：从Security Target到EUCC证书
EUCC项目的第一步不是测试，而是清晰界定认证对象。申请人要冻结产品版本、配置、预期用途、运行环境和目标等级，并将风险与安全目标编入Security Target。Security Target描述产品安全问题、应对目标以及所选择的功能与保证要求。[2]
ITSEF按照Common Criteria、Common Evaluation Methodology和适用的SotA文件执行技术评估，并形成技术评估报告。认证机构审查评估结果和方法的一致性后，作出认证决定并签发证书。
证书签发后，项目进入保证连续性管理。产品变更、补丁、威胁环境变化、证书即将到期或持证人要求重新确认抵抗能力，都可能触发复核或重新评估。
项目启动清单： 认证边界、产品用途与风险说明、Security Target、设计与开发证据、构建/配置、样品、漏洞管理与披露流程、变更管理记录。 |
对应PPT第 6 页｜认证路径：从Security Target到EUCC证书
07. 责任地图：申请人、ITSEF、认证机构与NCCA
申请人或证书持有人负责界定产品并提供评估所需的证据、产品和信息，同时在产品生命周期中维护与证书范围一致的状态。企业应把对外宣称的认证状态、版本信息和证书有效性纳入合规控制。
ITSEF是信息技术安全评估设施，负责执行技术安全评估并形成Evaluation Technical Report。Certification Body，即认证机构，负责基于评估结果作出签发、维护、暂停或撤回证书的认证决定。两者职能不同，不能混同。[2]
NCCA，即国家网络安全认证机构，负责通知、授权和监督相应实体，并可实施调查、投诉处理和抽样监测。法规要求NCCA按风险评估每年抽查至少4%的EUCC证书。
角色 |
不能替代的职责 |
申请人/持证人 |
定义范围、提供证据、管理产品变更和漏洞流程、确保宣传与证书状态一致。 |
ITSEF |
进行技术评估，形成技术结论和评价报告。 |
Certification Body |
审查并作出认证决定，签发、维护、暂停或撤回证书。 |
NCCA |
授权与监督CB/ITSEF，监测证书和处理国家层面的监督事项。 |
对应PPT第 7 页｜责任地图：申请人、ITSEF、认证机构与NCCA
08. 技术证据与SotA：认证评估真正审查什么
EUCC评估并非只对产品做一次黑盒测试。项目证据需要支持可复现、可审阅的结论，包括Security Target、设计与开发资料、构建和配置、评估样品、生命周期控制、漏洞管理和披露安排。
Common Criteria和Common Evaluation Methodology提供共同的评估语言与方法。State-of-the-Art（SotA）文件则对某些技术域或保护轮廓规定更具体的评价方法、技术和工具，以促进跨国评估一致性。[2] [4]
企业必须区分“final”SotA和“draft”资料。ENISA页面说明，draft文件可能已获相关意见支持并计划纳入未来修订，但不应被当作与已纳入实施法规或其修订的最终文件具有同等强制效力。
证据工程建议： 为每一项安全目标建立从风险与用途、到需求、设计、实现、测试、漏洞处置与变更记录的追溯链。这样既服务EUCC评估，也便于与CRA工程证据对接。 |
对应PPT第 8 页｜技术证据与SotA：认证评估真正审查什么
09. 证书生命周期：有效期、变更、暂停与撤回
EUCC证书有效期由认证机构结合产品特征设定，通常不得超过5年。超过5年需要满足法规规定的特别条件和相应国家认证机构程序。5年不是自动取得的固定期限，也不是在生命周期中不需要维护的保证期。[2]
当产品、环境、威胁或安全功能发生变化时，持证人可能需要通过保证连续性、复核或重新评估来保持认证结论的适用性。临近到期九个月内、产品发生相关变化或需要重新确认抵抗当前攻击能力时，均是重要的审查触发场景。
出现不符合项时，认证机构可以要求纠正；紧急或不合作情况下可以暂停证书；持续或重复违反义务可能导致撤回。暂停不等于撤回，但采购、宣传和市场声明都应以证书的实时状态为准。
商业控制点： 将证书编号、认证范围、产品版本、有效期、复核日期、暂停/撤回状态和公开链接纳入销售、投标及网站发布审批。 |
对应PPT第 9 页｜证书生命周期：有效期、变更、暂停与撤回
10. EUCC与CRA：如何衔接，哪些事项不能替代
CRA承认基于Regulation (EU) 2019/881建立的欧洲网络安全认证框架，并允许欧盟委员会在相关方案可用时，通过后续法律行为明确某一欧洲网络安全证书与CRA基本网络安全要求之间的合格推定关系。[5]
这意味着EUCC可能在一定产品类别、保证等级和证书覆盖要求下，为CRA合规评定提供价值，甚至在后续指定的相应范围内影响第三方评定要求。但这是一种条件性机制，而不是“已取得EUCC即自动满足CRA”的规则。
即使EUCC与某些CRA要求形成衔接，制造商仍应独立履行适用的CE标志、欧盟符合性声明、支持期、SBOM和漏洞处置、报告义务、技术文档、用户信息和市场监督合作义务。
需明确区分： EUCC证书的认证范围、CRA基本网络安全要求、委员会后续法律行为、以及制造商全生命周期义务，四者不能互相自动替代。 |
对应PPT第 10 页｜EUCC与CRA：如何衔接，哪些事项不能替代
11. 企业实施路线：90日决策与项目工作包
0至30日，企业应完成认证可行性筛选。输出包括产品与版本台账、目标欧盟市场、认证商业驱动、预期用途、风险画像和初步保证等级假设。这个阶段的目标是作出“是否继续投入”的管理决策，而不是承诺取证日期。
30至60日，产品、工程、法务、采购和商业团队应共同形成Security Target草案、SotA或保护轮廓定位、证据差距、供应商资料接口和预算/排期假设。此时应接洽具备相应范围的CB和ITSEF，验证其可承接性。
60至90日，企业可冻结拟认证边界，建立评估计划、证据索引、漏洞与变更治理工作流，并把EUCC项目与CRA、产品发布、供应链和客户沟通流程形成边界清晰的衔接。
管理闸门 |
需要回答的问题 |
认证对象 |
是哪个产品、版本、配置和运行环境？是否有稳定性与商业必要性？ |
目标等级 |
目标用途、攻击面与影响是否支持Substantial或High的选择？ |
认证能力 |
CB和ITSEF是否具备对应等级、技术域、认可和授权范围？ |
持续维护 |
变更、补丁、漏洞、到期与宣传状态如何纳入既有产品治理？ |
对应PPT第 11 页｜企业实施路线：90日决策与项目工作包
12. 法规依据、数据校验与使用边界
本报告优先使用EUR-Lex、欧盟委员会和ENISA公开资料。法规效力层级上，Regulation (EU) 2019/881、Commission Implementing Regulation (EU) 2024/482和Regulation (EU) 2024/2847是主要法律依据；委员会和ENISA页面用于解释实施、SotA、修订和操作入口。
逻辑校验已明确区分四项容易混淆的内容：EUCC的默认自愿性质与其他规则或采购可能提出的要求；EUCC的Substantial/High两档与通用认证框架三档；ITSEF技术评估与CB认证决定；EUCC与CRA的条件性衔接而非自动替代。
对具体产品的认证路径、适用SotA、保护轮廓、国家主管机构、认证机构/ITSEF范围以及CRA法律后果，仍须按当前有效文本和产品事实逐项复核。
使用边界： 本材料为客户认证解读与项目规划资料，不构成法律意见、认证结论或对某一产品的最终适用判定。 |
