欧盟《网络弹性法案》
CRA 合规中心
从"我的产品是否受 CRA 约束"，到"应该属于哪一类、需要做什么评估、如何建立 SBOM 与漏洞管理体系"，用一套完整的合规知识体系帮助企业从法规理解走向可执行落地。
法规依据：Regulation (EU) 2024/2847（Cyber Resilience Act）。本页面用于合规准备与技术参考，不构成法律意见或特定产品的最终适用性判断。
CRA 实施时间线
CRA 是什么？为什么企业现在就要准备？
欧盟《网络弹性法案》（Cyber Resilience Act，CRA）是针对"含数字元素产品"的横向网络安全法规。它把网络安全责任从传统的"上市前测试"扩展到产品设计、开发、生产、交付、维护和上市后漏洞处理的完整生命周期。
横向产品网络安全法规
CRA建立适用于硬件和软件产品的统一网络安全要求，覆盖最终产品以及单独投放市场的数字组件。
设计即安全
制造商要在设计、开发和生产阶段考虑网络安全，并确保产品在合理可预见的使用条件下满足基本网络安全要求。
上市不是合规终点
制造商需要在支持期内有效处理产品及其组件漏洞，并提供必要的安全更新和相关用户信息。
哪些产品属于 CRA？先判断"是否适用"
CRA的核心概念是"Products with Digital Elements（含数字元素的产品）"。判断不能只看"是不是软件"，而应看产品的预期用途或合理可预见用途是否包含与设备或网络的直接或间接逻辑或物理数据连接。
典型适用产品
- 操作系统、浏览器、应用软件、开发工具等软件产品
- 联网消费电子、智能家居、可穿戴设备
- 路由器、交换机、调制解调器、网络接口
- IoT设备、工业控制及嵌入式设备
- 安全软件、VPN、SIEM、身份管理、密码管理器
- 具有数字元素并单独投放欧盟市场的软件/硬件组件
判断时不能忽略的边界
- 产品是否"在欧盟市场提供"是重要前提。
- 不能仅凭产品名称判断，需要分析核心功能和预期用途。
- 已经受特定欧盟法规约束的部分产品可能被排除、限制适用或需要与CRA协调。
- 医疗器械、体外诊断医疗器械、机动车辆及航空相关特定产品存在明确的法规交叉/排除规则。
- 远程数据处理解决方案、开源软件等特殊场景需要单独分析。
CRA 与其他欧盟法规如何衔接？
CRA本身就是欧盟产品法规体系的一部分。企业不能只做单一法规判断，而应建立产品级的法规适用矩阵。
| 法规/框架 | 重点关注 | 与CRA的关系 | 企业建议 |
|---|---|---|---|
| RED 2014/53/EU | 无线电设备安全、频谱、相关网络安全要求 | 部分无线产品存在法规交叉 | 建立产品级法规适用矩阵，避免重复评估 |
| NIS2 | 关键/重要实体的网络安全风险管理 | 主要管"实体"，CRA主要管"产品" | 企业可能同时受到NIS2与CRA影响 |
| EU Cybersecurity Act / EUCC | 网络安全认证框架 | 特定认证方案可影响CRA符合性评估 | 关注欧盟网络安全认证方案与CRA的衔接 |
| 医疗器械法规 MDR / IVDR | 医疗器械安全和合规 | CRA对部分医疗产品有明确排除规则 | 先确认是否落入MDR/IVDR及CRA排除条款 |
| 机动车型式法规 | 车辆及其系统 | CRA Article 2规定特定排除 | 汽车产品应结合车辆网络安全法规体系判断 |
产品分类决定合规评估路径
CRA将产品分为Default Category、Important Products（Class I / Class II）以及Critical Products等不同监管类别。分类的关键不是"企业自己选择"，而是根据法规附件及产品核心功能判断。
普通产品
不属于Annex III或Annex IV特定类别的产品。大量一般软件、智能设备和消费类数字产品可能落入这一范围。
- 一般应用软件
- 智能硬件
- 普通联网设备
- 部分消费电子产品
重要产品 Class I
Annex III列出的第一类重要产品。包括身份与访问管理、浏览器、密码管理器、恶意软件防护、VPN、网络管理、SIEM等。
- 身份管理/PAM
- 浏览器
- 密码管理器
- VPN
- SIEM
- 操作系统、路由器、交换机等
重要产品 Class II
Annex III中的第二类产品，通常涉及更高的网络安全风险。
- Hypervisor
- Container Runtime
- 防火墙
- 入侵检测/防御系统
- 抗篡改微处理器
- 抗篡改微控制器
关键产品
Annex IV规定的关键产品类别具有更高的网络安全关键性，需要关注更严格的符合性评估及适用的欧盟网络安全认证机制。
- 以法规Annex IV为准
- 关注EUCC等相关认证方案
- 关注具体实施/授权规则
Annex III：重要产品分类清单
以下按照法规现行文本整理。正式项目判断应以欧盟官方现行合并文本及后续授权/实施法规为准。
| 类别 | 法规中的典型产品 | 典型中文理解 |
|---|---|---|
| Class I | Identity management systems / PAM | 身份管理、特权访问管理、认证和访问控制设备 |
| Class I | Standalone and embedded browsers | 独立浏览器、嵌入式浏览器 |
| Class I | Password managers | 密码管理器 |
| Class I | Malware search/removal/quarantine software | 恶意软件检测、清除、隔离软件 |
| Class I | VPN products | 虚拟专用网络产品 |
| Class I | Network management systems / SIEM | 网络管理系统、SIEM |
| Class I | Boot managers / PKI / certificate issuance | 启动管理器、PKI、公钥及数字证书签发软件 |
| Class I | Network interfaces / operating systems | 物理/虚拟网络接口、操作系统 |
| Class I | Routers / modems / switches | 互联网连接路由器、调制解调器、交换机 |
| Class I | Security-related microprocessors / microcontrollers / ASIC / FPGA | 具有安全相关功能的处理器、控制器、ASIC、FPGA |
| Class I | Smart home assistants / security products | 智能家居通用语音助手、智能门锁、摄像头、婴儿监护、报警系统等 |
| Class I | Connected toys / certain wearables | 具有社交交互/定位能力的联网玩具；特定健康监测或儿童可穿戴产品 |
| Class II | Hypervisors / container runtime | 虚拟化执行操作系统及类似环境的Hypervisor、容器运行时 |
| Class II | Firewalls / IDS / IPS | 防火墙、入侵检测与入侵防御系统 |
| Class II | Tamper-resistant microprocessors / microcontrollers | 抗篡改微处理器、微控制器 |
CRA核心：Annex I基本网络安全要求
Annex I是产品制造商最需要落地的核心要求之一，分为产品本身要求（Part I）和漏洞处理流程要求（Part II）。
产品应具备的网络安全属性
- 产品应按照适当的网络安全水平进行设计、开发和生产。
- 基于风险进行安全配置，减少可被利用的攻击面。
- 产品应避免已知可被利用的漏洞，适当情况下应采取安全更新机制。
- 产品应保护数据的机密性、完整性、可用性以及相关功能。
- 产品应限制对数据、功能和资源的未授权访问。
- 产品应在合理可行范围内避免对其他设备或网络造成不利影响。
- 产品应允许安全地删除或重置相关数据。
制造商必须建立的漏洞处理流程
- 识别并记录产品及其组件的漏洞。
- 对漏洞进行定期测试和评估。
- 及时处理和修复漏洞。
- 建立协调漏洞披露（CVD）政策及漏洞报告接收点。
- 确保安全更新能够及时、免费提供，并在适用情况下自动安装。
- 在支持期内持续监控漏洞。
- 对已修复漏洞提供安全信息和更新说明。
用户信息与技术文档：合规证据必须可追溯
CRA要求制造商提供清晰的用户信息，并建立技术文档证明产品符合适用的基本网络安全要求。
用户信息至少应覆盖
- 制造商名称、注册商号/商标及联系方式
- 漏洞报告单一联系点及协调漏洞披露政策
- 产品名称、类型及唯一识别信息
- 预期用途、基本功能和安全属性
- 可能导致重大网络安全风险的已知或可预见情况
- EU Declaration of Conformity的访问地址（适用时）
- 安全技术支持类型及安全支持结束日期
- 安全安装、运行、更新、数据删除和安全退役说明
- 如制造商提供SBOM，应说明获取SBOM的方式
技术文档建议形成证据链
- 产品总体描述、预期用途和版本信息
- 产品架构、设计与开发过程
- 适用的网络安全风险评估
- 已识别的漏洞及其处理过程
- SBOM及软件组件/依赖信息
- 测试、验证和安全更新记录
- 符合性评估所依据的标准或其他技术规范
- 相关声明、证书和评估结果
SBOM：CRA产品合规的基础数据层
软件供应链越来越复杂。对于一个现代数字产品，企业需要知道"产品里到底有什么"，才能判断新漏洞是否真正影响产品。
SBOM组件资产
记录组件名称、版本、供应商、依赖关系及组件来源，建立产品级软件资产清单。
二进制固件分析
针对嵌入式设备和固件，在无法完整获得源代码的情况下，从二进制中识别组件、版本和潜在依赖。
漏洞影响分析
将CVE、组件和具体产品版本建立映射，减少"扫描到漏洞≠产品一定受影响"的误判。
漏洞管理：从发现到修复，再到报告
CRA要求制造商在产品支持期内有效处理漏洞。2026年9月11日起，主动被利用漏洞和影响产品安全的严重事件还将触发强制报告义务。
发现
持续识别产品软件组成、公开漏洞和供应链风险。
影响分析
确认漏洞对应组件、受影响版本、产品实际是否包含该组件及可利用条件。
风险评估
结合产品功能、暴露面、可利用性、影响范围和业务场景确定优先级。
修复与缓解
跟踪补丁、升级、配置变更、临时缓解措施和验证结果。
协调漏洞披露
建立漏洞接收渠道、CVD政策、内部响应流程和责任人。
持续监控
产品版本、组件版本、漏洞情报变化后重新评估产品风险。
CRA漏洞与严重事件报告机制
报告义务通过CRA Single Reporting Platform（SRP）执行，由ENISA负责建立和维护。企业应提前建立内部识别、研判、审批和报告流程。
发现主动利用/严重事件
从制造商知悉相关漏洞或事件开始计算。
早期预警
提交早期预警，满足CRA规定的初始通知要求。
主要通知
提交主要通知，包括一般信息和初步评估。
最终报告
漏洞：纠正措施可用后14天内；严重事件：72小时通知后1个月内。
符合性评估怎么选？不是所有产品都一样
CRA根据产品类别规定不同符合性评估路径。对于Default Category，法规允许在满足条件时采用内部生产控制；Important和Critical产品需要根据法规要求采用相应的更严格程序。
| 产品类别 | 主要判断 | 符合性评估关注 | 企业行动 |
|---|---|---|---|
| Default Category | 不属于Annex III/IV特定类别 | 可适用内部生产控制（需满足法规条件） | 建立产品安全要求、风险评估、技术文档和符合性声明 |
| Important Class I | Annex III Class I | Article 32对应的评估程序；取决于适用标准/技术规范等条件 | 确认是否有适用协调标准、是否需要第三方评估 |
| Important Class II | Annex III Class II | 更严格的符合性评估要求 | 提前与符合性评估机构沟通并准备技术证据 |
| Critical | Annex IV及相关规定 | 关注适用欧盟网络安全认证方案及法规规定的评估路径 | 结合具体产品类别和实施规则确定路径 |
企业真正落地 CRA 的 12 步合规路径
把法规语言转换成产品经理、研发、安全、质量和合规团队可以执行的工作流。
建立产品清单
识别所有面向欧盟市场的软件、固件、硬件和数字组件。
判断CRA适用性
确认数字元素、数据连接、欧盟市场和法规排除/交叉情况。
确定产品类别
依据核心功能及Annex III/IV判断Default、Class I、Class II或Critical。
建立要求矩阵
将Annex I、II及相关条款映射到产品和组织控制措施。
产品网络安全风险评估
建立威胁模型、攻击面、风险场景和安全控制。
建立软件供应链资产
识别组件、版本、依赖关系和第三方软件。
建立漏洞管理
发现、分析、评级、修复、验证并记录漏洞处理过程。
嵌入安全开发流程
把安全要求、测试、代码分析和供应链管理纳入研发流程。
建立技术文档
形成产品设计、风险、测试、漏洞和更新等证据链。
完成符合性评估
按照产品类别选择适用评估程序及必要的第三方机构。
声明与市场投放
完成EU Declaration of Conformity、CE等适用市场准入步骤。
持续合规
上市后持续处理漏洞、提供安全更新并维护合规证据。
CRA 合规资料清单
建议以"产品"为核心建立一套可审计、可追踪、可持续更新的合规资料包。
| 资料域 | 典型内容 | 对应目的 | ONEKEY可支撑的数据基础 |
|---|---|---|---|
| 产品身份 | 名称、型号、版本、供应商、市场、预期用途 | 确定产品边界 | 产品资产 |
| 架构 | 硬件、软件、网络接口、数据流、依赖 | 理解攻击面 | 软件组成/关联 |
| SBOM | 组件、版本、依赖、供应商、许可证 | 软件透明度 | SBOM管理 |
| 漏洞 | CVE、严重度、可利用性、影响版本 | 风险识别 | 漏洞关联与分析 |
| 风险评估 | 威胁、攻击面、风险场景、缓解措施 | 产品安全设计 | 风险数据基础 |
| 安全测试 | 扫描、SAST/SCA、固件分析、渗透测试等 | 验证安全性 | 测试结果关联 |
| 漏洞处理 | 工单、补丁、修复、验证、关闭记录 | 证明持续处理能力 | 漏洞生命周期 |
| 支持期 | 安全支持周期、更新策略、EOL | 上市后持续安全 | 版本/生命周期数据 |
| 合规证明 | 技术文档、DoC、证书、评估记录 | 市场准入 | 合规证据管理基础 |
为什么 CRA 是持续合规而非一次性认证？
产品上线后，组件会更新、CVE会新增、供应商会变化、产品版本会迭代。企业需要持续证明自己掌握产品安全状态。
产品资产持续变化
新版本、新固件、新第三方组件都会改变产品的软件组成。
漏洞持续变化
新的CVE和供应链事件会不断产生新的风险，需要重新评估实际影响。
证据持续积累
持续保存扫描、分析、修复和验证记录，让合规状态可以被证明。
ONEKEY：从产品软件组成到持续漏洞管理
ONEKEY的价值不是替企业"完成法规认证"，而是帮助企业建立CRA所需的产品安全数据基础和持续漏洞管理能力，让合规工作从人工盘点转向可持续、可量化、可追踪。
CRA Readiness Assessment｜合规准备度评估
从产品范围、分类、软件供应链、漏洞管理和生命周期流程等维度识别差距，形成整改优先级。
Product Discovery｜产品软件组成识别
分析软件、固件及组件组成，建立产品级软件资产，为SBOM和漏洞影响分析提供基础。
SBOM｜软件物料清单
建立组件、版本、依赖关系和供应商信息，支持标准化SBOM管理与软件供应链透明度。
Vulnerability Intelligence｜漏洞情报
将产品组件与漏洞情报关联，识别受影响产品和版本，减少无效漏洞告警。
Impact Analysis｜漏洞影响分析
从"有漏洞"进一步判断"产品是否真的受影响"，帮助安全团队进行风险优先级排序。
Remediation Tracking｜修复闭环
跟踪漏洞处置、补丁升级、缓解措施和验证状态，形成可追踪的整改记录。
Continuous Monitoring｜持续监控
当组件、版本和漏洞信息发生变化时持续评估产品风险，支撑上市后的持续安全管理。
Evidence｜合规证据基础
将产品分析、SBOM、漏洞和修复记录沉淀为持续维护的安全数据，为技术文档和合规审查提供数据基础。
把 CRA 法规要求映射到企业实际工作
| CRA要求 | 企业要解决的问题 | 技术动作 | ONEKEY价值 |
|---|---|---|---|
| 产品范围识别 | 哪些产品受CRA影响？ | 建立产品清单和数字元素分析 | 产品资产发现与分析 |
| 风险评估 | 产品面临哪些网络安全风险？ | 组件、漏洞、攻击面关联 | 产品风险数据基础 |
| SBOM | 产品到底用了哪些组件？ | 生成/导入/维护SBOM | SBOM与组件管理 |
| 漏洞处理 | 哪些CVE真正影响产品？ | 漏洞扫描、匹配、影响分析 | 漏洞情报与产品关联 |
| 修复 | 哪些问题应该先修？ | 风险排序、修复跟踪、验证 | 整改闭环 |
| 持续合规 | 产品发布后如何持续掌握风险？ | 持续监控版本、组件和漏洞 | 持续监控 |
企业 CRA 项目建议：按 4 个阶段推进
法规适用性与产品盘点
建立产品清单；确认欧盟市场；判断是否属于产品数字元素范围；识别与RED、MDR、IVDR、车辆法规等的关系；确定潜在分类。
产品安全基线与差距分析
对照Annex I、II、VII梳理产品设计、漏洞管理、用户信息、技术文档、支持周期和安全更新机制。
技术能力建设
建立SBOM、SCA/固件分析、漏洞情报、影响分析、修复闭环、CVD和安全事件响应能力。
符合性评估与持续运营
选择适用符合性评估路径；准备技术文档和DoC；完成市场准入；建立持续漏洞监控与报告机制。
CRA 产品适用性快速自测
此板块仅为初步筛查工具，不替代法律或符合性评估。回答以下问题，可获得下一步行动建议。
产品是否包含软件、固件、数字功能或数据处理能力？
产品是否在欧盟市场提供，或计划进入欧盟市场？
产品是否属于网络、安全、身份、操作系统或其他高风险数字产品？
产品是否同时受其他欧盟法规约束？
企业目前是否已经具备SBOM和持续漏洞管理能力？
建议下一步进行产品范围确认、产品分类判断和CRA Gap Assessment，并根据分类确定符合性评估路径。
CRA 常见专业问题
1. CRA的正式法规名称和编号是什么？
正式法规为Regulation (EU) 2024/2847，即“Regulation on horizontal cybersecurity requirements for products with digital elements”，通常称Cyber Resilience Act（CRA）。
2. CRA什么时候全面适用？
CRA于2024年12月10日生效，主要义务自2027年12月11日起适用；符合性评估机构通知相关章节自2026年6月11日起适用；Article 14报告义务自2026年9月11日起适用。
3. CRA是不是只管IoT？
不是。CRA覆盖范围明显大于传统IoT法规，软件和硬件产品均可能属于“含数字元素产品”，包括单独投放市场的软件和组件。
4. 普通软件是否也需要CRA？
可能需要。关键判断不是“软件/硬件”二分，而是是否属于CRA定义的产品范围，以及是否存在排除或其他法规优先适用情形。
5. Class I和Class II有什么区别？
两者均属于Important Products，但Annex III将产品分成Class I和Class II，Class II通常对应更高的网络安全风险，并适用更严格的符合性评估要求。
6. 产品集成了一个Class I组件，整个产品是否自动变成Class I？
不当然。CRA Article 7明确指出，集成一个核心功能属于Annex III的产品，本身并不自动使集成后的产品受同样的Article 32(2)/(3)评估程序约束，需要分析集成产品本身的核心功能和法规范围。
7. CRA是不是所有产品都必须找第三方认证？
不是。不同类别适用不同符合性评估路径。企业应根据产品类别、协调标准、技术规范及相关欧盟网络安全认证方案确定是否需要Notified Body。
8. CRA为什么特别强调漏洞管理？
CRA把漏洞处理纳入产品制造商的基本义务，并要求在产品支持期内有效处理产品及组件漏洞。这意味着企业需要建立持续漏洞识别、修复、更新和披露机制。
9. CRA要求企业提供SBOM吗？
CRA明确要求制造商掌握和处理产品及组件相关漏洞，并在用户信息中规定：如果制造商决定向用户提供SBOM，需要提供SBOM访问信息。因此SBOM是非常重要的产品软件供应链治理基础，但不能简单表述为“所有产品必须向用户公开完整SBOM”。
10. CRA的24小时和72小时报告是什么？
从制造商知悉主动被利用漏洞或严重事件开始，早期预警不迟于24小时，主要通知不迟于72小时；之后还需按照漏洞/事件类型提交最终报告。
11. CRA和CE是什么关系？
CE是欧盟市场产品符合相关欧盟法规的重要标志。CRA建立了产品网络安全方面的基本要求和符合性评估规则。对于适用CRA的产品，完成相关符合性要求后，按照法规要求进行EU Declaration of Conformity和CE标志等市场准入步骤。
12. CRA和ISO/IEC 27001可以互相替代吗？
不能。ISO/IEC 27001主要关注组织层面的信息安全管理体系；CRA主要针对含数字元素产品的网络安全及制造商产品生命周期义务。两者可以形成互补。
13. CRA和ISO/IEC 62443有什么关系？
对于工业自动化和控制产品，可以将IEC 62443相关实践作为产品和开发流程的技术参考，但是否可以产生CRA下的符合性推定，要看具体协调标准、标准版本及欧盟官方认可情况。
14. CRA是否要求安全支持期？
是。制造商需要在产品支持期内有效处理漏洞，并向用户提供安全技术支持期结束日期等信息。支持期需要结合产品性质、使用预期和法规要求合理确定。
15. 已经上市的旧产品还需要做CRA吗？
欧盟委员会当前说明：在2027年12月11日前已投放市场的产品，一般仅在该日期之后发生重大修改等特定情况下受到CRA主要要求影响；但Article 14报告义务适用于已经在欧盟市场提供的相关产品。
17. CRA合规需要准备哪些技术文档？
主要技术文档包括：安全设计文档、漏洞管理流程说明、SBOM（软件物料清单）、符合性声明等。这些文档需要详细说明产品如何满足CRA的各项要求。
18. CRA 要求的 SBOM 最小字段集是什么？
最少需要囊括如下7个最小字段：组件供应商、组件名称、版本、唯一标识符、依赖关系、SBOM 作者、生成时间戳。
19. CRA认证需要多长时间？
根据不同等级的产品，CRA的认证方式不同，认证需要的时间也不尽相同。技术文档准备时间取决于产品复杂度和现有安全基础。对于安全基础较好的产品，通常需要数周时间；对于需要大幅改进的产品，可能需要数月时间。高风险产品如需公告机构审核，时间会更长。
20. 违反CRA会有什么后果？
违反CRA可能会导致巨额行政罚款：违反核心网络安全要求的，最高可处以1500万欧元罚款，或全球年营业额的2.5%；其他违规行为最高可处以1000万欧元罚款，或营业额的2%；向当局提供虚假或不完整信息的，最高可处以500万欧元罚款，或营业额的1%。此外，当局可要求企业纠正安全漏洞，并限制或召回不合规产品。
权威法规与实施资料
正式项目建议优先引用欧盟官方法规、欧盟委员会指导文件和ENISA实施资料。
现在着手做CRA合规准备，而不是2027年再整改
从产品范围、分类、SBOM、漏洞影响分析，到持续漏洞管理和合规证据，ONEKEY帮助企业建立面向CRA的产品安全数据基础。
