产品已经出货，第三方开源组件突然曝出正在被利用的漏洞：谁来判断影响、谁在24小时内启动欧盟报告、补丁要维护到哪一年、旧型号是否也要处理？过去这些问题常被当作售后或研发内部事项；《欧盟网络韧性法案》把它们变成了产品进入和留在欧盟市场所必须管理的合规责任。
文章摘要： 欧盟《网络韧性法案》（Cyber Resilience Act，CRA）即Regulation (EU) 2024/2847，主要管理带数字要素产品从设计、投放市场到支持期结束的网络安全。法规于2024年12月10日生效，漏洞和严重事件报告义务自2026年9月11日起适用，主体要求自2027年12月11日起适用。它不是一项独立的“CRA证书”业务，而是一套涵盖产品范围判断、网络安全风险评估、漏洞处理、支持期、技术文件、符合性评估、欧盟符合性声明和CE标志的市场准入制度。权检认证可围绕实际型号协助完成适用性分析、差距评估、测试规划、文件编制与整改验证，但制造商及供应链主体仍须按其法定角色承担责任。
一、CRA究竟改变了什么？
CRA把“出厂时没有已知漏洞”扩展为“在整个支持期内持续管理网络安全风险”。按照法规第1至3条，其目标是为带数字要素产品在欧盟市场提供统一网络安全要求，并改善产品全生命周期的透明度和漏洞处置。
这里的“产品”并不只指硬件。只要软件或硬件产品被投放欧盟市场，而且其预期用途或合理可预见用途包含与设备或网络的直接或间接、逻辑或物理数据连接，就应先做CRA范围判断。单独投放市场的软硬件组件也可能属于产品；由制造商设计、开发或在其责任下提供，且缺少后会使产品无法执行某项功能的远程数据处理方案，也可能成为产品组成部分。
这意味着CRA项目不能只在发货前补一份渗透测试报告。产品架构、默认配置、身份认证、数据保护、攻击面、更新机制、第三方组件、漏洞接收和修复流程，都要能回到法规要求和技术证据。对准备进入欧盟的联网设备、嵌入式产品、应用软件或独立软件，越晚识别法规角色和产品边界，后期重新设计安全更新、日志、认证或标签的成本通常越高。
二、哪些硬件、软件和云功能会进入范围？
常见落入范围的对象包括联网消费电子、智能家居、可穿戴设备、路由器和网关、联网玩具、工业控制组件、网络安全产品、操作系统、移动或桌面应用、独立销售的软件、嵌入式固件，以及单独投放市场并具有数字功能的组件。是否收费并非唯一判断标准；商业活动中提供的免费软件同样可能“在商业活动过程中提供于市场”。欧盟委员会CRA概览也将法规概括为适用于直接或间接连接其他设备或网络的硬件和软件产品。
范围判断至少应明确四件事：产品的核心功能是什么，哪些软件和远程功能属于交付的一部分，谁控制其设计与更新，产品以何种方式向欧盟市场提供。仅把云端功能写成“服务”，并不能自动排除；若远程处理由制造商设计或在其责任下开发，且缺少它产品就不能实现某项功能，该远程处理可能按CRA中的“remote data processing solution”处理。
另一方面，通用的独立云服务、SaaS或网站通常不因服务本身直接成为CRA产品；它们可能落入NIS2等其他制度。把设备、App、云平台和后台运维混成一个不设边界的“系统”，会让风险评估、支持期和责任主体难以落地。权检认证在范围预判时会先画出产品架构与数据连接图，再逐项确定纳入CRA技术文件的硬件、软件、接口和远程功能。
CRA的主要排除包括：受欧盟医疗器械法规Regulation (EU) 2017/745或体外诊断医疗器械法规Regulation (EU) 2017/746管理的产品；受Regulation (EU) 2019/2144相关车辆型式批准网络安全要求约束的产品；按Regulation (EU) 2018/1139认证的部分航空产品；属于Directive 2014/90/EU范围的船用设备；按相同规格替换、且不改变风险水平的特定备件；以及专为国家安全、国防或处理机密信息开发或修改的产品。此后通过的Delegated Regulation (EU) 2025/1535还排除了Regulation (EU) No 168/2013范围内的L类车辆相关数字产品，但该排除不适用于其中指定的L1e助力车类别。准确边界仍应以CRA第2条和现行补充法案为准，不能只凭行业名称排除。
自由和开源软件并非一概豁免：在商业活动之外开发或提供的自由和开源软件通常不适用普通产品义务；以商业方式提供时仍可能进入范围。对以持续、系统方式支持开源产品开发并维护其商业用途可行性的“open-source software steward”，法规另设较轻但真实存在的第24条义务。
三、CRA什么时候实施？现在已经要做什么？
根据法规第71条和欧盟委员会实施时间线，关键节点如下：
| 日期 | 法律效果 | 企业应对重点 |
|---|---|---|
| 2024年12月10日 | CRA生效 | 启动产品盘点、角色确认和设计差距分析 |
| 2026年6月11日 | 第四章第35至51条开始适用 | 合格评定机构通知与监管体系进入实施阶段 |
| 2026年9月11日 | 第14条报告义务开始适用 | 已在范围内的产品要建立并实际运行漏洞、严重事件报告机制 |
| 2027年12月11日 | 法规主体要求全面适用 | 新投放市场的范围内产品须完成适用合格评定、技术文件、EU DoC和CE等要求 |
截至本文更新日2026年9月29日，第14条报告义务已经生效，不应等到2027年才搭建报告流程。第69条过渡规定还明确：第14条适用于在2027年12月11日前已投放市场的范围内产品。其他主体要求对该日前已投放的产品通常只在其此后发生“substantial modification（实质性修改）”时适用。
“库存旧型号”不是统一豁免词。企业需要保存首次投放市场、版本、软件更新和修改内容的证据，并判断后续改变是否影响原有合规性或预期用途。新项目也不宜把2027年当作开始日期，因为支持期承诺、更新架构、漏洞披露接口和第三方组件治理都需要在产品设计阶段建立。
四、网络安全风险评估如何进入产品设计？
CRA第13条与附件I要求制造商在产品规划、设计、开发、生产、交付和维护中进行并记录网络安全风险评估。评估要考虑预期用途、合理可预见用途、使用条件、产品可能被使用的环境、受影响资产及支持期内的变化，并以此决定适用的基本网络安全要求。
附件I第一部分并不是要求所有产品堆叠相同功能。核心逻辑是基于风险做到“secure by design and by default”：产品在没有已知可利用漏洞的情况下提供；具有与风险相称的默认安全配置；防止未授权访问；保护数据机密性、完整性与必要时的可用性；限制攻击面；降低事件影响；提供安全相关日志或监测能力；并使安全漏洞可通过更新得到处理。某项要求不适用时，也要在技术文件中给出基于产品和风险的理由。
一份可用的风险评估通常会完成以下闭环：
- 固定产品型号、硬件版本、固件或软件版本、组件清单、交付附件和远程功能边界；
- 列出资产、接口、信任边界、数据流、用户与权限，形成攻击面和威胁场景；
- 评价漏洞被利用的可能性及对机密性、完整性、可用性、业务连续性和人身安全的影响；
- 将安全控制映射到附件I，区分设计控制、默认配置、生产控制、用户措施和后台运维措施；
- 通过代码审查、成分分析、接口测试、身份认证测试、模糊测试、渗透测试、更新与回滚验证等手段取得证据；
- 记录残余风险、量产一致性、版本变化、触发再评估的条件和批准责任。
测试项目应由风险和产品架构驱动，不是“所有设备固定做一套扫描”。权检认证可协助把法规条款、适用标准或测试规范、产品控制和证据一一映射，并针对发现的默认口令、弱认证、非安全更新、敏感数据暴露、开放接口或组件漏洞形成整改验证方案。
五、漏洞处理、SBOM与支持期应怎样落地？
附件I第二部分要求制造商在支持期内建立漏洞处理流程，包括识别和记录产品及其组件中的漏洞，维护软件物料清单（SBOM），至少覆盖产品的顶层依赖；及时修复或缓解漏洞；有效、定期地开展安全测试和审查；发布安全更新；建立协调漏洞披露政策和单一联系点；促进产品漏洞信息共享。SBOM是技术文件的一部分，但CRA没有把某一种商业工具或某一种交换格式写成唯一合法方案。
第三方商业组件或开源组件也不能被当作供应商自己的问题。第13条与第15条要求制造商在集成其他组件时尽到适当注意义务，并在发现组件漏洞时向相关维护者报告和提供修复信息；自身产品受到影响时，仍要完成分析、修复、发布和用户沟通。采购合同最好事先约定组件清单、漏洞通知、修复窗口、版本寿命和证据交付。
支持期不是任意写一个短期限。制造商应结合用户合理预期、产品性质与用途、预期使用时间、支持环境以及同类产品支持期确定支持期限；原则上至少五年。只有产品预计使用时间少于五年时，支持期才可相应缩短；预计使用超过五年时，支持应与预期使用相匹配。支持期截止时间至少应以月份和年份清楚告知购买者，欧盟委员会2026年实施指南和FAQ可作为项目解释的最新官方参考。
在支持期内发布的每项安全更新，应在发布后至少保持可用十年，或保持到产品支持期结束，以较长者为准。企业因此需要提前规划更新服务器、签名密钥、版本存档、离线更新、供应商终止支持和产品停产后的责任，而不是在最后一次销售后立即关闭更新渠道。
六、24小时、72小时和最终报告分别报什么？
制造商一旦知悉产品存在“actively exploited vulnerability（被积极利用的漏洞）”，应按CRA第14条通过统一报告平台履行分阶段报告：
- 24小时内提交早期预警，至少说明受影响产品、漏洞性质，以及在适用情况下说明可能已知的利用发生地；
- 72小时内提交漏洞通知，补充一般信息、严重程度、影响、已采取或建议采取的缓解或纠正措施；确需时可请求延期公开相关信息；
- 纠正或缓解措施可用后14天内提交最终报告，至少包括漏洞描述、严重程度、影响、根因或恶意行为者信息（如适用）、已采取措施及其他可帮助主管机关的信息。
对影响产品安全的“severe incident（严重事件）”，同样在知悉后24小时内早期预警、72小时内提交主要事件通知，并在主要通知后一个月内提交最终报告。企业不宜把“发现时间”理解为管理层最终批准时间；内部流程应明确监测、初筛、升级、法务或安全判断、报告账号和节假日值班责任。
报告通过ENISA建立的Single Reporting Platform单一报告平台提交，同时送达相关成员国指定的CSIRT协调机构和ENISA。欧盟委员会的CRA报告说明页提供了当前实施入口和说明。制造商还应在不无故拖延的情况下，向受影响用户告知漏洞或严重事件及可采取的缓解或纠正措施。
报告机制不是把技术团队的一封邮件转交即可。建议预先准备产品身份、版本与销售地、漏洞确认标准、CVSS或内部严重度、被利用证据、用户影响、临时缓解、补丁计划、监管联络人和对外沟通模板，并定期演练24小时窗口。
七、“重要产品”和“关键产品”如何分级？
CRA大多数范围内产品属于普通产品，可以按风险选择常规合格评定路径；部分产品因核心功能具有较高网络安全影响，被列入附件III的“important products（重要产品）”I类或II类，附件IV另列“critical products（关键产品）”。判断看的是产品的核心功能是否属于相应类别，而不是产品只要包含了某个列名组件就自动升级。
附件III I类包括身份与访问管理软件和硬件、独立或嵌入式浏览器、密码管理器、恶意软件检测或清除产品、VPN、网络管理与SIEM、引导管理器、PKI和数字证书签发软件、网络接口、操作系统、路由器/调制解调器/交换机、特定安全微处理器或微控制器、带安全功能的智能家居与智能助理、部分联网玩具和可穿戴健康监测产品。II类包括虚拟机管理程序和容器运行系统、防火墙与入侵检测/防御系统，以及防篡改微处理器和微控制器。附件IV关键产品包括硬件安全设备、具有高级安全特征的智能电表网关及类似设备，以及智能卡或安全元件。
欧盟已通过Implementing Regulation (EU) 2025/2392给出附件III和IV类别的技术描述。实际项目仍需用核心功能、技术特征和市场用途与实施法规逐项对照，不能只按营销名称分级。
分级直接影响合格评定：
- 普通产品： 一般可采用附件VIII的内部控制（Module A），制造商也可选择第三方路线；
- 重要产品I类： 只有在完全采用覆盖所有适用要求的协调标准、共同规范或法规认可的网络安全认证方案时，才可使用Module A；否则采用EU型式检验加内部生产控制（Module B+C）或全面质量保证（Module H）；
- 重要产品II类： 不能仅靠普通自我评定，应采用B+C、H，或在适用时采用法规认可且达到相应保证等级的欧盟网络安全认证方案；
- 关键产品： 如果欧盟委员会通过委托法要求使用指定欧洲网络安全认证方案，则按该方案执行；在相关委托法尚未提出强制方案时，法规规定采用与II类相应的第三方路径。
因此，市场上常说的“CRA认证”不是一张适用于所有产品的统一证书。部分产品可以自我评定，部分必须由公告机构参与，另一些未来可能进入强制欧洲网络安全认证方案；路线必须由具体产品分级和届时有效的实施法案决定。
八、CE、EU DoC、技术文件和随附信息怎样组成证据链？
制造商完成适用合格评定并证明满足附件I要求后，应编制EU Declaration of Conformity（欧盟符合性声明）并加贴CE标志。若产品同时受RED、EMC、LVD、RoHS等法规管理，可以编制覆盖各适用欧盟法规的一份EU DoC；CE仍是相应法规体系下的合规标志，不应另造“CRA标志”或虚构“CRA证书”。CRA第27至32条及附件V、VI规定了DoC与CE的基本要求。
技术文件应在产品投放市场前形成，并在支持期内持续更新。按附件VII，常见内容包括：产品及版本说明、预期用途和合理可预见用途、支持期、产品架构或功能原理、网络安全风险评估、附件I要求适用性与控制说明、设计开发和漏洞处理过程、SBOM、采用标准或规范、测试报告、合格评定资料、EU DoC，以及产品投放后处理漏洞的流程和证据。文件可以与其他欧盟法规的技术文件合并，但应能快速定位每项要求的证据。
技术文件和EU DoC至少保存至产品投放市场后十年或支持期结束，以较晚者为准。产品可随附简化版EU DoC，但需提供可访问完整声明的准确网址。附件II还要求向用户清楚提供产品与制造商识别信息、单一漏洞报告联系点、预期用途和安全环境、可预见网络安全风险、支持类型与支持期截止日期，以及安全安装、运行、更新和退役等信息。
标签和界面设计也应在量产前核对：型号、批次或序列号等产品识别，制造商名称及邮寄和电子联系方式，进口商信息（适用时），CE标志和用户信息需要与DoC、技术文件、包装、说明书和销售页面保持一致。无法合理标在产品本体时，法规允许按条件放在包装或随附文件，但不能为了版面方便随意省略。
九、进口商、经销商和贴牌销售方承担什么责任？
进口商把欧盟境外制造商的产品投放欧盟市场前，应核实制造商已完成适用合格评定和技术文件，产品带有CE，随附EU DoC或简化声明及附件II用户信息，并已标明支持期。进口商还要标示自身名称、注册商号或商标、邮寄地址和电子联系方式，保存DoC、确保技术文件可供主管机关取得，并在发现不合规、重大网络安全风险或漏洞时采取停止投放、纠正、撤回或召回及通知措施。具体义务见CRA第19条。
经销商应以适当注意义务核查CE、制造商和进口商信息、用户资料及其他明显合规事项；已知或应当认为产品不合规时不得继续提供。发现漏洞要及时通知制造商；构成重大网络安全风险时，还需通知相关市场监管机关。仓储、运输和销售过程也不能破坏产品合规性。第20条并没有允许经销商仅凭供应商一句“已做CRA”免除核查。
进口商或经销商以自己的名称或商标投放产品，或者对已投放产品作实质性修改，将被视为制造商并承担制造商义务。代工、贴牌、固件二次开发、App换牌、后台迁移和功能解锁等项目，应在合同与版本计划阶段判断是否造成角色变化，而不是等海关或平台审核时才确认责任。
供应链资料交付建议写入合同：组件与版本清单、漏洞通知时限、修复责任、更新签名和发布权限、支持期、测试与DoC资料、监管询问响应、退市与召回协作。法规责任不能通过合同转移给监管机关之外的主体，但合同能减少关键证据拿不到、24小时窗口内找不到负责人的现实风险。
十、CRA与RED网络安全、NIS2是什么关系？
CRA和RED可能同时出现在无线产品项目中，但时间线与对象不同。RED授权法规Commission Delegated Regulation (EU) 2022/30所激活的网络安全基本要求自2025年8月1日起适用于其覆盖的无线电设备。为避免CRA全面适用后的重叠，欧盟委员会已通过Delegated Regulation (EU) 2026/339，自2027年12月11日起废止2022/30；2025年8月1日至2027年12月10日期间已投放市场设备的RED市场监管仍会继续。
因此，现在投放欧盟的联网无线产品不能因为CRA将在2027年全面适用，就跳过当前RED网络安全要求；为2027年后设计的新平台，也不宜只满足RED现行测试点而忽略CRA的支持期、漏洞管理、报告、技术文件和产品分级。合理做法是建立一张跨法规矩阵，区分相同控制可以复用的证据和每部法规特有的义务。
NIS2则主要要求重要和关键实体对其网络与信息系统实施组织层面的网络安全风险管理和事件报告。CRA聚焦投放市场的带数字要素产品及其制造商、进口商和经销商；NIS2聚焦受覆盖实体及其服务运行。二者互补，产品取得CRA下的CE并不能代替企业在NIS2下的治理、供应链风险、业务连续性和事件报告责任。欧盟委员会的CRA政策页说明CRA与NIS2等欧盟网络安全框架的互补关系，ENISA的NIS2专题页可用于核对NIS2对象与实施资料。
若产品还属于机械、医疗、车辆、无线设备、通用产品安全或数据保护等领域，应分别做法规矩阵。CRA不会自动替代其他产品安全、电气安全、无线频谱、隐私或行业网络安全要求。
十一、从现在到2027年怎样准备？结论与官方依据
企业现在最有效的动作不是先采购一张“CRA证书”，而是把产品、流程和证据同时建起来。建议按以下顺序推进：
第一步：盘点产品和版本。 列出硬件、固件、软件、App、云端依赖、组件、接口、目标用户、销售模式和欧盟供应链角色；区分已投放型号、在售型号和2027年后拟投放型号。
第二步：完成范围与分级。 对照CRA定义、排除条款、2025/2392技术描述以及其他行业法规，确定普通、重要I类、重要II类或关键产品，并选择可行的合格评定路线。不要用产品名称替代“核心功能”分析。
第三步：建立要求矩阵和风险评估。 把附件I逐项映射至产品控制、开发流程、测试与文件；对不适用项记录理由，对缺口确定负责人和整改日期。技术参考可结合产品选择IEC 62443-4-1、IEC 62443-4-2、ETSI EN 303 645、ISO/IEC 29147、ISO/IEC 30111等，但是否形成CRA符合性推定，必须以项目时欧盟官方公报所列协调标准及其适用范围为准。欧盟委员会CRA标准化专题可跟踪官方进展。
第四步：让漏洞流程真正运行。 建立SBOM、第三方组件准入、漏洞监测、单一披露入口、分级修复、更新签名、用户通知和支持期退出机制；完成ENISA报告平台账号、权限、内部24/72小时决策链和桌面演练。
第五步：收口合格评定和量产证据。 根据分类完成内部控制或公告机构参与的评定，整理技术文件、EU DoC、CE、说明书、标签及支持期信息，并通过版本和变更控制保持量产一致性。软件更新、硬件替代和云端变更都要评估是否触发文件更新或实质性修改。
常见误区包括：把CRA理解成一次性取证；只扫描成品而不管理开发流程和组件；把开源组件全部视为豁免；支持期随意写短；认为2027年前的产品无需报告；将所有云功能都排除；看到“重要产品”就默认必须买某一种证书；已有RED网络安全报告就认为CRA全部满足。这些判断都可能使范围、时间线或证据链出现实质缺口。
权检认证可从前期范围和分类判断开始，协助制定测试与标准路线、开展风险与文件差距分析、规划网络安全验证、整理技术文件和标签信息，并对整改后的控制进行复核。服务目标是让每个结论都能对应具体型号、版本、条款和证据，而不是承诺一张不存在的通用“CRA证书”。
结论： CRA把产品网络安全从可选质量能力变成欧盟市场准入和持续在市管理的一部分。2027年12月11日是主体要求全面适用日，但报告义务已于2026年9月11日生效。越早完成产品边界、分级、支持期、漏洞处理和证据规划，越容易把整改放进正常研发周期，避免在投放前集中返工。
官方依据
- Regulation (EU) 2024/2847（CRA法规正文）
- 欧盟委员会：Cyber Resilience Act简要说明
- 欧盟委员会：CRA实施时间线
- 欧盟委员会：CRA报告义务说明
- ENISA：Single Reporting Platform
- Implementing Regulation (EU) 2025/2392（重要及关键产品技术描述）
- Delegated Regulation (EU) 2025/1535（部分L类车辆产品排除）
- Delegated Regulation (EU) 2026/339（RED网络安全授权法规衔接）
- 欧盟委员会：CRA实施指南与FAQ发布页
- 欧盟委员会：CRA标准化进展
- ENISA：NIS2专题
法规说明： 本文依据截至2026年9月29日可核验的欧盟官方资料整理，用于一般信息与项目准备，不构成法律意见、监管决定或对特定产品合规结果的保证。法规实施文件、协调标准引用、网络安全认证方案、公告机构范围和主管机关实践仍可能更新，实际项目应按最终产品、版本、核心功能、供应链角色和投放日期重新核对。 本文由AI辅导进行创作。
