CRA《网络弹性法案》附件 I：产品网络安全要求解读
CRA 对“具有数字元素的产品”提出了基本网络安全要求，其中第一部分重点关注产品属性本身，也就是产品在设计、开发、制造和投放市场时，应该具备哪些安全特性。
这部分要求对智能硬件、IoT 设备、工业控制产品、网络设备、嵌入式软件、企业软件平台、车载终端、远程管理系统等出海欧盟产品影响非常直接。企业不能只在产品上市前做一次测试，而需要从产品设计阶段就把安全要求纳入研发流程。
一、CRA 的核心逻辑：产品要基于风险进行安全设计
CRA 首先强调，具有数字元素的产品应当基于风险，以确保适当网络安全水平的方式进行设计、开发和制造。
这句话看起来比较原则，但对企业来说非常关键。
它意味着，CRA 不要求所有产品都采用完全相同的安全措施，而是要求企业结合产品的预期用途、使用场景、连接能力、数据类型、用户群体和潜在影响，进行网络安全风险评估，并基于风险结果落实相应安全要求。
例如，一个普通蓝牙小设备和一套工业远程控制系统，面对的威胁和影响程度完全不同；一款本地运行的软件工具和一个承载用户账户、远程访问、云端同步的平台，安全要求也不可能完全一样。
所以，企业准备 CRA 合规时，第一步不是直接套模板，而是先做产品风险评估。只有明确风险，后续的身份认证、访问控制、加密、更新机制、漏洞管理、数据删除等措施才有依据。
二、产品投放市场时，不应存在已知可利用漏洞
CRA 要求产品在投放市场时，应以没有已知可利用漏洞的方式上市。
这对很多企业是一个很现实的挑战。
过去，一些企业产品上线时，可能只完成了功能测试和基础稳定性测试，安全漏洞则依赖客户反馈或后期版本修复。但 CRA 下，企业需要在产品上市前主动识别和处理已知漏洞。
这意味着企业至少需要建立几个基础能力：
对自研代码进行安全测试；
对第三方组件进行漏洞扫描；
对开源库和依赖包进行版本管理；
对已知 CVE 进行排查；
对高风险漏洞完成修复和复测；
对无法立即修复的问题形成风险说明和缓解措施。
尤其是大量使用开源组件的软件产品、嵌入式设备和 IoT 产品，更不能忽视第三方组件风险。产品里用了哪些库、版本是什么、是否存在公开漏洞、是否已经修复，都需要形成可追溯记录。
三、默认安全配置将成为产品合规重点
CRA 要求产品应以默认安全配置投放市场，除非制造商和业务用户就定制产品另有约定。同时，产品应允许用户将其重置到原始状态。
默认安全配置至少应包括：
首次使用时强制修改默认密码；
默认关闭不必要服务和端口；
默认启用关键安全功能；
默认采用合理的权限控制；
默认保护管理接口；
默认启用必要日志记录；
默认提供安全更新能力。
四、安全更新机制必须可用、可信、可操作
CRA 对漏洞修复和安全更新提出了非常明确的要求。产品应确保漏洞可以通过安全更新得到解决，在适用情况下，应默认启用自动安全更新，并允许用户清晰、便捷地选择退出，也应通知用户可用更新，并允许在一定条件下暂时推迟更新。
这说明，欧盟并不只关注产品上市时是否安全，还关注产品上市后的持续维护能力。
对企业来说，安全更新机制需要重点考虑：
更新包是否经过签名验证；
更新传输过程是否安全；
用户是否能清楚知道更新内容；
是否支持自动更新；
是否允许业务用户合理控制更新时间；
更新失败后是否支持回滚；
是否有补丁发布和版本记录；
安全更新支持周期是否明确。
对于工业设备、医疗设备、车载设备等不能随意自动更新的产品，企业更需要设计合理机制，既要保证漏洞可修复，也要避免自动更新影响业务连续性。
五、身份认证和访问控制是 CRA 的基础要求
CRA 要求产品通过适当控制机制防止未经授权的访问，包括身份验证、身份或访问管理系统，并报告可能的未经授权访问。
这对网络设备、管理平台、IoT 设备、工业控制设备、SaaS 系统、远程运维工具影响非常明显。
企业需要重点检查：
是否存在默认账号；
是否支持强密码策略；
是否支持多因素认证；
是否有管理员和普通用户权限区分；
是否支持最小权限原则；
是否记录登录失败、异常访问和权限变更；
是否能发现并提示可能的未授权访问。
很多产品的风险并不是核心功能不安全，而是管理入口保护不足。例如远程管理接口暴露、默认账号未修改、权限设计过粗、普通用户可访问管理员功能等。这些问题在 CRA 合规中都需要重点整改。
六、数据机密性和完整性都要被保护
CRA 对数据保护提出了两方面要求：一是保护数据机密性，二是保护数据完整性。
机密性关注的是数据不能被未授权访问或泄露。对于存储、传输或处理的个人数据和其他数据，企业应采用先进机制进行保护，例如对传输中的数据和静态数据进行加密。
完整性关注的是数据、命令、程序和配置不能被未经授权地篡改或操纵，并且在发生损坏时应能报告。
这意味着，企业不能只考虑“数据是否能传过去”，还要考虑：
传输是否加密；
存储是否加密；
密钥如何管理；
配置文件是否防篡改；
固件或软件是否有完整性校验；
命令下发是否有认证和校验；
日志和关键数据是否能发现异常修改。
对于工业控制、远程运维、车载终端等产品，命令和配置完整性尤其重要。因为一旦控制命令被篡改，可能直接影响设备运行状态。
七、数据最小化：只处理必要数据
CRA 要求产品仅处理与预期用途相关且适当、相关、必要的数据，也就是数据最小化。
一些产品为了后续分析、运营或功能扩展，会尽可能多地采集设备信息、用户行为、日志、位置信息、运行状态等。但在 CRA 逻辑下，企业需要能够解释：为什么要采集这些数据？这些数据是否与产品预期用途相关？是否有必要长期保存？是否可以匿名化或减少采集范围？
数据最小化不仅关系到 CRA，也会与 GDPR 等欧盟数据保护要求产生关联。
企业应在产品设计阶段就明确数据清单，包括采集哪些数据、用途是什么、保存多久、传输到哪里、谁可以访问、用户能否删除。
八、产品要保护基本功能可用性，包括事件发生后恢复能力
CRA 要求产品保护基本和基础功能的可用性，包括事件发生后仍能恢复，并具备针对拒绝服务攻击的韧性和缓解措施。
这说明，CRA 中的网络安全不只是防止入侵，也包括产品能否持续稳定提供关键功能。
对于企业来说，需要关注：
是否存在单点故障；
异常流量是否会导致服务不可用；
关键功能是否有降级机制；
日志和告警是否能支持事件排查；
系统崩溃后是否能恢复；
是否具备备份、恢复或重置机制；
是否有拒绝服务攻击缓解措施。
对于网关、云平台、工业控制设备、远程管理系统等产品，可用性要求非常重要。因为这些产品一旦失效，可能影响下游业务系统、生产系统或客户网络。
九、产品不能对其他设备和网络造成负面影响
CRA 还要求产品应最小化其自身或连接设备对其他设备或网络服务可用性的负面影响。
这个要求背后关注的是供应链和生态安全。
一个产品如果被攻击后成为跳板，或者因为设计缺陷产生异常流量，影响其他设备和网络，就不仅是产品自身问题，还可能扩大为系统性风险。
因此，企业需要考虑：
产品是否会异常占用网络资源；
被攻击后是否可能参与横向传播；
是否存在默认开放服务被滥用的风险；
异常状态下是否会影响连接设备；
是否限制不必要的网络访问；
是否有流量控制和异常检测机制。
对于 IoT 设备、网关、路由器、边缘设备和工业网络设备，这一要求尤其关键。
十、攻击面最小化：外部接口不能随意开放
CRA 要求产品应在设计、开发和制造时限制攻击面，包括外部接口。
攻击面越大，潜在风险越高。很多安全事件都源于不必要的接口暴露、调试端口未关闭、默认服务未禁用、API 权限不足、远程管理入口缺乏保护。
企业应检查：
是否关闭不必要端口；
是否移除测试账号和调试接口；
API 是否有认证和权限控制；
管理后台是否限制访问；
默认服务是否最小化；
通信接口是否有安全校验；
硬件接口是否存在被滥用风险。
攻击面最小化并不是后期扫描发现问题再修，而应成为产品架构和版本发布前的固定检查项。
十一、产品应具备利用缓解机制，降低事件影响
CRA 要求产品使用适当的利用缓解机制和技术，减少安全事件影响。
这意味着，即使产品出现漏洞，也应通过安全设计降低漏洞被利用后的影响范围。
常见措施包括：
权限隔离；
进程隔离；
内存保护；
沙箱机制；
输入校验；
异常处理；
最小权限运行；
安全启动；
代码签名；
防回滚机制。
对于软件产品和嵌入式设备来说，这部分要求需要研发团队深入参与。它不是简单采购工具就能解决，而要落实到产品架构、代码实现和运行环境配置中。
十二、日志记录和安全监控要能提供安全相关信息
CRA 要求产品通过记录和监控相关内部活动提供安全相关信息，包括对数据、服务或功能的访问或修改，并为用户提供选择退出机制。
这说明，产品需要具备一定可观测性。
当发生安全事件时，用户和制造商需要知道发生了什么、什么时候发生、涉及哪些账户、哪些数据被访问、哪些配置被修改。
企业需要重点考虑：
是否记录登录和退出；
是否记录权限变更；
是否记录配置修改；
是否记录关键数据访问；
是否记录安全更新；
是否记录异常行为；
日志是否防篡改；
用户是否可以查看或导出日志。
需要注意的是，日志记录也要平衡数据保护要求，不能因为记录日志而过度采集个人数据。
十三、用户应能安全、轻松、永久删除数据和设置
CRA 要求制造商为用户提供安全且轻松地永久删除所有数据和设置的可能性。如果数据可以传输到其他产品或系统，还应确保以安全方式进行。
这对智能设备、SaaS 平台、IoT 设备、移动终端、工业网关等产品非常重要。
用户在产品退役、转让、维修、返厂、账号注销或更换系统时，应能清除数据和配置，避免敏感信息残留。
企业需要考虑：
是否支持恢复出厂设置；
是否能清除用户账户；
是否能删除本地存储数据；
是否能清除密钥和凭据；
是否能删除云端绑定关系；
是否支持安全数据迁移；
删除操作是否易于用户理解。
很多设备表面上支持“恢复出厂设置”，但实际上仍可能保留日志、缓存、证书、密钥或用户数据，这在 CRA 合规下会成为风险点。
十四、企业应该如何落地这些要求？
面对 CRA 的产品属性要求，企业可以按照以下路径推进。
第一步，开展产品网络安全风险评估。
结合产品用途、运行环境、用户类型、连接方式和数据处理情况，识别主要风险。
第二步，建立 CRA 要求映射表。
将 CRA 基本网络安全要求逐项映射到产品功能、设计文档、测试用例和证据材料中。
第三步，补齐安全设计。
重点检查默认安全配置、更新机制、访问控制、数据保护、日志监控、攻击面控制和数据删除能力。
第四步，完善测试验证。
围绕每一项安全要求设计测试，包括功能验证、安全测试、异常场景测试和漏洞扫描。
第五步，形成技术文档和证据链。
CRA 合规不是口头说明，而是需要形成风险评估、设计说明、测试报告、SBOM、漏洞管理、用户文档等材料。
CRA 合规的重点，是让产品从设计阶段就具备安全属性
CRA《网络弹性法案》对企业提出的要求，不是简单“补一份安全报告”，而是要求产品从设计、开发、制造、上市到维护全过程具备网络安全能力。
对于出海欧盟企业来说，第一部分“产品属性相关的网络安全要求”尤其关键。它直接决定产品是否具备默认安全、可更新、可防护、可监控、可删除、可恢复的基本能力。