欧盟网络安全法案（CRA）
法规解读与企业合规指引
Regulation (EU) 2024/2847 | Cyber Resilience Act
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
法规与实施状态核验基准：2026 年 9 月 8 日
适用对象：产品管理、安全工程、合规、法务、供应链与高层管理团队
使用说明 本文以 Regulation (EU) 2024/2847 及 EUR-Lex 已公布的相关授权/实施法案为硬法依据，并以欧盟委员会和 ENISA 官方资料核验实施状态。内容用于企业合规决策支持，不构成面向具体事实的法律意见。 |
图 1 CRA 专业解读封面视觉
执行摘要
《网络韧性法案》（Cyber Resilience Act，简称 CRA）以条例形式统一规范欧盟市场上的“带数字元素产品”。它将产品网络安全从单次上市审查，延伸至设计、开发、供应链、漏洞处理、更新支持、符合性评定与市场监督的完整生命周期。对制造商而言，CRA 的合规核心不是取得一次性证书，而是建立一条可被监管机关追溯的产品安全与证据链。
本资料的最重要时间结论是：CRA 虽于 2024 年 12 月 10 日生效，但其一般适用日为 2027 年 12 月 11 日；同时，第 14 条有关主动被利用漏洞与严重事件的强制报告义务提前于 2026 年 9 月 11 日适用。因此，在本报告的核验基准日 2026 年 9 月 8 日，企业应将报告能力建设视为紧急事项，而不能等待全面适用日。
管理层应立即确认的事项 |
法规后果 |
哪些产品在 CRA 范围内？ |
对每一产品判断数据连接、远程数据处理与法定排除项，并留存产品级范围记录。 |
谁承担制造商责任？ |
开发、委托开发或以自身名称/商标提供产品的主体通常为制造商；重新定牌或实质性修改也可能触发制造商责任。 |
第 14 条是否已准备？ |
从 2026.09.11 起，针对主动被利用漏洞及严重事件建立 SRP 报告、时限管理和用户通知流程。 |
是否需要第三方评定？ |
先以附件 III/IV 和 2025/2392 的技术描述确定核心功能类别，再选择模块 A、B+C、H 或适用认证路径。 |
证据是否完整？ |
风险评估、SBOM、CVD、测试、支持期依据、更新分发及 EU 符合性声明应能在技术文档中闭环。 |
图 2 分阶段适用时间轴与基准日提示
1. 适用范围：先做产品级法律测试，再谈技术合规
CRA 适用于在欧盟市场提供的带数字元素产品，只要其预定用途或合理可预见用途包含与设备或网络的直接或间接、逻辑或物理数据连接。[1] 第 2(1) 条将这一连接性作为范围关键条件。“带数字元素产品”包括软件或硬件产品及其远程数据处理方案，也包括单独投放市场的软件或硬件组件。[1] 第 3(1) 条。
远程数据处理不能被简单理解为任何云服务。法规要求该处理由制造商或在其责任下设计开发，并且如果没有该远程处理，产品将无法执行其一项功能。[1] 第 3(2) 条。企业应以产品功能、责任归属、运行依赖和市场投放方式为维度形成书面范围结论。
范围判断对象 |
关键问题 |
处理提示 |
连接性 |
是否存在设备/网络的直接或间接、逻辑或物理数据连接？ |
分析预定用途与合理可预见用途，而非仅分析宣传功能。 |
远程处理 |
是否由制造商负责，且缺失会妨碍某项产品功能？ |
将架构图、服务责任及降级行为纳入范围档案。 |
明文排除 |
是否属于医疗、IVD、机动车、航空、船用设备、特定备件、国防/国家安全或机密信息专用产品？ |
排除判断应对应 CRA 第 2 条的具体款项；还应核验其他部门立法的等效覆盖。 |
开源软件 |
是否在商业活动中提供？是否属于开源软件管理者？ |
未商业化 FOSS 并非当然受规制；商业提供时仍可能进入 CRA。 |
存量产品 |
是否在 2027.12.11 后发生实质性修改？ |
一般全面义务以实质性修改为触发，但第 14 条报告存在特别规则。 |
实践判断 范围结论应在每次产品投放、重大版本发布、远程服务责任变化和并购/贴牌安排变化时复核。单纯依赖产品名称、部署形态或“云服务”标签，难以支持稳健的 CRA 适用性结论。 |
图 3 CRA 产品级范围判断框架
2. 附件 I 与制造商义务：将网络安全嵌入产品全生命周期
CRA 第 6 条要求产品满足附件 I 第一部分的产品网络安全要求，且制造商须满足附件 I 第二部分的漏洞处理要求。第 13 条将该要求落实为制造商在规划、设计、开发、生产、交付和维护阶段持续执行并记录网络安全风险评估的责任。风险评估并不是上市前一次性文档，而应在支持期内适当更新。[1] 第 13(1)–(3) 条。
控制域 |
法规基线 |
建议形成的审计证据 |
安全设计 |
产品应以适当安全水平上市，并实现安全默认配置、最小攻击面、访问控制及保密性、完整性、可用性保护。 |
威胁建模、架构评审、默认配置清单、访问控制测试和安全日志设计。 |
第三方组件 |
对第三方组件（包括非商业开源组件）开展与风险相称的尽职调查；发现集成组件漏洞应采取报告与修复措施。 |
依赖准入标准、漏洞处置单、组件维护方沟通记录、补丁决策。 |
SBOM |
以通用、机器可读格式识别和记录组件，至少覆盖顶层依赖。法规并未要求向公众公开 SBOM。 |
版本化 SBOM、构建来源、组件与漏洞映射、访问控制与留存策略。 |
漏洞处理 |
建立协调漏洞披露政策、漏洞报告联系地址、修复和安全更新机制；安全更新应不无当延误地提供。 |
PSIRT 流程、CVD 政策、CVE/告警记录、补丁测试与发布证据。 |
支持期 |
通常不少于 5 年；若预期使用期短于 5 年，则可按较短使用期确定。安全更新须至少保留 10 年或支持期余期，以较长者为准。 |
支持期判断备忘录、用户告知页面、更新可得性与归档记录。 |
技术文档至少应满足附件 VII，并持续更新。其内容包括产品描述、系统架构、漏洞处理流程、SBOM、协调漏洞披露政策、漏洞报告地址、安全更新分发安排、风险评估、支持期依据、采用的标准或其他技术规范以及测试报告。[1] 附件 VII。这意味着“代码安全”与“可证明的安全治理”同样重要。
图 4 附件 I 工程控制与漏洞治理基线
3. 经济运营者：制造商居中，供应链共同承担信息与处置责任
制造商承担最广泛的实质义务，包括设计与开发符合性、风险评估、技术文档、符合性评定、EU 符合性声明、CE 标志、支持期内漏洞处理及第 14 条强制报告。授权代表可以在书面授权范围内保存文档、提供监管资料并协作，但不得承接第 13 条规定的核心制造商义务。[1] 第 18 条。
进口商和分销商并非“被动物流角色”。进口商在投放前需核验适用评定、技术文档、CE、EU 声明及用户资料；分销商须以合理注意义务核验 CE 与识别信息。二者在知悉漏洞时均应无不当延误地告知制造商，在产品存在重大网络安全风险时还须通知相关监管机关。[1] 第 19–20 条。
角色 |
主要合规动作 |
高风险误区 |
制造商 |
建立全生命周期安全控制、合格评定和报告机制。 |
以授权代表、外包开发商或商业证书替代自身法定责任。 |
授权代表 |
保存/提供文件，支持市场监督协作。 |
授权书含糊，或误以为可承接制造商核心工程与报告义务。 |
进口商 |
入境投放前核验产品与制造商文件，并保留 EU 声明。 |
未核验产品版本、语言资料及追溯信息即投放市场。 |
分销商 |
提供市场前尽合理注意义务；发现问题时停止提供并协助纠正。 |
将 CE 标志当作唯一检查点，忽略已知漏洞和不合规迹象。 |
图 5 经营者职责分工与制造商责任中心
4. 分类与合格评定：以核心功能及法律状态选择证据路径
附件 III 将重要产品分为 I 类和 II 类；附件 IV 列出关键产品。判定重点是产品的核心功能，而不是营销名称，也不能因为某个重要产品被作为组件集成到另一产品中，就自动推定后者进入更严格类别。[1] 第 7 条。Commission Implementing Regulation (EU) 2025/2392 已为附件 III 与附件 IV 的现行类别提供技术描述，企业应以该文件完成具体映射。[2] 第 2 条及附件。
产品组别 |
CRA 路径 |
管理含义 |
普通产品 |
可采用内部控制（模块 A）。 |
可以自评，但不免除附件 I、技术文档、EU 声明与 CE 的全部责任。 |
重要产品 I 类 |
未完整采用适用协调标准、共同规范或相应认证方案时，适用模块 B+C 或模块 H。 |
须逐项核验标准/认证是否可用、适用且覆盖相关要求。 |
重要产品 II 类 |
适用模块 B+C、模块 H，或在可用且适用时适用至少“实质”保障等级的指定认证方案。 |
提前规划公告机构范围、产品版本冻结和测试证据。 |
关键产品 |
原则上依第 8(1) 条所定认证方案；条件未满足时，按 II 类路径处理。 |
不得假定任意 EU 认证都已自动满足 CRA，也不得预设所有关键产品的指定认证命令已生效。 |
法规状态提示 协调标准的符合性推定，取决于相关标准或其部分的引用已刊登于《欧盟官方公报》且覆盖对应附件 I 要求。[1] 第 27(1) 条。委员会标准化请求 M/606 本身不是协调标准。共同规范与认证方案也须满足条例的条件并经相应法律文件确认。 |
图 6 普通、重要与关键产品的合格评定路径
5. 第 14 条报告义务：2026 年 9 月 11 日起应建立可运行的 SRP 流程
自 2026 年 9 月 11 日起，制造商知悉其产品含有“主动被利用漏洞”时，须通过 Single Reporting Platform（SRP）同时向相关协调 CSIRT 和 ENISA 报告。所谓“主动被利用漏洞”，需要有可靠证据显示恶意行为者已在未经系统所有者许可的系统中利用该漏洞；它不同于一般可被利用但尚无恶意利用证据的漏洞。[1] 第 3(42)、14(1) 条。
触发事项 |
24 小时 |
72 小时 |
最终报告 |
主动被利用漏洞 |
早期预警；不得无不当延误。 |
漏洞通知。 |
纠正或缓解措施可用后最迟 14 日。 |
影响产品安全的严重事件 |
早期预警；不得无不当延误。 |
事件通知。 |
提交事件通知后 1 个月内。 |
报告端点原则上按照制造商在欧盟的主要营业地确定；ENISA 能够同时访问相关信息。[1] 第 14(7)、16 条。制造商知悉主动被利用漏洞或严重事件后，还须通知受影响用户；在适当情况下，应通知所有用户及可采取的缓解或纠正措施。[1] 第 14(8) 条。已有存量产品不应被简单排除：第 69(3) 条明确将第 14 条义务延伸至 2027 年 12 月 11 日之前已投放市场、但仍在 CRA 范围内的产品。
72 小时不是“分析完成期限” 企业应以“获悉时间”为起点建立固定时钟和决策记录。对是否达到“主动被利用”或“严重事件”门槛的判断、已知影响、可用缓解措施、SRP 提交证据和用户通知均应可回溯。 |
图 7 主动被利用漏洞与严重事件的法定报告时限
6. 市场监督、纠正措施与处罚：合规文件必须能在监管时被快速调取
CRA 将 Regulation (EU) 2019/1020 的市场监督框架适用于其范围内产品。成员国市场监督机关可在有理由的请求下获取评估产品设计、开发、生产与漏洞处理所需的数据及相关内部文件。[1] 第 52–53 条。这直接要求企业将安全和合规证据组织成可导出、可解释、可按产品版本定位的档案。
如监管机关认为产品存在重大网络安全风险或发现不符合，相关经济运营者可能被要求在风险相称期限内使产品合规、撤出市场或召回。未充分纠正时，成员国可限制或禁止提供、撤市或召回；跨境影响还可触发欧盟层面的保障程序。[1] 第 54–58 条。
违规类型 |
CRA 最高行政罚框架 |
适用说明 |
违反附件 I 或第 13、14 条义务 |
€15,000,000 或上一财年全球年营业额 2.5%，取较高者。 |
对应基本网络安全、制造商义务及报告义务。 |
违反第 64(3) 条列举义务 |
€10,000,000 或全球年营业额 2%，取较高者。 |
包括部分运营者、评定和文档等相关义务。 |
对公告机构或监管请求提供错误、不完整或误导信息 |
€5,000,000 或全球年营业额 1%，取较高者。 |
记录管理与监管沟通必须受控。 |
第 64 条设定的是成员国须落实的最高档框架，而非在每一成员国自动适用的单一罚款决定。实际处罚程序、主管机关与国内实施规则需按目标市场进一步核验。第 64 条随 CRA 一般适用日进入普遍适用。[1] 第 64、71 条。
图 8 市场监督措施与三档处罚上限
7. 建议的企业行动路线图
建议将 CRA 项目按“紧急报告能力—产品与证据台账—上市合规闭环”三层推进。这样既能处理 2026 年 9 月的迫切报告义务，也能在 2027 年一般适用日前形成可持续运行的产品安全治理。
时间窗口 |
关键交付物 |
责任团队 |
立即至 2026.09.11 |
确定制造商实体与欧盟主要营业地；建立 SRP 上报 RACI、24/72 小时计时、升级阈值、用户通知模板和桌面演练。 |
PSIRT / SOC / 产品安全 / 法务 / 欧盟实体。 |
2026 Q4—2027 H1 |
建立产品—角色—市场—类别台账；落实 SBOM、风险评估、CVD、更新及技术文档；动态映射附件 III/IV。 |
产品管理 / 研发 / AppSec / GRC / 供应链。 |
2027 H2—2027.12.11 |
完成适用评定、EU 声明和 CE 流程；对需第三方路径产品确认公告机构范围与供给；建立实质性修改审查门。 |
质量 / 合规 / 法务 / 采购 / 发布管理。 |
项目治理建议 以版本化“合规证据包”作为每个产品发布门禁。该证据包应能够把范围判断、类别映射、风险评估、SBOM、测试报告、支持期、更新策略、CVD、符合性评定、EU 声明与 CE 关联到一个可审计的产品版本。 |
图 9 从报告就绪到全面适用的企业路线图
8. 实施状态与法律使用边界
CRA 的母法规与已经在 EUR-Lex 公布并生效的授权/实施法案，可作为本报告的硬法依据。例如，2025/2392 已对重要/关键产品类别的技术描述作出细化；2026/881 已对协调 CSIRT 因网络安全理由延迟传播通知的条件作出规定。[2] [3] 但企业不应将法规中的授权、项目计划或非约束性指南误读为已经完全生效的统一操作细则。
事项 |
本报告的稳健表述 |
企业应采取的动作 |
协调标准 |
只有 OJ 已刊登引用、并覆盖相关要求的标准，才产生相应符合性推定。 |
逐项核对 OJ 引用、产品适用性与覆盖范围；M/606 不是标准本身。 |
共同规范 |
仅在第 27(2) 条条件满足并通过实施法案制定时可以作为路径。 |
不得预设“没有标准即可自动使用共同规范”。 |
SBOM 与报告格式 |
CRA 已明确底线，但格式/要素与报告程序可以被后续实施法案细化。 |
建立可变配置的运营流程，并临近使用时复核官方更新。 |
EU 认证与关键产品 |
适用范围取决于可用认证方案以及后续指定法案。 |
勿把一般商业证书或未获指定的认证自动等同于 CRA 合规。 |
委员会指南 / ENISA 指引 |
可用于理解和实施；委员会 2026 指引明确为非约束性。 |
作为受控解释源，但冲突时以法规与 OJ 文件为准。 |
图 10 硬法、实施文件与指南的使用边界
结语：以“可证明的产品安全”应对 CRA
CRA 的监管逻辑可以概括为：产品必须以安全方式设计和维护，制造商必须在支持期内处理漏洞，欧盟市场上的经济运营者必须能够证明合规，并且在特定漏洞或事件发生时必须及时上报。企业的最佳准备方式是将法规要求纳入产品治理机制，而不是在临近上市时补做一套静态文档。
鉴于第 14 条的提前适用，建议本报告使用者优先完成报告流程和责任人验证，然后以产品台账驱动附件 I 控制、附件 VII 技术文档和适用的评定路径。对于存在分类、排除、远程数据处理或实质性修改疑问的具体产品，应根据最新官方文件并结合事实，取得专项法律意见。
图 11 官方依据与复核提示
