欧盟CRA网络弹性法案出海企业合规指南

2/2欧盟CRA网络弹性法案出海企业合规指南法规依据：Regulation(EU)2024/2847oftheEuropeanParliamentandoftheCouncil（欧盟《网络弹性法案》，简称CRA）信息更新截止时间：2026年7月31日生效时间：2024年12月10日正式生效，分阶段强制实施核心时间节点：2026年9月11日：制造商漏洞与严重安全事件上报义务正式生效（Article14）2027年12月11日：全部核心义务全面实施，新产品须满足全生命周期安全要求并加贴CE标志文档合规声明本指南基于欧盟《网络弹性法案》（Regulation(EU)2024/2847）公开文本及欧盟委员会2026年7月27日发布的官方适用指南（CommunicationC(2026)5252）编制，旨在帮助企业理解法规要求并规划合规路径。文档内容仅供参考，不构成法律意见。具体合规方案建议结合企业实际情况，必要时咨询专业合规律师。法规实施细则与技术标准处于持续更新中，请以欧盟官方最新发布为准。

目录第一部分政策背景与适用范围判定 3第1章CRA法案概述与立法背景 3第2章适用范围与产品分类判定 5第3章中国企业常见认知误区澄清 9第二部分核心义务详解与落地实施 12第4章漏洞管理与安全事件上报制度 12第5章软件物料清单（SBOM）编制与管理 16第6章安全设计与默认安全（SecuritybyDesign&Default） 20第7章安全更新与产品支持周期制度 23第三部分合规认证与技术文档 27第8章合格评定与CE认证 27第9章技术文档体系建设 30第10章授权代表与欧盟境内责任人 33第四部分违规后果与合规落地路线图 36第11章违规法律后果与执法机制 36第12章企业合规落地路线图（2026-2027） 39第13章不同规模企业的合规策略 42第14章常见合规工具与资源汇总 43第五部分附录 46附录A核心法规条文原文摘录（中文译本） 46附录B合规自查清单模板 48附录C上报文书模板 52附录D术语对照表 55

第一部分政策背景与适用范围判定第1章CRA法案概述与立法背景1.1欧盟网络安全监管体系演进：从行业指令到横向产品法规欧盟的网络安全监管经历了从"行业分治"到"产品全域覆盖"的演进过程。2016年发布的《网络与信息安全指令》（NIS指令）首次建立了欧盟层面的网络安全监管框架，但仅覆盖关键基础设施运营者和数字服务提供商；2022年生效的《NIS2指令》进一步扩大了行业覆盖范围，但仍以服务提供者为监管对象，未触及产品端的安全根源问题。随着物联网、智能硬件的普及，数字产品的安全缺陷已成为欧盟网络安全的主要风险来源。欧盟委员会2023年的调研数据显示，欧盟市场上超过70%的消费级智能设备存在中高危安全漏洞，且多数厂商未提供长期安全更新支持，大量"僵尸设备"被纳入僵尸网络，成为DDoS攻击、数据泄露的重灾区。在此背景下，欧盟启动了全球首部针对数字产品的横向网络安全立法——《网络弹性法案》（CRA），将网络安全要求嵌入产品全生命周期，从源头降低安全风险。CRA与《数字服务法案》（DSA）、《数字市场法案》（DMA）、《人工智能法案》（AIAct）共同构成欧盟数字经济监管的"四大支柱"，形成从产品到服务、从技术到市场的完整监管闭环。1.2CRA法案的立法目标与监管逻辑：全生命周期安全管控CRA的核心立法目标包含三个层面：第一，提升欧盟市场内数字产品的整体网络安全水平，确保产品从设计阶段就融入安全能力，而非事后补救；第二，建立统一的欧盟市场规则，消除各成员国产品安全要求的碎片化，降低企业合规成本；第三，保障用户知情权，让消费者和企业用户在采购数字产品时能够清晰了解产品的安全支持周期、安全特性等信息，做出理性选择。在监管逻辑上，CRA遵循"全生命周期覆盖"原则，将监管要求贯穿产品的设计、开发、生产、上市、运维、退市全流程：上市前要求产品满足基本网络安全要求，完成合格评定，加贴CE标志；上市后要求厂商持续维护产品安全，及时修复漏洞，按规定上报安全事件；退市前要求厂商提前告知产品终止支持时间，保障用户的知情权与迁移权。1.3法案法律地位：直接适用的欧盟条例，无需成员国转化CRA的法律形式是欧盟条例（Regulation），而非指令（Directive）。这一属性决定了其极强的直接执行力。【法规条文】根据欧盟运行条约第288条，条例在所有成员国具有直接适用性，无需各国立法机关转化为国内法即可生效。这意味着：2026年9月11日起，所有欧盟成员国的市场监管机构将直接依据CRA条文开展执法，不存在各国转化差异带来的缓冲期；企业无需针对不同成员国制定差异化合规方案，一套合规体系即可覆盖整个欧盟单一市场；各成员国仅可在CRA框架内细化执法程序，不得增设额外的产品安全要求。1.4分阶段实施时间表与各节点义务清单CRA采用"分阶段落地"的实施节奏，避免一次性给企业造成过大合规压力。根据法案第71条规定，核心时间节点与对应义务如下。【法规条文】Article71分阶段适用安排：1.本条例自2024年12月10日起生效；2.以下条款自不同时间点起适用：(a)关于合格评定机构通知的条款，自2026年6月11日起适用；(b)第14条（漏洞与事件上报义务），自2026年9月11日起适用；(c)其余所有实质性义务，自2027年12月11日起适用。结合欧盟委员会2026年7月27日发布的官方指南，各关键节点的具体义务清单如下：时间节点核心义务覆盖产品范围2024年12月10日法案正式生效，企业可启动合规准备—2026年6月11日合格评定公告机构资质审批启动—2026年9月11日1.发现被主动利用的漏洞后24小时内早期预警、72小时内完整上报

2.严重安全事件按时限要求上报

3.通过ENISA单一上报平台（SRP）提交报告所有已在欧盟市场销售、及未来销售的在管数字产品2027年12月11日1.所有新产品需满足AnnexI基本网络安全要求

2.完成合格评定，加贴CE标志

3.建立完整技术文档体系

4.落实安全更新与支持周期义务

