很多企业听到欧洲客户说"产品要满足 CRA 认证"后，会下意识把 CRA 当成一张证书处理。但从欧盟法规体系看，CRA 更像是把网络安全正式嵌入产品市场准入体系的一部横向法规。它不是孤立存在的，而是会与 CE、RED、EUCC、NIS2、GDPR、AI Act、Data Act、DORA、GPSR 以及产品责任规则共同作用。
资深合规人员在解读 CRA 时，不能只问"做不做 CRA"，而要先问三个问题：产品是否属于 CRA 范围；CRA 与已有 CE/RED/行业法规是否重叠；客户要求的"CRA 认证"到底是自我符合性声明、公告机构评估，还是网络安全认证证据。
CRA 的法律定位：产品网络安全的横向准入规则
CRA，即 Regulation (EU) 2024/2847，标题中已经点明其定位：它规定的是"products with digital elements"的横向网络安全要求。这里的关键词是 horizontal cybersecurity requirements，也就是跨行业、跨产品类别的基础网络安全规则。
CRA 第 1 条规定了法案的核心内容，包括产品进入欧盟市场的规则、设计开发生产阶段的基本网络安全要求、制造商漏洞处理义务，以及市场监管和执法规则。
这说明 CRA 不是企业 IT 安全管理法，也不是单纯的数据保护法，而是产品法。它管的是投放欧盟市场的产品是否具备网络安全能力，以及制造商是否能在产品生命周期内持续处理漏洞。
CRA 第 6 条是理解整部法案的核心：产品只有在满足 Annex I Part I 的产品网络安全要求，并且制造商流程满足 Annex I Part II 的漏洞处理要求时，才能在欧盟市场提供。换句话说，CRA 同时管"产品本身"和"制造商流程"。
这也是很多企业低估 CRA 的地方。只做一次渗透测试，不能覆盖 Annex I Part II 的漏洞管理流程；只写一份合规声明，也不能替代 Annex I Part I 要求的安全设计、默认安全配置、安全更新能力和访问控制机制。
CRA 与 CE：CRA 不是 CE 之外的标签，而是 CE 技术文件中的网络安全部分
从欧盟新立法框架看，CRA 会纳入 CE 合规逻辑。产品如果属于 CRA 范围，制造商完成适用的符合性评估后，需要签署 EU Declaration of Conformity，并加贴 CE 标志。
因此，CRA 与 CE 的关系不是"CRA 证书 + CE 证书"的并列关系，而是：CE 是市场准入标志，CRA 是支撑 CE 声明的一项法规依据。
对企业来说，真正要做的是把 CRA 放入 CE 法规矩阵。例如一款联网智能家居设备，可能同时适用 RED、EMC、RoHS、LVD、CRA、GDPR、Data Act；一款工业联网设备，可能同时涉及 EMC、RoHS、Machinery Regulation、CRA、NIS2 客户供应链要求。
所以技术文档不能分裂成多套互相矛盾的材料。安全风险评估、产品说明、用户说明、安全更新机制、漏洞响应流程、SBOM、测试报告，应当成为 CE 技术文件体系的一部分，而不是临时给客户补一份"CRA 文件"。
CRA 与 RED：无线设备的网络安全要求存在过渡期衔接
RED，即 Radio Equipment Directive 2014/53/EU，适用于无线电设备。智能手表、蓝牙耳机、Wi-Fi 摄像头、蜂窝通信设备、智能家居网关、无线工业终端，通常首先会进入 RED 范围。
RED 的网络安全要求来自 Delegated Regulation (EU) 2022/30。该授权法规激活 RED 第 3(3)(d)、3(3)(e)、3(3)(f) 条，分别涉及网络保护、个人数据和隐私保护、防欺诈，并自 2025 年 8 月 1 日起适用于相关无线设备。
但 CRA 全面适用后，RED 网络安全要求与 CRA 会发生重叠。欧盟通过 Delegated Regulation (EU) 2026/339 明确，为避免重复监管，Delegated Regulation (EU) 2022/30 自 2027 年 12 月 11 日起废止。
这意味着企业需要按时间轴理解：
2025 年 8 月 1 日至 2027 年 12 月 10 日，相关无线设备仍需应对 RED 网络安全要求。
2026 年 9 月 11 日起，CRA 漏洞和严重安全事件报告义务开始适用。
2027 年 12 月 11 日起，CRA 主要义务全面适用，RED 网络安全授权法规被废止，产品网络安全要求主要由 CRA 承接。
实务中，无线产品企业不能简单说"等 CRA 到 2027 年再做"。如果产品在 2025-2027 年投放欧盟市场，RED 网络安全要求已经可能进入公告机构审查和客户准入清单。
CRA 与 EUCC：EUCC 是证据路径，不是 CRA 的全部答案
EUCC 是欧盟基于 Common Criteria 的网络安全认证方案，由 Implementing Regulation (EU) 2024/482 建立。它属于 Cybersecurity Act Regulation (EU) 2019/881 下的欧洲网络安全认证体系。
CRA 与 EUCC 的关系，需要看 CRA 第 27 条。第 27 条规定，符合已发布引用的协调标准，可以产生对相应 Annex I 要求的符合性推定；同时，若产品获得欧洲网络安全认证方案下的 EU statement of conformity 或 European cybersecurity certificate，并且该方案覆盖 CRA 对应要求，也可以对相应要求形成符合性推定。
因此，EUCC 的价值在于为产品安全能力提供强证据，尤其适用于防火墙、VPN、路由器、交换机、安全芯片、安全元件、数据库、操作系统等高安全属性产品。
但 EUCC 不能被简单理解为"做了就等于 CRA 全部合规"。EUCC 通常围绕特定产品边界、版本、安全目标、保护轮廓、评估保证级别展开；CRA 除了产品安全功能，还要求制造商具备漏洞处理、安全更新、技术文档、用户说明、支持期、市场监管配合等全生命周期能力。
更准确的判断是：EUCC 可以成为 CRA 证据链中的高级证明材料，但不能替代 CRA 项目本身。
CRA 与 NIS2：产品义务与客户供应链义务会叠加
NIS2 Directive (EU) 2022/2555 管的是欧盟关键和重要实体的网络安全治理，例如能源、交通、金融、医疗、数字基础设施、公共管理、制造、数字服务等行业。它强调网络安全风险管理、事件报告、供应链安全和管理层责任。
CRA 管产品，NIS2 管组织。这是二者最本质的区别。
但出口企业在业务上会感受到二者叠加。因为欧洲客户如果自身受 NIS2 约束，就会把供应链安全压力传导给设备和软件供应商。于是中国企业虽然未必直接是 NIS2 义务主体，却会在招投标或供应商审核中被要求提交 CRA 合规声明、漏洞响应流程、安全更新承诺、SBOM、渗透测试报告、产品生命周期支持说明。
所以，CRA 是供应商向 NIS2 客户证明产品安全能力的重要材料来源。对于面向能源、交通、金融、医疗、制造行业的产品，CRA 合规准备应当直接服务于客户的 NIS2 供应链审核。
CRA 与 GDPR：网络安全与个人数据保护不是同一个合规问题
GDPR 管个人数据处理，CRA 管产品网络安全。二者在智能穿戴、智能家居、摄像头、App、儿童设备、健康监测设备中高度交叉。
以智能手表为例：
CRA 关注固件漏洞、蓝牙通信、OTA 更新、默认密码、访问控制、日志审计、安全更新和漏洞报告。
GDPR 关注健康数据、定位数据、账号数据、儿童数据、隐私告知、合法性基础、用户权利、跨境传输和数据处理安全。
一个产品即使满足 CRA，也不代表个人数据处理合法；一个产品即使隐私政策写得完整，也不代表固件、接口和更新机制满足 CRA。
实务上，应将 GDPR 的 privacy by design 与 CRA 的 security by design 并行评估。特别是摄像头、可穿戴设备、智能家居网关这类产品，数据最小化、加密传输、访问控制、日志留存、账号注销和安全更新机制往往需要统一设计。
CRA 与 AI Act：CRA 可覆盖网络安全要求，但不覆盖 AI 全部义务
AI Act Regulation (EU) 2024/1689 管 AI 系统风险。其核心不是一般网络安全，而是 AI 系统的风险分类、禁止性实践、高风险 AI 要求、透明度义务、数据治理、人类监督、准确性、鲁棒性等。
CRA 第 12 条专门处理高风险 AI 系统与 CRA 的衔接。其逻辑是：如果一个带有数字元素的产品同时属于 CRA 范围，并根据 AI Act 第 6 条被认定为高风险 AI 系统，在满足 CRA Annex I 产品网络安全要求和制造商漏洞处理流程，并在 CRA 的 EU Declaration of Conformity 中证明达到 AI Act 第 15 条所需网络安全保护水平时，可以视为满足 AI Act 第 15 条中的网络安全要求。
这条规则的意义是避免重复证明同一网络安全要求。但它不是说 CRA 覆盖 AI Act。
例如 AI 摄像头、AI 门禁、工业 AI 质检设备，如果构成高风险 AI，仍需满足 AI Act 关于数据治理、技术文档、透明度、人类监督、准确性、鲁棒性和质量管理体系的要求。CRA 只是在网络安全维度上与 AI Act 形成衔接。
CRA 与 Data Act：数据可访问要求必须与接口安全一起设计
Data Act Regulation (EU) 2023/2854 关注联网产品和相关服务产生的数据访问、使用和共享。对工业设备、智能家居、智能计量、车联网周边设备等产品，Data Act 可能要求用户能够访问产品生成的数据，并在一定条件下将数据提供给第三方。
这与 CRA 存在天然张力：Data Act 鼓励数据可访问，CRA 要求接口和产品安全。
企业不能只为了满足 Data Act 开放 API、导出接口或远程访问能力，却没有同步设计身份认证、授权控制、访问日志、速率限制、加密传输、密钥管理和漏洞响应机制。否则，数据访问接口本身可能成为 CRA 风险评估中的高风险攻击面。
正确的合规做法是把 Data Act 的数据访问设计放入 CRA 威胁建模中，判断数据接口是否扩大攻击面，以及是否需要额外的访问控制、安全日志和异常检测。
CRA 与 DORA：金融客户的 ICT 风险要求会要求更强证据
DORA Regulation (EU) 2022/2554 自 2025 年 1 月 17 日起适用于欧盟金融实体，重点是 ICT 风险管理、重大 ICT 事件报告、数字运营韧性测试、ICT 第三方风险管理和关键 ICT 第三方服务提供商监管。
如果企业向欧洲银行、保险、支付机构、证券机构提供软件、云服务、网络安全设备、身份认证系统、数据库或运维平台，客户会把 DORA 第三方风险管理要求传导给供应商。
CRA 可以证明产品安全；DORA 会进一步追问服务连续性、事件响应、外包管理、分包链、合同退出、数据位置和运营韧性。也就是说，面向金融客户时，CRA 是必要的产品证据，但通常不是充分的供应商证据。
CRA 与 GPSR、产品责任指令：网络安全缺陷会变成市场监管和赔偿风险
CRA 第 11 条处理与 General Product Safety Regulation (EU) 2023/988 的关系。对于带有数字元素的消费品，如果某些风险不被 CRA 或其他欧盟协调法规覆盖，GPSR 仍可能介入。
Product Liability Directive (EU) 2024/2853 则把产品责任规则更新到数字时代。软件、AI 系统、数字服务以及缺少必要安全更新导致的安全缺陷，都可能进入产品责任讨论。
这意味着 CRA 合规不是"上市前交材料"就结束。产品如果上市后没有及时修复漏洞、没有提供安全更新、没有合理披露风险，未来可能面对市场监管、召回、经销商追责、消费者索赔和产品责任争议。
合规专家的实务结论
从法案解读角度看，CRA 的核心不是"多一个认证"，而是把数字产品的网络安全责任嵌入欧盟产品准入、供应链审查和上市后监管体系。
企业应按以下逻辑建立合规框架：
先识别产品边界：硬件、固件、软件、App、云端远程数据处理、第三方组件是否属于同一产品体系。
再判断法规适用：CRA、RED、CE、GDPR、AI Act、Data Act、DORA、GPSR、行业法规分别管什么风险。
再判断 CRA 分类：普通产品、Annex III 重要产品 Class I/Class II、Annex IV 关键产品，分类决定 Article 32 下的符合性评估路径。
再做 Annex I 映射：Part I 是产品安全属性，Part II 是漏洞处理流程，二者都必须有证据。
最后形成统一技术文件：风险评估、威胁建模、SBOM、漏洞披露政策、安全更新机制、测试整改记录、用户说明、EU DoC、CE 技术文件和客户投标答复材料应当能够互相支撑。
真正成熟的 CRA 合规，不是拿一份文件回答客户，而是形成一条经得起公告机构、进口商、经销商、市场监管机构和大客户供应链审核追问的产品安全证据链。
参考来源：Regulation (EU) 2024/2847 Cyber Resilience Act、欧盟委员会 CRA 法规摘要、欧盟委员会 CRA 报告义务说明、ENISA Single Reporting Platform、Delegated Regulation (EU) 2026/339、Implementing Regulation (EU) 2024/482 EUCC。