4. 适用范围与排除
欧盟《网络弹性法案》（Cyber Resilience Act, CRA）的管辖边界，是企业在合规启动阶段面临的首要问题。判断一款产品是否落入CRA的“数字元素产品”范畴，不仅决定了后续合规工作的投入规模，也直接影响产品在欧盟市场的准入节奏。本章将围绕CRA第2条（Scope）及附件I、附件II、附件III，系统拆解管辖范围、豁免清单与边界判定逻辑，并结合典型产品形态进行案例拆解。
4.1 核心原理：CRA的“数字元素”定义与管辖逻辑
CRA的管辖起点并非产品类别，而是“数字元素”（digital elements）的存在。根据CRA第2条第1款，法规适用于“含有数字元素的产品”（products with digital elements），即任何软件或硬件产品及其远程数据处理解决方案（包括单独投放市场的软件组件）。这一宽泛定义意味着，只要产品中嵌入了可编程逻辑（无论是MCU固件、Linux系统还是纯软件App），原则上都进入CRA的视野。
理解这一逻辑的关键在于：CRA采取的是“全链条覆盖+分类分级”的监管思路。全链条覆盖指从设计、开发、生产到运维的整个生命周期；分类分级则根据产品的网络安全风险等级，将产品划分为默认类别（Default）、重要类别（Important，I类和II类）以及关键类别（Critical），不同类别对应不同的合格评定程序（自我声明、第三方评估或欧盟网络安全局ENISA介入）。
值得注意的是，CRA的管辖对象是“投放市场的产品”，而非企业内部使用的开发工具或测试环境。如果一款软件仅用于内部研发，并未商业化提供给欧盟用户，则不构成“投放市场”行为，不属于CRA管辖。但一旦通过任何渠道（包括免费下载、SaaS订阅、预装分发）提供给欧盟境内的用户，即触发合规义务。
4.2 豁免与排除：CRA第2条及附件逐项解析
CRA的豁免条款主要分为两类：一类是“其他法规已覆盖”的领域豁免，另一类是“低风险或开发阶段”的排除。下表梳理了主要豁免/排除类别及其判定要点：
| 豁免/排除类别 | 法规依据 | 判定要点 | 典型产品示例 |
|---|---|---|---|
| 医疗器械（含体外诊断） | CRA第2条第2款(a) | 已获MDR/IVDR认证或符合其要求；若仅为MDR/IVDR的组件且独立投放市场，仍受CRA管辖 | 智能胰岛素泵、联网心电监护仪 |
| 航空产品 | CRA第2条第2款(b) | 已获EASA适航认证或为适航产品的部件 | 飞机航电系统、机载Wi-Fi设备 |
| 汽车及拖车 | CRA第2条第2款(c) | 已获EU 2018/858型式认证；但售后加装的联网设备不豁免 | 车载信息娱乐系统（原厂）、T-Box |
| 纯开源软件（非商业） | CRA第2条第3款 | 由非营利组织开发，且不构成商业活动；若开源软件被商业化集成，则集成方承担义务 | Apache HTTP Server、Linux内核 |
| 开发阶段产品 | CRA第2条第4款 | 未投放市场的原型、测试版本、内部开发工具 | 内部CI/CD测试环境、未发布的Beta版 |
| 纯数据文件/内容 | CRA第2条第5款 | 不包含可执行代码的文档、电子书、音视频文件 | PDF手册、MP4教程、CSV数据集 |
需要特别强调的是，豁免并非“一刀切”。以医疗器械为例，如果一款智能血压计同时具备通用计算功能（如安装第三方App），且该功能并非医疗器械用途所必需，则通用计算部分可能仍需满足CRA要求。这种“混合产品”的边界判定，是实务中最常见的争议点。
4.3 判断方法：五步定位法
针对具体产品，建议采用以下五步定位法进行管辖判定：
- 步骤一：识别数字元素——拆解产品BOM和软件物料清单（SBOM），确认是否存在MCU、MPU、FPGA、SoC或任何可执行代码（包括固件、驱动、应用层软件）。
- 步骤二：确认投放市场行为——判断产品是否通过销售、免费分发、预装、SaaS等方式提供给欧盟用户。内部使用、科研样品、展会演示不属于投放市场。
- 步骤三：匹配豁免清单——对照CRA第2条第2款和第3款，逐项检查是否属于已豁免领域。注意检查豁免是否附带条件（如“已获型式认证”）。
- 步骤四：识别远程数据处理——如果产品配套云服务或App，需判断该服务是否构成产品的“远程数据处理解决方案”。若云服务独立于硬件销售，则云服务本身可能单独受CRA管辖。
- 步骤五：确定风险类别——根据附件III（重要类别）和附件IV（关键类别）的清单，对照产品功能描述，确定所属类别。若不在清单中，则归为默认类别。
4.4 边界案例分析：三个典型场景的深度拆解
以下通过三个真实场景，展示边界判定的完整分析过程。
案例一：智能家居网关（Smart Home Gateway）
背景与约束：某深圳厂商计划向欧盟推出一款智能家居网关，支持Zigbee、Wi-Fi和以太网接入，内置Linux系统，可运行第三方插件。该网关同时提供配套云平台服务，用于设备管理和数据存储。
初始判断：产品含数字元素（Linux系统+网络协议栈），投放市场，不属于任何豁免类别。因此受CRA管辖。
关键分析：
- 网关本身属于“重要类别I类”吗？对照附件III，智能家居网关属于“智能家居管理中心”，被列为重要类别I类（需进行第三方合格评定）。
- 云平台是否单独受CRA管辖？云平台作为远程数据处理解决方案，若独立于网关销售（如按年订阅），则云平台本身也需满足CRA要求。但若云平台仅作为网关的附属功能，可视为产品整体的一部分。
- 第三方插件如何处理？CRA要求制造商对“可预见的误用”负责。若网关允许安装第三方插件，制造商需在技术文档中明确安全边界，并对核心系统（操作系统、通信栈）负责，第三方插件开发者则需自行满足CRA（若其插件独立投放市场）。
操作步骤与结果：该厂商最终将网关和云平台作为整体进行CRA合规，选择第三方评估机构进行合格评定，并在技术文档中明确了插件管理策略。合规成本约占总研发预算的8%，产品上市周期延长约3个月。
复盘经验：智能家居网关是CRA重点监管对象，切勿因“网关只是连接设备”而低估其风险等级。建议在立项阶段就引入CRA合规设计，避免后期整改。
案例二：开源工业协议栈（Open-Source Protocol Stack）
背景与约束：欧洲某非营利开源社区维护一个Modbus TCP协议栈，供工业设备制造商免费使用。该协议栈以LGPL许可证发布，社区不收取任何费用，也不提供商业支持。
初始判断：该协议栈属于开源软件，且由非营利组织开发，符合CRA第2条第3款的排除条件。
关键分析：
- 但若某设备制造商将该协议栈集成到其商用PLC产品中，则该PLC产品整体受CRA管辖。制造商需对协议栈的安全性负责，包括漏洞修补和更新支持。
- 开源社区本身不承担CRA义务，但若社区提供“商业版本”或“付费支持”，则可能丧失排除资格。
操作步骤与结果：该社区继续以非营利模式运营，但发布了安全公告模板和漏洞报告流程，帮助集成商履行CRA义务。集成商则需在SBOM中明确记录该协议栈版本，并建立漏洞跟踪机制。
复盘经验：开源不等于免责。集成商必须对上游开源组件的安全性负责，建议建立“开源组件安全基线”制度。
案例三：医疗级智能手环（Medical-Grade Smart Band）
背景与约束：某德国公司推出一款智能手环，可测量心率、血氧和ECG，已获得MDR Class IIa认证。手环同时具备通用通知功能（接收手机消息）。
初始判断：手环属于医疗器械，已获MDR认证，符合CRA豁免条件。
关键分析：
- 但通用通知功能是否属于“非医疗用途”？若该功能独立于医疗功能运行，且用户可单独关闭，则通用通知部分可能不受MDR覆盖，需单独评估CRA适用性。
- 若手环的固件更新同时影响医疗功能和通用功能，则更新机制需同时满足MDR和CRA的要求。
操作步骤与结果：该公司将手环拆分为“医疗模式”和“通用模式”，在技术文档中明确两种模式的安全责任边界。医疗模式遵循MDR，通用模式遵循CRA默认类别要求（自我声明）。
复盘经验：混合产品（医疗+通用）的边界划分是合规难点，建议在早期设计阶段就进行功能隔离，避免后期合规冲突。
4.5 常见误区与总结复盘
在CRA管辖判定中，企业常陷入以下误区：
- 误区一：认为“硬件产品”不需要关注CRA。实际上，只要硬件内含可编程逻辑（如MCU固件），就属于数字元素产品。纯机械产品（如手动扳手）才真正豁免。
- 误区二：混淆“豁免”与“排除”。豁免（Exempt）指其他法规已覆盖，排除（Excluded）指CRA明确不适用。两者的法律后果不同，但都需要在技术文档中记录判定依据。
- 误区三：忽视“远程数据处理解决方案”。很多企业只关注硬件本身，忽略了配套的云服务或App。若云服务独立投放市场，则需单独满足CRA。
- 误区四：认为“开源软件完全免责”。开源软件本身可能被排除，但集成开源软件的产品制造商仍需承担全部CRA义务。
总结：CRA的管辖边界并非一成不变，而是随着产品功能、商业模式和法规更新动态调整。企业应建立“数字元素识别→投放市场确认→豁免匹配→风险分类”的常态化评估机制，并将合规判断嵌入产品生命周期管理流程。对于边界模糊的产品，建议咨询专业法律顾问或向欧盟成员国主管当局申请非正式指导。