5.非欧盟厂商指定欧盟授权代表2027年12月11日起新投放欧盟市场的产品真实案例参考：欧盟数字监管执法强度参考——2026年5月，欧盟委员会依据《数字服务法案》（DSA）对跨境电商平台Temu处以2亿欧元罚款，处罚理由为平台风险评估流于形式，未有效识别平台内非法产品风险。欧盟委员会在处罚决定中明确指出，"风险评估是数字监管框架的基石，未落实该义务属于严重违规"。该案体现了欧盟数字监管"强执法、高罚款、零容忍"的整体趋势。CRA作为同批次数字监管立法，执法力度将保持同一水准，企业切勿抱有"法不责众"的侥幸心理。1.5对中国出海企业的整体影响评估对于面向欧盟市场的中国智能硬件、物联网、软件企业而言，CRA的实施将带来三大核心影响：第一，合规门槛显著提升。过往多数国内企业的产品安全仅满足基本功能需求，未建立体系化的安全开发与漏洞管理流程。CRA强制要求安全设计、SBOM、漏洞上报、长期支持等能力，企业需要在研发流程、团队配置、管理制度上进行系统性调整。第二，违法成本大幅上升。最高2.5%全球营业额的罚款，叠加产品下架、召回、市场禁入等措施，违规成本远高于合规投入。对于年营收10亿元人民币的企业，2.5%的罚款对应约2500万元人民币，远超多数企业的年度安全投入。第三，市场竞争格局重构。率先完成合规的企业将获得市场准入优势，而无法满足合规要求的中小厂商可能被迫退出欧盟市场。具备完整安全能力的品牌将在竞争中占据有利位置。需要特别注意的是，2026年9月11日生效的上报义务覆盖所有已在欧盟市场销售的产品，并非仅针对新产品。即便企业的产品是2023年上市的，只要仍在欧盟市场流通，自9月11日起发现被主动利用的漏洞，就必须履行上报义务。第2章适用范围与产品分类判定2.1"带有数字元素的产品"（PDE）法定定义CRA的监管对象是"带有数字元素的产品"（ProductswithDigitalElements，简称PDE），这是判定产品是否在管的核心标准。【法规条文】Article3(1)定义："带有数字元素的产品"指任何产品，其包含软件或数字组件，且该软件或数字组件的正常运行对于产品实现其预期用途是必要的，无论该软件或数字组件是内置的、嵌入的，还是通过远程方式提供的。【法规条文】Article3(2)远程数据处理定义：通过远程数据处理方式提供功能的产品，只要其面向欧盟市场的用户提供，无论服务器是否位于欧盟境内，均属于在管范围。从定义可以看出，判定的核心标准有两个：第一，包含软件/数字组件——产品只要具备代码运行能力，无论是固件、嵌入式软件、独立应用还是云端服务，都满足该条件；第二，数字组件是产品功能的必要组成——如果数字组件只是附属功能，不影响产品核心用途，则可能不在管范围内（例如带简单电子计时功能的机械手表，计时功能不影响手表核心计时用途的，通常不被认定为PDE）。欧盟委员会2026年7月的官方指南进一步明确：只要产品能够连接网络或其他数字设备，或者能够存储、处理用户数据，原则上都属于PDE范畴。2.2覆盖产品大类明细与判定标准结合法案定义与官方指南，CRA覆盖的产品主要分为五大类，中国出海企业常见的产品基本都包含在内。（1）智能硬件与物联网消费设备智能家居产品：智能门锁、智能摄像头、智能音箱、智能灯具、智能家电（冰箱、洗衣机、空调等带联网功能的型号）；可穿戴设备：智能手表、智能手环、智能耳机；消费电子：智能电视、机顶盒、游戏主机、平板电脑。判定要点：只要具备联网、蓝牙、Wi-Fi等连接能力，或内置可更新固件，均属于在管范围。（2）网络与通信设备路由器、交换机、网关、防火墙、无线接入点；调制解调器、光猫、5GCPE设备。判定要点：网络设备是CRA监管的重点品类，属于后续分级中的"重要产品"类别，合规要求更严格。（3）工业与商业数字产品工业控制系统：PLC可编程逻辑控制器、SCADA系统、工业机器人；商业智能设备：POS机、门禁系统、监控摄像头；办公设备：网络打印机、智能会议系统。判定要点：工业类产品多数属于"重要产品"或"关键产品"，需接受公告机构强制评定。（4）软件产品独立软件：操作系统、办公软件、安全软件、行业应用软件；固件与嵌入式软件：设备内置的系统软件、驱动程序；移动应用：面向欧盟用户提供的APP应用；SaaS服务：通过云端提供的软件服务。判定要点：软件产品无论以实体介质、下载还是订阅方式提供，均属于在管范围。纯网站若不提供可下载的软件产品，通常不在CRA管辖范围内。（5）其他带数字组件的产品智能汽车配件、新能源车载设备（整车由UNR155法规管辖，不在CRA范围，但后装车载设备属于CRA范围）；医疗设备的软件配件（整机受MDR管辖的除外）；带智能功能的玩具、健身器材。2.3排除适用范围与豁免情形CRA明确列出了不适用的产品类别，主要是已被其他专项法规覆盖的领域。【法规条文】Article2适用范围排除：1.本条例不适用于：(a)受《医疗器械法规》(EU)2017/745和《体外诊断医疗器械法规》(EU)2017/746管辖的医疗器械；(b)受(EU)2018/858法规管辖的机动车及其拖车，以及联合国UNR155法规覆盖的车辆网络安全相关组件；(c)航空产品、航空发动机和相关零部件，受欧盟航空安全局（EASA）管辖；(d)国防、国家安全用途的产品；(e)仅用于研究、非商业目的的原型产品；(f)非商业性质、由个人在非商业活动中开发和提供的软件；(g)开源软件，其开发者不以商业目的将产品投放市场。需要特别澄清两个常见误解：第一，开源软件并非全部豁免。只有"非商业目的"的开源软件才可以豁免。如果企业将开源组件整合到自己的商业产品中，或者基于开源软件开发商业产品进行销售，则不能豁免，企业作为制造商需承担全部合规义务。第二，SaaS服务并非全部在管。如果SaaS服务仅提供纯内容服务，不涉及软件产品的交付，可能不在CRA范围；但如果SaaS服务包含客户端软件、嵌入式组件，或者直接作为产品提供给用户，则属于在管范围。2.4产品分级制度：标准产品/I类重要产品/II类关键产品CRA根据产品的安全风险等级，将在管产品分为三个级别，不同级别对应不同的合格评定要求和监管强度。【法规条文】Article7产品分类：1.带有数字元素的产品根据其网络安全风险程度，分为：(a)标准产品：不属于重要产品或关键产品的其他产品；(b)I类重要产品：列入附件III的产品；(c)II类关键产品：列入附件IV的产品。（1）标准产品绝大多数消费级智能硬件、普通软件都属于标准产品。这类产品的安全缺陷通常仅影响单个用户，不会造成大规模系统性风险。合规要求：可采用"自我评定"模式（ModuleA），企业自行完成安全测试、技术文档编制，签署符合性声明后即可加贴CE标志。（2）I类重要产品（AnnexIII清单）指安全缺陷可能对多个用户或特定领域造成较大影响的产品，主要包括：网络设备（路由器、交换机、防火墙、网关）；身份认证设备（智能卡、生物识别认证设备）；工业控制基础组件（PLC、工业传感器）；操作系统、数据库软件；物联网网关、边缘计算设备。合规要求：优先采用协调标准进行自我评定，无协调标准时需由公告机构进行型式检验（ModuleB）。（3）II类关键产品（AnnexIV清单）指安全缺陷可能造成重大公共安全、经济安全影响的产品，主要包括：关键基础设施使用的工业控制系统；核心网络路由设备；高保障级别的身份认证系统；政府、公共部门使用的安全产品。合规要求：必须由公告机构进行强制型式检验（ModuleB），部分产品还需加严生产过程监督。截至2026年7月，欧盟尚未发布正式的协调标准清单。欧盟委员会官方指南指出，协调标准预计将于2027年上半年陆续发布，在此之前企业可参考现有国际标准（如ISO/IEC27001、ISO/IEC15408等）进行安全建设。2.5企业自测工具：三步法判定产品是否在管企业可通过以下三个步骤快速判定自身产品是否需要遵守CRA。第一步：判断是否属于排除范围。对照Article2的排除清单，确认产品是否属于医疗器械、汽车整车、航空产品、国防产品等已被专项法规覆盖的品类。如果是，则无需适用CRA。第二步：判断是否属于"带有数字元素的产品"。回答两个核心问题：产品是否包含软件、固件或数字组件？这些数字组件是否是产品实现预期功能的必要组成部分？两个问题均回答"是"的，属于在管产品。第三步：判断产品分级。对照AnnexIII和AnnexIV清单，确认产品是否属于重要产品或关键产品；不在清单内的属于标准产品。真实案例参考：2025年，德国联邦职业安全与健康研究所（BAuA）依据《产品安全法》（GPSG）对某中国品牌智能门锁开展市场抽查，发现产品固件存在默认弱口令漏洞，且厂商未提供有效的安全更新渠道。监管机构对该品牌发出警告，要求已售产品全部推送安全更新，未售出产品暂停销售，直至整改完成。CRA全面实施后，此类产品安全问题将直接触发欧盟层面的统一执法，罚款金额最高可达全球营业额的2.5%，处罚力度远大于当前成员国的单独执法。2.6经济运营者角色认定：制造商、授权代表、进口商、分销商的义务划分CRA将产品供应链上的主体分为四类，分别承担不同的合规义务，企业需先明确自身在供应链中的角色。【法规条文】Article13-17各经济运营者义务。（1）制造商（Manufacturer）指设计、生产带有数字元素的产品，并以自身名义将产品投放市场的主体。制造商是合规第一责任人，承担全部核心义务：确保产品满足基本网络安全要求；建立漏洞管理与事件上报流程；编制技术文档与符合性声明；提供安全更新与产品支持；加贴CE标志。中国出海企业如果以自有品牌向欧盟市场销售产品，无论通过什么渠道，都属于制造商范畴，需承担全部制造商义务。（2）欧盟授权代表（AuthorisedRepresentative）指非欧盟制造商在欧盟境内指定的代理主体。【法规条文】Article15授权代表义务：非欧盟成员国设立的制造商，必须指定一名欧盟境内的授权代表，负责：保管符合性声明与技术文档，供监管机构调阅；配合监管机构的调查与执法工作；协助制造商履行事件上报与产品召回义务；作为监管机构的联系对接人。未在欧盟设立实体的中国企业，必须在2027年12月11日前指定合规的授权代表；对于2026年9月11日生效的上报义务，也建议通过授权代表完成对接，避免因跨境沟通不畅导致上报超时。（3）进口商（Importer）指将非欧盟国家生产的产品引入欧盟市场销售的主体。进口商需承担以下义务：核实制造商已完成合格评定、加贴CE标志；核实制造商已指定授权代表；保存产品合规记录；发现产品存在安全缺陷时及时通知制造商与监管机构。（4）分销商（Distributor）指在供应链中向其他主体转售产品的主体，包括电商平台卖家、线下经销商等。分销商义务相对较轻，主要包括：销售合规产品，不得销售明知不符合要求的产品；配合监管机构的市场抽查与召回工作；发现产品安全问题时及时上报。需要特别注意：如果跨境电商卖家对产品进行了重新包装、更换品牌，或者对产品软件进行了修改，则会被认定为制造商，承担全部制造商义务。第3章中国企业常见认知误区澄清在CRA合规准备过程中，国内企业普遍存在以下认知误区，可能导致合规准备滞后或方向错误，需特别澄清。3.1误区一：只有硬件产品才受监管，软件/固件/SaaS不在列这是最常见的认知错误。CRA的全称是"带有数字元素的产品"，核心监管对象既包括硬件，也包括软件本身。独立软件产品（如操作系统、办公软件、行业软件）直接属于在管产品，需满足全部CRA要求；硬件内置的固件、驱动程序，是硬件产品的数字元素，其安全责任由硬件制造商承担；SaaS服务如果包含可交付的软件组件、客户端，或者作为独立产品提供给用户，同样属于在管范围。欧盟委员会2026年7月指南明确指出，软件是CRA监管的核心品类之一，纯软件厂商与硬件厂商承担同等的合规义务。3.2误区二：通过亚马逊等平台销售，合规责任由平台承担部分企业认为，自己通过第三方电商平台销售产品，平台会负责合规审核，自身无需准备。这一认知存在严重偏差。CRA明确规定，制造商始终是产品合规的第一责任人。电商平台仅承担分销商层面的核验义务，不替代制造商的主体责任。即便平台通过了产品上架审核，一旦产品被监管机构查出不合规，处罚对象首先是制造商，平台仅在明知产品违规仍允许销售的情况下承担连带责任。从DSA的执法实践来看，欧盟监管机构的执法重点始终是产品与服务的提供者，平台仅承担平台治理责任。企业切勿将合规希望寄托于平台审核，必须主动完成自身的合规体系建设。3.3误区三：产品不在欧盟本地发货，就不受CRA管辖部分直邮模式的跨境电商卖家认为，自己的仓库在中国，产品从中国直接发往欧盟消费者，不在欧盟本地备货，因此不受CRA管辖。这一理解不符合欧盟产品安全法规的基本原则。CRA的管辖标准是"产品是否投放欧盟市场"，只要产品面向欧盟消费者销售、最终交付到欧盟境内，无论发货地在哪里，都属于欧盟市场监管范围。【法规条文】Article2(1)本条例适用于所有在欧盟市场上提供的带有数字元素的产品，无论其原产地为何。事实上，跨境直邮模式反而会增加合规风险——由于没有欧盟境内的进口商对接监管，监管机构会直接通过平台追溯到卖家，要求履行合规义务，拒不配合的会直接采取平台下架、边境扣货等措施。3.4误区四：小微企业可以完全豁免CRA义务很多中小卖家听闻"小微企业豁免"，便认为自己无需做任何合规准备。实际上，CRA对小微企业的豁免范围非常有限。【法规条文】Article64(10)(a)对于微型、小型企业，监管机构可根据情况，免除其因违反第14条上报时限要求而产生的罚款。该豁免仅针对"24/72小时上报超时的罚款"，且是"可免除"而非"应当免除"，监管机构拥有自由裁量权。除此之外：小微企业仍需履行上报义务本身，只是超时可能不罚款；2027年生效的所有其他义务（安全设计、CE认证、技术文档等），小微企业均无豁免，必须全部落实；如果小微企业存在故意隐瞒漏洞、产品存在严重安全缺陷等情形，同样会被处以高额罚款。欧盟委员会2026年7月指南特别强调，小微企业豁免是"处罚酌减"，而非"义务豁免"。小微企业同样需要建立合规体系，只是在处罚环节会酌情考量企业规模与承受能力。3.5误区五：等2027年再准备也来得及，现在不用着急这是最危险的认知误区。CRA的义务是分阶段生效的，并非全部等到2027年：2026年9月11日，漏洞与事件上报义务就已正式生效，距今仅不足两个月。如果企业没有建立漏洞监测、事件响应、上报流程，届时一旦出现被利用的漏洞，就会直接构成违规；技术文档、SBOM、安全开发流程等体系建设，需要3-6个月的周期，部分产品的合格评定流程可能长达半年以上。等到2027年再启动准备，必然无法按时完成，将面临产品无法上市的风险；欧盟市场监管机构已在开展执法能力建设，2027年全面实施后将快速启动市场抽查，未合规产品将直接被挡在欧盟市场之外。对于多数中国企业而言，当前最紧迫的任务是在9月11日前完成上报义务的合规准备，这是CRA落地的第一关，也是成本最低、见效最快的合规动作。

