背景
2024年12月10日，欧盟《网络弹性法案》正式生效。
2025年4月3日，欧盟三大标准化组织已正式启动《网络弹性法案》配套标准的制定工作。
2025年4月18日，欧盟委员会针对重要与关键产品的最终技术描述文件征求了122份意见。
2025年8月1日，无线电指令（RED）网络安全补充授权法案（EU）2022/30正式实施。
2025年12月3日，欧盟委员会针对《网络弹性法案》发布了系列常见问题解答（FAQ）。
2026年3月3日，欧盟委员会发布了《网络弹性法案》（CRA）应用指南的2026年草案来进行公众意见征集[Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)]，征求意见期已于4月13日结束。该草案旨在协助经济运营商，尤其是中小型企业(SMEs)，更好地理解和应用这项即将全面实施的法规。
CRA是欧盟首部针对“含数字元素产品”的横向网络安全法规，覆盖范围极广，具体从路由器、智能摄像头等硬件，到手机App、云服务等软件，甚至包括独立销售的芯片、主板等硬件组件。凡是在欧盟市场销售的相关产品，均须满足该法案规定的强制性安全要求。
正因为覆盖范围如此广泛，CRA在具体技术场景下如何适用，尤其是涉及免费和开源软件（Free and open-source software，FOSS）、远程数据处理（Remote data processing solutions，RDPS）、实质性变更（Substantial changes）以及第三方组件（Third-party components）等关键议题等时，亟需权威解释。此次发布的草案正是针对这些关键议题，提供了目前最详细的官方指引。
本文将深入解读这份最新指南草案，梳理其对中国企业对欧出口业务可能带来的合规挑战，特别是涉及智能硬件、软件产品、物联网设备以及集成开源组件的制造商。
开源软件（FOSS）的使用边界
草案明确，使用开源软件本身不自动触发CRA义务，但如果企业通过开源软件收费、变现或强制收集用户数据，则可能被认定为“商业活动”，须承担全部合规责任。此外，集成开源组件的制造商需对最终产品全面负责，并进行尽职调查（Due diligence），具体规则要求是：
开源软件本身不自动触发CRA义务。只要软件是免费、公开、不变现的，就不视为“商业活动”，不受CRA管辖。
但如果企业通过开源软件变现，性质就变了。以下行为会被认定为“商业活动”，使该版本成为CRA下的“产品”：直接收费（如付费下载、订阅）；通过软件推广付费服务（如免费App内购云存储）；强制收集用户数据用于广告等非安全目的；捐赠事实上等于收费（如不捐款就无法下载）。
同一软件可以有两个“身份”：免费社区版（不受CRA管辖）+ 付费企业版（受CRA管辖），企业需分别对待。
集成开源组件的制造商：不对组件本身的合规负责，但需对最终产品全面负责，并进行尽职调查，以验证组件安全性。
软件更新可能触发“实质性变更”
CRA规定，某些更新可能被认定为“实质性变更”，触发重新认证义务，带来额外成本和时间延误，这可能对普遍采用敏捷开发、快速迭代模式，频繁发布软件更新的中国企业带来影响。指南草案的具体规则要求
“实质性变更”的定义（满足其一即可）：更新影响产品对基本安全要求的符合性（如移除了加密功能）；或，更新改变了产品的预期用途（如从“只读监控”变成“远程控制”）。
安全更新通常不算：纯漏洞修复、安全补丁，只要不改变用途、不引入新风险，不构成实质性变更。
判断清单（四个问题）：是否引入新的攻击入口（如新增API、蓝牙、云依赖）？是否启用新的攻击方式（如新增远程配置功能）？是否让已知攻击更容易得手（如降低攻击门槛）？是否让已知攻击的后果更严重（如影响范围扩大）？
后果：一旦构成实质性变更，修改后的产品视为新产品，须重新进行合规评估、更新技术文档、重新出具符合性声明（Declaration of conformity，DOC）。
供应链管理与第三方组件尽职调查
CRA将供应链安全责任明确落在最终产品制造商身上，不能转嫁给供应商。具体要求包括：
尽职调查义务：制造商必须验证集成的第三方组件不会破坏产品的安全性。
具体做法：确定产品需要组件具备哪些安全能力（如加密、安全更新、安全通信）；从组件供应商处获取技术规格、安全文档、合规证明（如CE标志、认证证书）；必要时进行功能测试。
向上游报告漏洞：如果在自己产品中发现集成组件的漏洞，必须报告给该组件的维护者，并分享修复方案。
注意：如果组件是开源的且没有维护者，或企业自己分叉（fork）了组件不再依赖原维护者，则不需要报告。
产品分类决定合规路径
CRA根据产品的“核心功能”（Core functionality）将其分为默认类、重要I类、重要II类、关键类，不同类别适用不同的合规评估程序。分类错误可能导致企业走了错误的合规通道，造成资源浪费或合规失效。根据指南草案，该要求的具体规则是：
分类依据：产品的核心功能（“本职工作”），而不是集成的组件功能。
合规评估要求：默认类：可自评（内部管控）；重要I类：采用协调标准可自评，否则需第三方；重要II类：必须第三方认证（开源产品例外）；关键类：必须第三方认证。
禁止操纵分类：不能故意夸大或弱化某些功能来逃避更严格的合规程序。宣传材料、说明书、技术文档必须一致。
远程数据处理（RDPS）的合规边界
大量中国企业的产品依赖云端功能（如App配网、数据同步、远程控制）。CRA将制造商自研的远程数据处理软件视为产品的一部分，需要纳入合规评估，具体规则包括：
RDPS的判断三要素（必须全部满足）：数据处理在远端（云端、边缘、厂商服务器）；缺少它产品无法执行某功能（功能不限于核心功能，也包括配置、更新、登录等）；软件由制造商设计或负责（自研或定制开发）。
三种云模型的处理：基础设施即服务（Infrastructure as a Service，IaaS）和平台即服务（Platform as a Service，PaaS）上自研的应用：自研部分算作RDPS，需要纳入合规范围；云平台本身则作为第三方组件进行尽职调查；软件即服务（Software as a Service，SaaS）：不构成RDPS，仅作为第三方组件进行尽职调查。
运营方不影响责任：即使RDPS由第三方云服务商运营，制造商仍对RDPS的安全性负全责。
对企业的建议
面对即将全面落地的CRA，建议对欧出口的中国企业从多个方面着手准备，包括但不限于：
开展差距分析。对照CRA要求评估现有产品是否存在合规缺口，明确需要优先解决的风险点。
建立开源软件管理台账。 梳理产品中使用的所有开源组件，记录其名称、版本、许可证及变现状态，区分“仅集成”的组件（需做尽职调查）和“自己发布并变现”的组件（需完全合规）。
建立软件更新分类机制。在首次合规评估时尽可能预见未来可能添加的功能，并预先纳入风险评估文档。每次更新前对照四个判断问题核查是否构成实质性变更。
完善供应链安全流程。 建立供应商安全评估清单，要求关键组件供应商提供安全文档和合规证明，并在采购合同中写入安全保证、漏洞通报等条款。
确认产品分类并规划合规路径。 对照CRA附件判断自身产品的核心功能归属。如属于重要II类或关键产品，需提前联系欧盟通告机构（Notified bodies）了解认证排期。
梳理云端依赖。 区分自研的远程数据处理（需纳入技术文档和风险评估）与采购的SaaS服务（作为第三方组件做尽职调查）。
持续关注法规动态。 本次发布的为指南草案，后续可能进一步修订，建议企业根据最终版本调整合规策略。
