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《网络弹性法案》对企业提出的要求不是简单“补一份安全报告”而是要求产品从设计、开发、制造、上市到维护全过程具备网络安全能力。对于出海欧盟企业来说第一部分“产品属性相关的网络安全要求”尤其关键。它直接决定产品是否具备默认安全、可更新、可防护、可监控、可删除、可恢复的基本能力。