第二部分核心义务详解与落地实施第4章漏洞管理与安全事件上报制度漏洞与事件上报是CRA最先生效的核心义务，也是当前企业合规准备的重中之重。2026年9月11日起，所有在欧盟市场销售的数字产品，一旦出现被主动利用的漏洞或严重安全事件，厂商必须按法定时限上报欧盟监管机构。4.1上报义务法定要求总览【法规条文】Article14漏洞与严重事件的通知：1.制造商在获悉其产品中存在被主动利用的漏洞，或发生影响产品安全的严重事件后，应当立即通知主管当局。2.通知分三个阶段提交：(a)早期预警：在获悉事件后24小时内提交；(b)完整通知：在获悉事件后72小时内提交；(c)最终报告：对于被主动利用的漏洞，在纠正措施可用后14天内提交；对于严重事件，在完整通知提交后1个月内提交。【法规条文】Article16单一上报平台：1.欧盟网络安全局（ENISA）应建立并维护单一电子上报平台（SRP），供制造商统一提交通知。2.制造商通过SRP提交一次通知，即视为完成向所有相关成员国主管当局的上报义务。结合欧盟委员会2026年7月官方指南，上报义务的核心原则包括：覆盖范围广——所有在管产品，无论上市时间、产品分级，均需履行上报义务；触发标准严——只要漏洞被主动利用，无论CVSS评分高低，均需上报；时限要求紧——24小时早期预警、72小时完整通报的时限，远严于行业常规响应速度；上报渠道统一——通过ENISA的单一上报平台（SRP）一次提交，无需分别通知各国。4.2需上报的两类情形界定CRA规定了两类必须上报的情形：被主动利用的漏洞、严重安全事件。企业需准确区分两类情形，避免漏报或错报。（1）被主动利用的漏洞（ActivelyExploitedVulnerabilities）指制造商有合理证据证明，产品中的安全漏洞正在被恶意攻击者在现实环境中利用。【法规条文】Article14(1)被主动利用的漏洞，是指存在可靠证据表明该漏洞已被用于恶意目的的安全漏洞。欧盟官方指南明确了判定"主动利用"的常见证据：野外攻击样本、攻击流量被安全厂商捕获；漏洞利用代码（Exploit）已公开流传且被证实可有效利用；收到用户、安全研究者反馈的真实攻击案例；该漏洞被纳入CISA已知被利用漏洞目录（KEV）等权威清单，且经确认影响自身产品。需要特别注意：没有CVSS最低分要求，即便CVSS评分只有中危，只要被证实正在被利用，就必须上报；第三方组件（开源组件、商用SDK）的漏洞被利用，只要影响自身产品，同样需要上报，不能将责任推给上游组件厂商；内部发现、尚未被利用的漏洞，无需上报，企业自行修复即可。（2）严重安全事件（SevereIncidents）指发生在产品侧的、对产品安全功能或用户数据造成严重影响的安全事件。欧盟官方指南明确了严重事件的判定标准，满足以下任一条件即属于严重事件：导致恶意代码可在产品中执行，或产品被远程控制；导致大规模用户数据泄露，涉及个人信息、敏感数据；导致产品功能大面积失效，影响大量用户正常使用；导致产品被用于大规模网络攻击（如被纳入僵尸网络）。例如：智能摄像头被大规模破解导致用户隐私泄露、路由器漏洞被利用组建僵尸网络、云服务故障导致大量用户数据丢失等，均属于需上报的严重事件。4.3三级上报时限与内容要求CRA采用"三级上报"机制，不同阶段有明确的时限与内容要求，企业需严格按节点提交。上报阶段时限要求核心提交内容法规依据早期预警获悉事件后24小时内1.事件基本确认，说明是被利用漏洞还是严重事件

