对于计划进入欧盟市场的智能硬件、IoT设备、网络设备、工业控制产品、操作系统和软件产品制造商而言，网络安全风险评估是开展欧盟《网络弹性法案》（Cyber Resilience Act，CRA）合规的重要基础。
CRA并不是要求企业简单完成一次漏洞扫描，也不是只提交一张风险评估表。制造商需要根据产品的预期用途、合理可预见的使用方式、运行环境和预期使用期限，识别产品面临的网络安全风险，并将评估结果落实到安全设计、开发、测试、漏洞处理和技术文档中。
一、CRA是否强制要求进行网络安全风险评估？是的。
根据《网络弹性法案》Regulation (EU) 2024/2847 第13条第2至第4款，制造商需要对具有数字元素的产品开展网络安全风险评估，并将评估结果应用于产品规划、设计、开发、生产、交付和维护等阶段。
第13条第3款进一步规定，风险评估至少应考虑产品的预期用途、合理可预见的使用方式和使用条件，例如运行环境、需要保护的资产，以及产品预计使用的时间长度。
制造商还
需要将风险评估形成文件，并在适用的支持期内根据实际情况更新。
CRA附件VII规定的技术文档内容也包括网络安全风险评估，以及产品如何足附件I基本网络安全要求的相关信息。
需要注意，CRA的主要产品安全义务将从2027年12月11日起全面适用，而第14条主动利用漏洞和严重安全事件报告义务已于2026年9月11日起适用。制造商应当提前建设风险评估和漏洞处理能力，而不是等到全面适用前才开始准备。
二、CRA风险评估究竟要评估什么？CRA风险评估的核心不是罗列所有可能发生的攻击，而是结合具体产品识别相关风险，并据此确定适用的网络安全要求及其实现方式。
在实际项目中，建议制造商重点分析以下五个方面。
1. 明确产品边界和预期用途
首先需要确定评估对象，包括产品的硬件、软件、固件、网络接口、远程服务和第三方组件等相关组成部分。
同时，应当明确产品的预期用途、部署环境、用户类型、联网方式及主要安全功能。
例如，一台联网工业网关可能承担设备接入、协议转换、远程运维和数据传输等功能。如果风险评估只关注网关自身的管理界面，而忽略其与现场设备、云平台和远程运维系统之间的连接，就可能遗漏重要风险。
产品边界不清晰，后续的风险分析、安全要求分配和测试范围就很难保持一致。
2. 识别需要保护的资产和潜在攻击路径
制造商需要结合产品架构，识别可能受到影响的安全资产及其保护需求。
典型对象包括：
- 身份凭据、密钥及其他敏感安全参数；
- 用户数据、配置数据和业务数据；
- 管理接口、远程访问接口和网络服务；
- 固件、软件更新包及启动链；
- 访问控制、安全管理和审计功能；
- 第三方软件组件及其依赖关系。
在此基础上，进一步分析未授权访问、权限提升、数据泄露、数据篡改、服务中断、恶意更新和第三方组件漏洞等潜在攻击路径。
具体分析深度应与产品功能、部署环境和实际风险相匹配，而不是为所有产品机械套用同一份风险清单。
3. 分析风险及其影响
识别威胁后，需要分析相关攻击发生的可能性、潜在影响以及现有安全措施能否有效降低风险。
例如，智能摄像头存在远程访问接口，并不意味着该接口必然构成不可接受的风险。真正需要判断的是：接口是否经过身份鉴别，权限是否受到限制，默认配置是否安全，相关数据是否受到保护，以及在异常情况下能否及时发现和处置问题。
风险分析还应考虑产品的预期使用期限。对于长期运行的设备，第三方组件漏洞、软件版本变化和新出现的攻击方式，都可能改变产品的风险状况。
因此，风险评估不能只反映开发初期的产品状态，还需要为后续维护和更新提供依据。
4. 将风险映射到CRA附件I安全要求
这是CRA风险评估中最关键的环节之一。
附件I规定了产品的基本网络安全要求，包括基于风险实现适当的网络安全水平、避免已知可利用漏洞、采用安全默认配置，以及在适用情况下支持漏洞修复和安全更新等要求。
制造商需要根据风险评估结果，逐项判断相关要求是否适用于产品，以及通过哪些技术和组织措施落实要求。
例如：
- 默认配置风险： 是否需要取消通用默认密码、限制默认开放的服务，或提供安全初始化机制？
- 访问控制风险： 是否需要加强身份鉴别、角色权限和管理接口保护？
- 数据保护风险： 是否需要采用适当的加密、完整性保护或密钥管理机制？
- 漏洞风险： 是否建立组件识别、漏洞监测、修复验证和安全更新机制？
- 更新机制风险： 是否能够验证更新来源和完整性，并在支持期内提供适当的安全更新？
如果某项基本网络安全要求被判断为不适用，制造商需要在技术文档中提供清晰的理由。不能仅仅因为某项功能暂时没有实现，就直接将其标记为不适用。
欧盟委员会对制造商义务的说明也明确指出，风险评估是确定产品应当如何落实基本网络安全要求的起点。
5. 明确风险处置措施和验证证据
风险评估的最终目的，是指导产品安全措施的实施，而不是停留在风险登记表中。
对于每项需要处理的风险，建议制造商记录风险描述、影响范围、拟采取的措施、责任人、验证方法和处置结果。
例如，针对未授权访问风险，可以通过权限设计、接口限制和身份鉴别机制进行控制，再通过功能测试、异常输入测试和权限绕过测试验证措施是否有效。
针对第三方组件漏洞，则需要识别受影响组件和产品版本，分析漏洞影响，制定修复或缓解措施，并保留相关验证记录。
风险、控制措施、测试结果和整改记录应当能够相互追溯。 这有助于证明制造商不是仅仅识别了风险，而是已经采取措施处理风险。
三、CRA风险评估需要准备哪些文档？CRA没有规定所有制造商必须使用完全相同的风险评估模板，但第13条和附件VII明确要求形成风险评估及相关技术文档。
在项目实施中，建议至少准备以下材料：
材料主要内容产品边界与架构说明产品组成、接口、联网方式、关键模块及运行环境网络安全风险评估报告预期用途、使用条件、资产、威胁、风险分析及评估结论CRA要求适用性分析附件I相关要求的适用性判断、实现措施及不适用理由安全设计与实现说明关键安全机制如何落实相关要求风险处置与整改记录风险处理措施、责任分工、整改状态和残余风险测试与验证报告测试范围、方法、结果、缺陷及复测结论SBOM及组件管理资料软件组件、版本、依赖关系和漏洞处理信息漏洞处理与更新流程漏洞接收、研判、修复、更新、披露和记录机制支持期及维护依据产品预计使用期限、用户预期、支持安排及相关依据
上述清单是便于项目实施的材料组织建议，不意味着每个项目都必须单独建立同名文件。企业可以根据产品特点、适用法规和已有工程资料整合文档，但应确保CRA要求的内容得到完整覆盖。
四、CRA风险评估需要做一次，还是持续更新？风险评估不是一次性工作。
CRA第13条要求制造商在产品支持期内根据需要更新网络安全风险评估，并系统记录相关网络安全事项，包括已知漏洞及第三方提供的相关信息。
以下情况通常值得重新审视风险评估：
- 产品新增远程管理接口或重要功能；
- 软件、固件或第三方组件发生重大变化；
- 发现可能影响产品安全的新漏洞；
- 产品部署环境或预期用途发生变化；
- 安全测试发现新的攻击路径；
- 已有控制措施失效，或者残余风险发生变化。
这并不意味着每次普通版本更新都必须从头开展完整评估。制造商可以依据变更范围和风险影响，决定更新相关部分还是重新审视整体风险，并保留相应依据。
五、没有CRA协调标准，风险评估应该怎么开展？企业不应将协调标准的发布进度当作启动风险评估的前提。
欧盟委员会于2026年7月27日发布了CRA实施指南，专门涉及风险评估、产品适用范围、支持期和报告义务等实际问题。该指南属于非约束性指导文件，可帮助企业理解法规要求，但不能取代CRA法规本身。
在协调标准尚未被欧盟官方公报正式引用，或企业尚未确定适用标准的情况下，可以先以CRA第13条和附件I为基础，完成产品边界分析、风险评估、安全要求映射和差距识别。
后续再结合适用的协调标准、共同规范或其他相关技术规范，完善具体实施方法和符合性证据。
需要注意，采用某项标准与获得符合性推定并不是同一回事。企业应核实标准的具体版本、适用范围及其是否已在欧盟官方公报中正式引用，不能仅凭标准已经发布就认定自动获得符合性推定。
六、望安科技CRA合规实施支持浙江望安科技有限公司面向计划进入欧盟市场的硬件、软件、IoT设备、网络设备及工业数字产品，提供CRA全流程合规咨询与技术实施支持。
相关服务可覆盖产品适用范围及分类判断、网络安全风险评估、附件I要求映射、产品安全差距分析、SBOM及第三方组件管理、漏洞处理流程建设、安全测试验证、技术文档和符合性评估支持。
通过将风险评估与产品设计、测试整改和证据管理相结合，帮助制造商把CRA法规要求转化为可执行的工程措施和可追溯的合规证据。
欢迎前后浙江望安科技有限公司官网，获取欧盟CRA合规方案与报价
常见问题
CRA是否要求所有制造商进行网络安全风险评估？
是。CRA第13条规定制造商需要评估产品相关网络安全风险，并将评估结果用于产品生命周期内的相关活动。
CRA风险评估报告必须采用统一模板吗？
CRA规定了风险评估必须覆盖的内容，但没有要求所有制造商使用完全相同的报告模板。企业应确保法规要求的内容完整、清晰且能够在技术文档中得到证明。
风险评估可以用漏洞扫描报告代替吗？
不可以。漏洞扫描可以作为风险识别和验证的输入，但无法单独覆盖产品预期用途、运行环境、资产、风险处置、要求适用性及持续维护等全部内容。