2.涉及的产品型号与版本范围

3.初步判断的影响范围（涉及的成员国、用户规模）

4.已采取的临时缓解措施Article14(2)(a)、14(4)(a)完整通报获悉事件后72小时内1.漏洞/事件的详细技术描述

2.漏洞的CVE编号（如有）、攻击利用方式

3.受影响产品的完整清单与版本信息

4.漏洞/事件的影响评估（用户影响、安全风险）

5.已采取的处置措施与用户缓解建议

6.后续修复计划与预计时间Article14(2)(b)、14(4)(b)最终报告漏洞：修复方案发布后14天内

事件：完整通报后1个月内1.完整的技术根因分析

2.修复方案的详细说明与发布情况

3.用户侧的修复指引与更新推送情况

4.事件处置复盘与长效改进措施Article14(2)(c)、14(4)(c)时限计算起点说明：时限从制造商"获悉事件"开始计算，即企业经过初步核实，有合理程度的确定性确认漏洞被利用或事件发生的时间点，而非收到原始情报的时间。欧盟官方指南明确：企业收到漏洞情报后，有合理的初步核实时间；但一旦确认事件属实，时钟立即启动，不得再以"还在调查"为由拖延上报。4.4上报渠道与接收主体（1）单一上报平台（SRP）所有上报均需通过ENISA建设的单一上报平台（SingleReportingPlatform,SRP）提交。最新进展：截至2026年7月31日，SRP平台已完成开发与安全测试，将于2026年9月11日正式上线运行。ENISA已于7月下旬发布了平台用户指南与注册说明，企业可提前注册EULogin账号，为平台上线后的使用做准备。平台核心特性：一次提交，同步送达制造商主营业地所在成员国CSIRT与ENISA；系统自动将事件信息同步给所有受影响成员国的CSIRT，企业无需逐一通知；支持事件全生命周期管理，可在线更新事件进展、提交最终报告；设有专门的小微企业帮助通道，提供申报指引与客服支持。（2）非欧盟企业的上报路径未在欧盟设立实体的中国制造商，上报路径有两种：通过欧盟授权代表提交上报，这是推荐方式，授权代表更熟悉欧盟监管沟通规则；企业直接注册SRP平台账号提交，需指定欧盟境内的联系人和联系地址。需要注意：无论采用哪种方式，上报义务的责任主体始终是制造商本身，授权代表仅负责提交操作，不承担违规的主要责任。（3）信息保密规则很多企业担心上报漏洞会导致信息泄露，反而增加攻击风险。对此CRA有明确的保密规定：上报的漏洞信息属于保密信息，仅在欧盟CSIRT网络内部共享；在厂商发布修复方案前，监管机构不会公开漏洞细节；企业可在上报时申请信息保护，说明哪些内容属于商业秘密，要求限制传播范围。真实案例参考：2024年，某全球知名路由器厂商曝出零日漏洞，被发现在野外环境中被积极利用，攻击者可通过漏洞获取设备管理员权限。由于厂商响应机制不完善，从确认漏洞到发布官方公告间隔了5天，期间大量欧洲中小企业用户遭受攻击，设备被纳入僵尸网络用于DDoS攻击。若该事件发生在2026年9月11日之后，厂商未在24小时内提交早期预警、72小时内提交完整通报，将直接违反CRA第14条规定，面临最高1500万欧元或2.5%全球营业额的罚款。该案充分说明，CRA的时限要求远严于当前行业惯例，企业必须重构自身的事件响应流程才能满足要求。4.5内部上报流程建设模板要满足24/72小时的上报要求，企业必须建立体系化的内部响应流程，而非依赖临时应急。以下是可直接落地的内部上报流程框架。（1）第一步：建立漏洞情报监测机制多源情报接入：接入NVD、CVE详情库、CISAKEV目录、各大安全厂商漏洞预警、安全社区情报、用户反馈渠道等，确保第一时间发现相关漏洞；产品影响研判：建立自身产品组件库与SBOM，收到漏洞情报后可快速匹配，判断是否影响自身产品；7×24小时值守：安排安全团队轮值，确保非工作时间也能及时接收和研判漏洞情报。（2）第二步：事件定级与升级触发规则制定明确的事件定级标准，达到上报级别的事件立即启动上报流程：一级（需上报）：确认漏洞被野外利用、发生严重安全事件→立即启动24小时上报倒计时，同步成立应急响应组；二级（观察级）：收到漏洞情报，尚未确认是否被利用→加快核实，24小时内给出结论，确认属实则升级为一级；三级（常规级）：内部发现未公开漏洞，无利用证据→按常规漏洞修复流程处理，无需上报。（3）第三步：跨部门协作流程明确各部门在事件响应与上报中的职责：安全团队负责漏洞研判、技术分析、修复方案制定、上报内容技术部分撰写；法务/合规团队负责审核上报内容、把控合规风险、对接授权代表与监管机构；研发团队负责提供产品技术信息、开发修复补丁；客服/公关团队负责准备用户通知话术、应对用户咨询；指定上报责任人，明确最终审批上报内容的负责人，确保决策高效，避免流程拖沓。（4）第四步：时间节点管控与证据留存制定上报内容模板，提前填好固定信息，事件发生时只需补充事件相关内容，缩短撰写时间；建立时间线台账，记录每个节点的操作时间、责任人、处理内容，作为合规证据留存；所有上报材料、沟通记录、证据材料需至少保存10年，以备监管机构核查。4.6小微企业特殊豁免说明针对微型、小型企业，CRA在处罚层面有一定的酌减规则，但义务层面无豁免。【法规条文】Article64(10)：(a)对于微型和小型企业，主管当局可决定不处以因违反第14条规定的通知时限而产生的行政罚款，但企业存在故意或重大过失的除外；(b)本款规定不免除企业提交通知的义务。欧盟官方指南进一步明确：小微企业的判定标准遵循欧盟中小企业定义——微型企业员工<10人且年营业额<200万欧元；小型企业员工<50人且年营业额<1000万欧元；豁免仅针对"上报超时"的罚款，不针对其他违规情形。如果企业故意隐瞒漏洞、虚假上报，仍会被处以全额罚款；豁免是"可酌定"而非"必须"，监管机构会根据事件严重程度、企业主观过错程度综合判断。因此，小微企业同样需要建立上报流程，不能因为有罚款豁免就不做准备。毕竟除了罚款，还有产品下架、召回等处罚措施，同样会对企业经营造成重大影响。第5章软件物料清单（SBOM）编制与管理软件物料清单（SoftwareBillofMaterials，简称SBOM）是CRA要求的核心合规文档之一，也是企业实现供应链安全管理、快速响应组件漏洞的基础工具。5.1SBOM的法定地位与监管价值CRA虽未在正文中直接出现"SBOM"字样，但通过组件尽职调查义务，明确了SBOM的强制性要求。【法规条文】Article13(5)制造商应确保对产品中使用的第三方组件和开源组件进行尽职调查，识别并管理相关的网络安全风险。【法规条文】AnnexIPartI(11)产品设计开发阶段应建立并维护所有软件组件的清单，包括开源组件和第三方组件，记录其版本、来源和已知漏洞。【法规序言】Recital77为确保供应链透明度，制造商应能够提供产品的软件物料清单，以支持漏洞响应与市场监管。结合欧盟委员会2026年7月官方指南，SBOM的法定地位与监管价值体现在三个层面：第一，合规必备文档——SBOM是技术文档的必备组成部分，市场监管机构抽查时可要求企业在72小时内提供；第二，漏洞响应基础——当开源组件曝出漏洞时，企业可通过SBOM快速定位受影响的产品，大幅缩短漏洞响应时间，满足CRA的上报与修复时限要求；第三，供应链管控工具——SBOM帮助企业梳理软件供应链，识别高风险组件，从源头降低供应链安全风险。对于中国出海企业而言，SBOM不仅是合规要求，更是提升自身安全管理能力的基础工具。过往Log4j、xz-utils等开源组件漏洞爆发时，多数国内企业因无法快速梳理自身产品的依赖关系，导致修复周期长达数周，在欧盟市场面临严重的安全与合规风险。5.2CRA对SBOM的强制性要求CRA对SBOM提出了最低强制性要求，企业编制的SBOM至少需满足以下标准。（1）格式要求：机器可读【法规条文】AnnexIPartI(11)组件清单应采用机器可读格式，便于自动化处理与核查。欧盟官方指南明确，SBOM不能是Excel表格、PDF文档等纯人工阅读格式，必须是符合标准规范的结构化数据格式，能够被工具自动解析。（2）内容要求：至少覆盖顶层依赖CRA要求SBOM至少覆盖产品的直接（顶层）依赖组件，间接（传递）依赖建议但不强制。欧盟官方指南与德国BSITR-03183技术指南均建议企业尽可能包含传递依赖，因为多数安全漏洞实际出现在深层传递依赖中。仅包含顶层依赖的SBOM，在漏洞响应时的实用价值会大打折扣。（3）保存要求：至少10年SBOM作为技术文档的一部分，保存期限要求与技术文档一致：自产品最后一批投放市场之日起至少保存10年。产品迭代过程中，每个版本的SBOM都需要单独留存，确保可追溯。（4）调阅要求：监管可随时要求提供市场监管机构在开展市场抽查、事件调查时，可要求企业在规定时限内提供对应产品的SBOM。无法提供或SBOM不符合要求的，将被视为未履行组件尽职调查义务，面临行政处罚。5.3SBOM标准格式选型CRA未强制指定单一SBOM格式，但行业内有两种主流的国际标准格式，均被欧盟官方认可：SPDX与CycloneDX。（1）SPDX格式SPDX（SoftwarePackageDataExchange）是ISO/IEC5962:2021国际标准，由Linux基金会主导维护，是目前应用最广泛的SBOM标准。优势：国际标准认可度高，生态工具完善，适合合规存档场景；适用场景：以合规交付、第三方审计为主要目的的企业。（2）CycloneDX格式CycloneDX由OWASP社区主导，专为安全场景设计，原生支持漏洞信息关联（VEX）、依赖图谱分析等安全功能。优势：安全属性更强，与漏洞管理工具兼容性好，支持VEX漏洞可利用性信息交换；适用场景：希望将SBOM用于内部安全运营、漏洞快速响应的企业。（3）企业选型建议若仅为满足CRA合规要求，两种格式均可，建议选择团队更熟悉、工具链更适配的格式；若希望兼顾合规与内部安全运营，优先选择CycloneDX，其VEX扩展可更好地支撑漏洞管理与事件上报；两种格式可通过工具互相转换，企业无需担心格式选错无法调整。截至2026年7月，欧盟层面的SBOM实施细则尚未正式发布。德国联邦信息安全局（BSI）发布的TR-03183技术指南是目前最详细的参考标准，欧盟后续的协调标准大概率会基于该指南制定。5.4SBOM必填字段规范结合CRA要求与BSITR-03183指南，一份合规的SBOM至少应包含以下字段。（1）文档元数据文档创建者与创建机构；SBOM版本号；创建时间（ISO8601格式）；对应产品名称与版本；SBOM格式规范版本。（2）组件基础信息每个组件需包含：组件名称；组件版本号；组件类型（开源/商用/自研）；组件唯一标识符：优先使用PURL（包URL），有CPE编号的也需记录；组件来源与下载地址；组件许可证信息。（3）依赖关系信息组件之间的依赖关系图谱；明确标注直接依赖与传递依赖；依赖层级说明。（4）安全相关信息（建议字段）组件已知漏洞（对应CVE编号）；漏洞影响状态（受影响/不受影响/正在调查/已修复）；漏洞修复版本。这部分对应CycloneDX的VEX扩展，虽非CRA强制要求，但对于企业内部漏洞管理与监管事件响应有极高价值，建议同步编制。5.5SBOM编制落地流程SBOM编制不是一次性工作，需要嵌入到产品研发流水线中，实现自动化生成与持续更新。具体落地流程如下。（1）第一步：梳理产品软件栈，明确编制范围梳理产品包含的所有软件组件：固件、操作系统、应用程序、驱动程序、第三方SDK、开源组件等；明确SBOM的颗粒度：建议至少细化到第三方库级别，自研代码可按模块粒度记录；对于多型号、多版本的产品，建议建立产品族SBOM模板，通过差异化说明区分不同型号的组件差异，降低重复工作量。（2）第二步：选择工具，接入研发流水线根据技术栈选择合适的SBOM生成工具：开源工具如SPDXTools、CycloneDXCLI、Trivy、Syft等，适合有技术能力的企业，成本较低；商业工具如各类软件成分分析（SCA）商业产品，功能更完善，支持自动化扫描与漏洞关联。落地建议：将SBOM生成工具嵌入CI/CD流水线，每次代码构建时自动生成对应版本的SBOM；建立SBOM质量校验规则，对缺失关键字段、格式错误的SBOM拦截并告警，确保输出质量。（3）第三步：补充完善，形成正式文档自动生成的SBOM通常存在信息不全的问题，需要人工补充：补充闭源商业组件的信息（自动扫描工具无法识别闭源组件）；校验依赖关系的准确性，修正误报、漏报的组件；添加产品元数据、版本信息等合规所需内容。（4）第四步：版本管理与持续更新每个产品版本对应一份SBOM，随产品版本同步迭代；当产品发布热修复、安全更新时，同步更新SBOM；建立SBOM归档制度，所有历史版本统一留存，满足10年保存要求。5.6常见问题与实操建议（1）闭源第三方组件无法获取SBOM怎么办？很多商用SDK、闭源组件的厂商不提供SBOM，导致企业无法完整编制。对此的实操建议：在采购合同中增加SBOM交付条款，要求供应商提供组件的SBOM或至少组件清单；对于无法获取SBOM的闭源组件，可通过二进制扫描工具识别其已知漏洞，同时在SBOM中记录组件名称、版本、供应商信息，注明"闭源组件，细节由供应商提供"；欧盟官方指南明确，企业对第三方组件的尽职调查义务以"合理可行"为限，并非要求获取所有组件的完整细节。企业只要能证明已尽到合理努力，即可满足合规要求。（2）传递依赖太多，是否需要全部列出？CRA强制要求至少列出直接依赖，传递依赖不做强制。但从安全实用角度，建议尽可能包含传递依赖：可设置依赖深度阈值，例如列出3层以内的传递依赖；对于安全风险高的核心组件，深度展开其依赖；对于边缘功能的组件，可仅记录顶层依赖。（3）SBOM包含产品核心代码信息，如何保密？SBOM中包含产品的组件清单，属于企业敏感技术信息。企业可采取以下保密措施：向监管机构提交SBOM时，可申请商业秘密保护，要求监管机构保密；对外提供的SBOM可进行脱敏处理，仅保留合规所需的必要字段；内部SBOM文档按涉密文档管理，控制访问权限。真实案例参考：2023年底Log4j漏洞爆发时，全球大量企业受影响。某国内智能家居厂商因没有完整的软件组件清单，无法快速确认哪些产品使用了Log4j组件，只能逐个产品排查代码，前后耗时近三周才完成全部产品的修复与用户推送。期间已有欧洲用户反馈设备被攻击，厂商收到多起投诉。若该事件发生在CRA实施后，厂商无法在72小时内完成影响评估并上报，将构成违规。而具备完整SBOM的企业，可在数小时内完成全产品线的影响面排查，快速定位受影响产品并启动修复，同时满足CRA的上报时限要求。SBOM正是欧盟针对此类供应链安全风险的制度性解决方案。第6章安全设计与默认安全（SecuritybyDesign&Default）安全设计与默认安全是CRA的核心产品要求，也是产品上市前必须满足的基本条件。CRA要求网络安全不是产品的附加功能，而是从设计阶段就融入产品基因的基础属性。6.1基本网络安全要求总览CRA附件I第一部分规定了产品设计开发阶段的基本网络安全要求，是所有在管产品必须满足的强制性标准。【法规条文】AnnexIPartI设计与开发阶段的基本网络安全要求：产品应遵循安全设计与默认安全原则，满足以下基本要求：1.基于风险管理的方法进行设计开发；2.具备适当的安全架构；3.遵循安全编码规范；4.对输入进行验证，防止注入攻击；5.保护数据的机密性、完整性与可用性；6.具备安全的身份认证与访问控制机制；7.保护软件完整性，防止未授权篡改；8.具备安全的更新机制；9.具备漏洞披露与接收渠道；10.记录产品安全相关事件的能力；11.建立并维护软件组件清单；12.移除不必要的功能与默认开启的服务；13.确保用户可获得产品安全相关信息。以上13项要求覆盖了产品安全的各个维度，是产品合格评定的核心判定标准。2027年12月11日起，不满足这些要求的产品不得投放欧盟市场。欧盟委员会2026年7月指南特别强调，安全设计要求不是"建议性最佳实践"，而是强制性法律要求。企业不能以"行业普遍做法"为由降低标准，必须严格落实每一项要求。6.2安全设计核心要素安全设计（SecuritybyDesign）指在产品设计开发的全流程中融入安全考量，而非在开发完成后再打补丁。核心落地要素包括以下方面。（1）风险管理与威胁建模产品立项阶段即启动安全风险评估，识别产品面临的主要安全威胁；采用威胁建模方法（如STRIDE模型），系统分析产品架构中的安全风险点；根据风险等级制定对应的安全防护方案，高风险点优先投入资源解决；风险评估文档需作为技术文档的一部分留存，作为合规证据。（2）安全架构设计原则产品架构设计需遵循以下安全原则：最小权限原则——每个模块、每个进程只拥有完成其功能所需的最小权限；纵深防御原则——建立多层防护机制，单一层防护被突破后仍有后续防护；攻击面最小化原则——关闭不必要的端口、服务、功能，减少可被攻击的入口；安全隔离原则——不同安全级别的模块相互隔离，避免单点突破导致全局沦陷。（3）安全编码规范实施制定企业内部的安全编码规范，覆盖所用的编程语言与开发框架；对开发人员开展安全编码培训，提升安全开发意识；接入代码安全扫描工具（SAST），在代码提交阶段自动检测常见安全漏洞；关键代码模块执行人工安全审计，确保无高危漏洞。（4）安全测试与验证产品上市前需完成全面的安全测试：功能安全测试——验证各项安全功能是否按预期工作；渗透测试——模拟攻击者视角对产品进行全面安全测试，发现潜在漏洞；模糊测试——对输入接口、协议进行模糊测试，发现未知漏洞；第三方组件安全测试——检测所用第三方组件、开源组件的已知漏洞。测试报告需纳入技术文档，作为产品满足安全要求的证明材料。6.3默认安全强制要求默认安全（SecuritybyDefault）指产品出厂时的默认配置应当是最安全的状态，无需用户额外配置即可获得基础安全保障。这是CRA针对当前大量产品"默认不安全"现状提出的针对性要求。（1）禁止默认弱口令与通用密码【法规条文】AnnexIPartI(6)产品不得设置通用默认密码，首次使用时应强制用户设置唯一密码。这是CRA最明确的硬性要求之一，也是市场抽查的重点项：禁止所有产品使用admin/admin、123456等通用默认密码；设备首次开机必须强制用户修改初始密码，不设置密码无法使用核心功能；密码需具备最低强度要求，如长度不少于8位，包含字符组合。（2）默认安全配置策略不必要的服务、端口、功能默认关闭，由用户根据需求手动开启；远程管理功能默认关闭，仅允许本地管理；用户权限默认设置为普通权限，管理员权限需用户主动开启并验证；数据采集默认遵循最小化原则，仅采集功能必需的数据。（3）用户知情权保障产品说明书需明确告知用户产品的安全特性、默认配置、安全风险；向用户提供安全配置指引，帮助用户提升产品安全等级；不得默认开启可能泄露用户隐私的功能，所有涉及隐私的功能需用户明确同意后方可开启。真实案例参考：2025年，荷兰消费者与市场管理局（ACM）对某知名智能摄像头品牌开展执法调查，发现该品牌产品出厂设置通用默认密码，且未强制用户修改，导致大量用户设备被黑客入侵，隐私视频泄露。监管机构要求该品牌立即推送强制更新，所有设备下次开机时必须修改密码才能使用，同时对已售用户发布安全警示。CRA全面实施后，此类"默认不安全"的产品将直接被认定为不符合基本安全要求，不仅会被要求整改，还将面临最高2.5%全球营业额的罚款，情节严重的将被禁止进入欧盟市场。默认安全是产品合规的底线要求，企业必须严格落实。6.4第三方组件安全管控第三方组件（包括开源组件、商用SDK、外包开发模块）是当前产品安全的重灾区，也是CRA监管的重点。【法规条文】Article13(5)制造商应对产品中使用的第三方组件进行尽职调查，确保组件的安全性，并持续跟踪组件的漏洞信息。企业可从以下三个方面落实第三方组件安全管控。（1）供应商准入评估建立第三方组件准入机制，引入新组件前必须进行安全评估；评估内容包括：组件的安全历史、维护活跃度、漏洞响应速度、许可证合规性；对于核心组件，要求供应商提供安全资质证明、SBOM、安全测试报告等材料。（2）开源组件持续监控建立企业级开源组件清单，统一管理所有产品使用的开源组件；接入漏洞情报源，组件曝出漏洞时第一时间收到预警；定期对在用组件进行安全扫描，发现高危漏洞及时推动修复；制定组件淘汰机制，停止维护的、存在重大安全风险的组件及时替换。（3）供应链责任划分在与供应商的合同中明确安全责任条款，要求供应商承担其组件的安全责任；明确漏洞通知时限，供应商发现组件漏洞后需在规定时间内通知下游厂商；对于关键组件，要求供应商提供安全支持承诺，保障漏洞修复响应速度。6.5产品上市前安全确认要求【法规条文】Article13(5)制造商在将产品投放市场前，应确认产品不存在已知的可被利用的高危漏洞。这是CRA对制造商的明确要求，也是产品上市的前置条件：产品上市前必须完成全面的安全测试，修复所有已知高危漏洞；排查所有第三方组件的已知漏洞，存在可利用高危漏洞且未修复的，不得上市；安全确认记录需纳入技术文档，作为合规证明。需要注意的是，"无已知可利用高危漏洞"是时点性要求，即上市时不存在已知的、可被利用的高危漏洞。产品上市后新发现的漏洞，按漏洞管理与安全更新流程处理即可，不溯及上市时的合规性。第7章安全更新与产品支持周期制度安全更新与支持周期是CRA针对"产品上市后无人维护"这一行业痛点提出的核心要求，也是保障产品全生命周期安全的关键制度。7.1支持周期法定义务CRA明确要求制造商为产品提供最低期限的安全支持，确保产品在使用周期内能够持续获得安全更新。【法规条文】Article13(1)(8)制造商应在产品预期使用寿命内，或至少5年内，提供安全更新支持，以较短者为准；若产品预期使用寿命超过5年，则至少提供5年安全支持。对该条款的官方解释如下：第一，最低5年支持期——无论产品预期寿命多长，安全支持期限不得少于5年，从产品最后一批投放市场之日起计算；第二，预期寿命优先——如果产品的预期使用寿命短于5年（例如部分消费电子换代周期为3年），则支持期与预期寿命一致即可；第三，长寿命产品要求——工业设备、网络设备等预期寿命超过5年的产品，至少提供5年安全支持，鼓励提供更长支持周期；第四，仅针对安全更新——该义务仅针对安全更新，功能更新不属于强制要求。欧盟委员会2026年7月指南进一步明确：产品支持周期信息需明确告知用户，在产品包装、说明书、官网均可查询。用户有权在购买前知晓产品的安全支持期限，作为购买决策的参考。7.2安全更新交付要求CRA不仅要求提供安全更新，还对更新的交付机制、及时性、用户体验提出了明确要求。【法规条文】Article13(7)制造商应确保产品具备安全、可靠的更新机制，能够及时交付安全更新。具体要求包括以下方面。（1）安全更新免费原则所有安全更新必须免费向用户提供，不得要求用户付费购买安全补丁。这是强制性要求，企业不得通过订阅制等方式将安全更新转为付费服务。（2）更新发布及时性要求对于高危漏洞，应在合理期限内发布修复更新；对于被主动利用的零日漏洞，需尽快发布临时缓解措施与正式修复补丁；修复更新发布后，需主动推送给用户，不得要求用户主动查询下载。（3）更新机制安全性更新包必须进行数字签名，确保完整性与真实性，防止篡改；更新传输过程必须加密，防止中间人攻击；更新机制本身不得存在安全漏洞，成为攻击入口。（4）用户可控性提供自动更新选项，默认建议开启自动安全更新；允许用户选择更新时间，避免影响正常使用；向用户说明更新的内容与安全影响，保障用户知情权。7.3更新留存期限要求【法规条文】AnnexIPartII(4)安全更新发布后，制造商应至少保留10年，或保留至产品支持期结束后5年，以较长者为准。该要求的目的是保障后续购买产品的用户，以及需要回退、重装系统的用户，能够随时获取历史安全更新。即便产品已经终止支持，历史安全更新仍需继续保留；企业需建立更新归档系统，确保所有历史版本的更新包均可追溯、可下载；更新留存记录需纳入技术文档，供监管机构核查。7.4产品生命周期终止（EOL）管理产品不可能无限期提供支持，当产品到达生命周期终点时，企业需按法定要求履行终止告知义务。（1）提前告知义务制造商决定终止产品安全支持时，需提前向用户告知：建议至少提前6个月发布终止支持公告；公告需明确说明终止支持的具体日期、终止后用户面临的安全风险；向用户提供迁移建议，如推荐替代产品型号。（2）用户知情权保障终止支持信息需在官网显著位置发布，同时通过产品内通知、邮件等方式通知已知用户；对于仍在销售渠道的库存产品，需标注"即将终止支持"的提示信息；终止支持后，不得再宣传产品具备安全更新能力。（3）终止后的最低义务产品终止支持后，企业不再有义务发布新的安全更新，但仍需履行以下义务：保留历史安全更新供用户下载；配合监管机构的事件调查与漏洞查询；若出现影响极其重大的漏洞，监管机构可要求厂商提供额外支持。7.5企业产品路线图调整建议CRA的支持周期要求将直接影响企业的产品研发与运维策略，建议企业从以下方面进行调整。（1）产品规划与支持周期匹配在产品立项阶段即明确产品的预期寿命与安全支持周期，同步规划对应的运维资源；对于长周期产品，选择生命周期长、维护活跃的技术栈与第三方组件，避免中途组件停止维护导致无法提供更新；合理规划产品迭代节奏，避免产品型号过多导致维护成本过高。（2）运维团队配置调整建立专门的产品安全维护团队，负责已上市产品的漏洞响应与安全更新发布；避免"开发完就解散团队"的模式，保留核心维护人员保障产品支持期内的运维能力；对于多代产品并行维护的情况，建立高效的补丁移植机制，降低维护成本。（3）老旧产品退市与迁移策略梳理现有产品清单，对接近支持终点的产品制定退市计划；引导老用户迁移到新型号产品，提供升级优惠政策，降低用户抵触；对于仍有大量用户的老旧产品，可根据实际情况适当延长支持周期，避免用户集中流失。真实案例参考：2024年，德国消费者组织（VZBV）对某知名消费电子品牌发起集体诉讼，理由是该品牌的一款智能电视上市仅18个月就停止固件更新，导致产品存在的多个安全漏洞长期无法修复，用户面临隐私泄露风险。消费者组织认为，智能电视的正常使用寿命远长于18个月，厂商提前停止更新违反了产品安全义务。CRA将5年安全支持明确为法定义务后，此类"短命"产品将直接丧失欧盟市场准入资格。过往"快速迭代、快速抛弃"的产品策略已无法适应新的监管要求，企业必须调整产品研发与运维模型，将长期安全支持纳入产品成本核算。

第三部分合规认证与技术文档本部分聚焦产品上市前的合规认证流程与技术文档体系建设，对应CRA法案2027年12月11日生效的核心准入要求。合格评定与CE标识是产品进入欧盟市场的法定准入凭证，技术文档是证明产品合规的核心证据链，二者共同构成产品端合规的基础框架。第8章合格评定与CE认证合格评定是CRA框架下产品上市的法定前置程序，制造商需通过规定的评定程序证明产品满足基本网络安全要求，方可加贴CE标识并投放欧盟市场。与传统CE指令不同，CRA根据产品风险等级实施分级评定，风险越高的产品对第三方机构介入的要求越严格。8.1合格评定路径与产品分级对应关系CRA设定了与产品风险等级匹配的三类合格评定路径，企业需根据自身产品的分级结果选择对应路径。【法规条文】Article28合格评定程序的选择：1.标准产品的制造商可选择第30条规定的内部生产控制程序（ModuleA）；2.I类重要产品的制造商可选择：(a)基于协调标准的内部生产控制程序（ModuleA）；(b)基于公告机构型式检验的程序（ModuleB）；3.II类关键产品的制造商必须采用基于公告机构型式检验的程序（ModuleB）。结合欧盟委员会2026年7月官方指南，各评定路径的具体要求与适用场景如下。（1）ModuleA：内部生产控制（自我评定）适用产品：全部标准产品；符合协调标准的I类重要产品。核心要求：企业自行完成产品安全设计、测试与验证，编制完整技术文档，签署欧盟符合性声明，无需第三方机构介入。责任主体：制造商对产品合规性承担全部责任。落地要点：自我评定不等于无需合规，技术文档必须完整详实，市场抽查时若无法提供有效证明材料，将直接判定不合规。（2）ModuleB：公告机构型式检验适用产品：无协调标准覆盖的I类重要产品；全部II类关键产品。核心要求：由欧盟公告机构（NotifiedBody）对产品原型进行型式检验，确认产品符合基本安全要求，出具型式检验证书。后续要求：取得证书后，企业自行负责批量生产的一致性，确保量产产品与检验原型一致。监管强度：公告机构可对生产过程进行不定期监督抽查。（3）特殊情形：多指令叠加适用多数智能硬件产品同时受多个CE指令管辖，例如带无线功能的智能家居设备需同时符合《无线电设备指令》（RED2014/53/EU）与CRA。对此欧盟官方指南明确：产品只需加贴一次CE标识，即视为同时满足所有适用指令的要求；合格评定可分别开展，也可委托同一家具备多资质的公告机构合并开展；技术文档可整合编制，统一存放，供不同指令的监管调阅。真实案例参考：2025年，欧盟市场监管机构在针对消费电子的联合抽查中，查获某中国品牌智能路由器未按RED指令要求完成合格评定即加贴CE标识。该产品被责令全欧盟范围内下架，制造商被处以约120万欧元罚款，同时被列入欧盟市场监管黑名单，后续所有产品入境均面临优先抽检。CRA实施后，网络路由器属于I类重要产品，若未采用对应合格评定程序即上市，处罚力度将远高于RED指令下的处罚，除罚款外还可能触发全品类产品禁入。合格评定是产品入市的法定门槛，企业切勿抱有"先上市后补证"的侥幸心理。8.2协调标准与符合性推定协调标准是欧盟层面发布的、与法规要求对应的技术标准，采用协调标准的产品可直接推定符合法规的基本安全要求。（1）协调标准的法律效力【法规条文】Article26协调标准的符合性推定：1.产品符合欧盟官方公报上公布的协调标准的，应推定其符合本条例规定的对应基本网络安全要求。采用协调标准是最高效的合规路径，可大幅降低技术文档编制难度与市场抽查风险；未采用协调标准的产品，企业需自行提供充分的技术证据，证明产品满足所有基本安全要求，合规成本与风险更高。（2）协调标准制定进展（截至2026年7月）截至2026年7月31日，CRA对应的协调标准仍在制定过程中，具体进展如下：欧盟标准化委员会（CEN/CENELEC）已联合ENISA启动首批协调标准的编制工作，涵盖通用安全要求、物联网设备安全、软件产品安全等方向；首批协调标准预计于2027年上半年正式发布并列入欧盟官方公报，具备法律效力；2027年12月11日CRA全面实施时，将有至少15项核心协调标准可用，覆盖80%以上的常见消费级产品。（3）过渡期可参考的技术标准在正式协调标准发布前，企业可参考以下成熟国际标准开展安全建设，这些标准是后续协调标准的核心参考依据：ETSIEN303645——消费级物联网设备网络安全基线标准，是CRA消费类产品要求的主要参考来源；ISO/IEC15408（CC标准）——信息技术安全评估通用准则，适用于高安全等级产品；ISO/IEC27001——信息安全管理体系标准，适用于企业层面的安全管理体系建设；BSITR03183——德国发布的软件物料清单技术规范，是SBOM要求的核心参考。欧盟官方指南明确，企业基于上述标准开展的安全建设与测试，在协调标准发布后可通过差异比对快速转换，不会造成重复投入。8.3公告机构选择与管理对于需要ModuleB评定的产品，选择合规且合适的公告机构是合规工作的重要环节。（1）公告机构资质查询公告机构的资质信息统一在欧盟NANDO数据库中公示，企业可通过该数据库验证机构资质：核实机构是否具备CRA法规下的公告资质；核实机构的资质范围是否覆盖自身产品类别；核实机构资质是否在有效期内，是否存在被暂停、撤销的记录。最新进展：截至2026年7月，欧盟各成员国已启动CRA公告机构的申报与评审工作，首批具备资质的公告机构预计于2027年第一季度正式获批并录入NANDO数据库。企业可提前对接意向机构，开展预评估，待资质获批后快速完成正式评定。（2）公告机构委托流程1.前期沟通：向机构提供产品资料，确认评定范围、周期与费用；2.提交资料：提交完整的技术文档与产品原型，供机构审核测试；3.型式检验：机构对产品开展测试与文档审核，提出整改意见；4.整改验证：企业根据意见整改，机构复核确认；5.颁发证书：审核通过后，机构颁发型式检验证书，证书有效期通常为5年。（3）持续监督与管理产品发生重大设计变更、软件版本重大升级时，需重新提交公告机构评估；配合公告机构的年度监督审核，确保量产产品与型式检验原型一致；公告机构资质发生变动时，及时更换机构并重新评定。8.4CE标识加贴规则CE标识是产品符合欧盟所有适用指令的视觉证明，加贴有严格的法定规范。【法规条文】Article34CE标识：1.制造商确认产品符合所有适用要求后，应在产品上加贴CE标识；2.CE标识应清晰、可辨认、持久地贴附在产品或其包装上；3.禁止在产品上加贴可能误导第三方认为产品符合本条例的其他标识。具体加贴要求：样式要求——CE标识必须使用官方规定的标准样式，按比例缩放，高度不得小于5mm；位置要求——优先贴附在产品本体上，产品体积过小的可贴在包装与随附文档上；时机要求——必须在产品投放欧盟市场前完成加贴，不得在销售环节临时补加；禁止情形——不得在未完成合格评定的产品上加贴CE标识，不得变造、冒用CE标识。需要特别注意：CRA属于CE立法框架下的法规，产品加贴的CE标识同时覆盖所有适用的CE指令，无需为CRA单独加贴标识。8.5欧盟符合性声明（EUDoC）欧盟符合性声明是制造商签署的、声明产品符合所有适用法规要求的法律文件，是CE认证流程的必备文件。【法规条文】AnnexV欧盟符合性声明格式：符合性声明应包含以下内容：1.产品标识：产品名称、型号、版本号、唯一识别信息；2.制造商信息：名称、注册地址、联系人；3.授权代表信息（如有）：名称、地址；4.适用法规声明：声明产品符合《网络弹性法案》(EU)2024/2847及其他适用的欧盟法规；5.引用的协调标准或其他技术规范清单；6.公告机构信息（如适用）：机构名称、编号、型式检验证书编号；7.签署信息：签署人姓名、职务、签字、日期、签署地点。落地管理要求：符合性声明需随产品一同提供给用户，或在官网公开供用户查询；声明需使用产品销售国的官方语言，至少包含英文版本；声明需与技术文档一同保存，保存期限不少于产品最后一批上市后10年；产品设计、版本发生重大变更时，需更新符合性声明。第9章技术文档体系建设技术文档是证明产品符合CRA要求的核心证据链，也是市场监管抽查的核心核查对象。完整、规范的技术文档不仅是合规要求，更是企业应对监管检查、降低执法风险的核心保障。9.1技术文档法定要求【法规条文】Article31技术文档：1.制造商应编制技术文档，用以证明产品符合本条例的基本网络安全要求；2.技术文档应包含附件VII规定的全部内容；3.技术文档应自产品最后一批投放市场之日起至少保存10年；4.市场监管机构提出要求时，制造商应在合理期限内提供技术文档供核查。【法规条文】AnnexVII技术文档内容清单：技术文档应包含足以评估产品是否符合基本网络安全要求的所有相关信息，包括产品设计、开发、生产、运维各阶段的安全说明。欧盟委员会2026年7月指南进一步明确了技术文档的核心原则：可追溯性——文档需清晰展现产品安全要求从设计到实现的完整落地路径，每个安全要求都有对应的实现证据与测试证据；充分性——文档内容需足以让第三方专业人员判断产品是否满足法规要求，无需依赖企业的口头解释；时效性——文档需随产品版本同步更新，确保与当前在售产品版本一致。9.2技术文档核心构成结合AnnexVII要求与监管实践，一份完整的CRA技术文档应包含以下核心模块。（1）产品描述与规格说明产品基本信息：名称、型号、版本、硬件配置、软件版本、预期用途、适用用户群体；产品功能架构：系统架构图、软硬件模块划分、网络拓扑、数据流向说明；产品分级说明：产品分级判定依据，对应合格评定路径说明。（2）网络安全风险评估报告风险评估方法论说明；威胁建模分析：识别产品面临的主要威胁、攻击路径、攻击面；风险清单与分级：每条风险的影响范围、严重程度、发生概率、风险等级；风险处置方案：针对每条风险采取的安全措施、残余风险接受说明。（3）安全设计与实现说明安全架构设计说明：对应安全设计各项原则的落地实现方式；各安全功能模块详细说明：身份认证、访问控制、数据加密、输入校验、完整性保护等；安全编码规范落实说明：采用的编码标准、代码审核机制、安全测试情况；默认安全配置说明：出厂默认配置清单，对应默认安全要求的落地情况。（4）测试验证报告测试方案：测试范围、测试方法、测试环境、测试工具；功能安全测试报告：各项安全功能的功能测试结果；渗透测试报告：第三方或内部渗透测试的过程、发现的问题、整改验证结果；第三方组件安全测试报告：组件漏洞扫描结果、修复情况；合规性测试报告：对照AnnexI基本要求逐项验证的测试结果。（5）软件物料清单（SBOM）产品完整SBOM文件，采用标准机器可读格式；SBOM编制说明：编制范围、采用标准、工具说明、更新机制；第三方组件尽职调查记录：供应商评估记录、组件安全审核记录。（6）漏洞管理与事件响应说明企业漏洞管理流程制度；漏洞接收渠道与处理流程；安全事件响应与上报流程；历史漏洞处置记录（如有）。（7）安全更新与支持政策产品安全支持周期承诺；安全更新机制说明：更新发布流程、更新校验机制、更新推送方式；产品生命周期终止管理规则；用户告知机制说明。（8）用户文档与安全信息用户说明书中安全相关章节内容；向用户公开的安全支持政策、更新政策；产品包装与宣传材料中的安全信息说明。9.3技术文档编制要点（1）可追溯性建设建立"法规要求-设计实现-测试验证"的三级追溯矩阵：第一级列出AnnexI的每一项基本要求；第二级对应说明产品中哪项设计、哪个模块实现了该要求；第三级对应哪份测试报告、哪个测试用例验证了该要求的有效性。追溯矩阵是监管审核时的核心索引，可大幅提升审核效率，降低沟通成本。（2）版本管理与更新机制技术文档实行版本号管理，每次更新记录变更内容、变更时间、变更责任人；产品软件版本迭代时，同步更新对应文档内容，确保文档与产品版本一一对应；建立文档变更审批流程，确保文档变更的准确性与合规性。（3）监管调阅响应准备提前准备技术文档的调阅版本，区分内部完整版与监管提供版，保护商业秘密；制定监管响应预案，明确接收到调阅要求后的对接人、响应流程、提供时限；对于多语言要求，提前准备英文版本文档，必要时补充销售国语言版本。9.4多产品系列的文档复用策略对于拥有多型号、多SKU的企业，逐型号编制完整技术文档成本极高，可采用以下策略提升效率。（1）产品族系化管理将硬件平台、软件架构相同的产品归为一个产品族，编制通用技术文档：通用部分——共享的安全架构、核心软件模块、通用安全功能等，全族系共用；差异部分——不同型号的硬件差异、功能差异、配置差异，单独编制差异说明文档。（2）模块化文档组件将技术文档拆分为多个独立模块，如风险评估模块、SB