芯耀
与非AI
167
引言
在前三期中，我们已经分别对 CRA 的适用范围、整体影响、率先生效的漏洞通报义务，以及网络安全风险评估与管理机制进行了分析。随着 2026 年 9 月 11 日报告义务适用日期不断临近，企业的 CRA 合规准备不应仅停留在“发生漏洞后如何报告”，也不能止步于“内部是否开展过风险评估”。更关键的问题正在浮现：企业是否能够把已经开展的安全活动，转化为一套能够被审查、被追溯、被证明的合规证据。
根据欧盟委员会公开说明，CRA 已于 2024 年 12 月 10 日生效，主要义务将自 2027 年 12 月 11 日起适用，其中报告义务自 2026 年 9 月 11 日提前适用。CRA 对制造商的要求覆盖产品的规划、设计、开发、生产、交付和维护阶段，并要求相关义务贯穿价值链。这意味着，CRA 合规并不是一次性安全整改，也不是单独建立一个漏洞报告流程，而是要求企业建立能够支撑产品全生命周期的合规证明体系。
如果说网络安全风险评估是 CRA 合规的起点，那么技术文档、符合性评估、欧盟符合性声明和 CE 标志，就是企业把风险评估结果转化为市场准入资格的关键环节。
一、CRA 合规的核心，不只是“做到”，而是“证明做到”
在许多企业现有的安全管理实践中，研发、安全、测试、运维、法务和合规团队往往分别保存各自的材料。例如，研发团队掌握架构设计和版本信息，安全团队掌握漏洞扫描和渗透测试结果，供应链团队掌握第三方组件清单，法务团队掌握用户条款和合规声明，售后团队掌握漏洞反馈和客户通知记录。
这些材料本身都很重要，但在 CRA 框架下，仅有分散材料并不足够。企业真正需要建立的是一条从“要求”到“措施”再到“证据”的可追溯链条。换言之，企业不仅要说明产品采取了哪些安全措施，还要能够解释这些措施对应 CRA 的哪些基本网络安全要求，依据何种风险判断被采用，由哪个部门负责实施，通过哪些测试或记录证明其有效，并在产品支持期内如何持续更新。
欧盟委员会在 CRA 说明中明确指出，制造商在设计、开发和生产具有数字要素的产品时，需要确保产品满足基本网络安全要求；为此，制造商需要开展网络安全风险评估，并将风险评估以及用于落实基本要求的手段纳入技术文档。制造商在产品投放市场前，还需要完成相应的符合性评估程序，随后出具欧盟符合性声明并加贴 CE 标志。
这正是第三期最需要提醒企业的地方：CRA 合规不是“安全团队内部认为已经安全”，而是“企业能够向市场监督机构、进口商、分销商、客户以及必要时的公告机构证明产品符合要求”。
二、技术文档是 CRA 合规证据链的核心载体
根据 CRA 第31条，技术文档应包含制造商用于证明产品及其相关流程符合附件 I 基本网络安全要求的所有相关数据和细节；技术文档应在产品投放市场前形成，并在适用情况下至少于支持期内持续更新。
这意味着，技术文档并不是产品上市前临时整理的一份“合规报告”，而应当是伴随产品开发、测试、发布和维护持续沉淀的证据库。对企业而言，技术文档至少应回答四个问题：第一，产品是什么；第二，产品面临哪些网络安全风险；第三，企业采取了哪些设计、开发、生产、漏洞处理和更新措施；第四，企业如何证明这些措施满足 CRA 的要求。
从 CRA 附件 VII 的内容来看，技术文档至少应覆盖产品的一般说明、预期用途、影响合规的软件版本、用户信息和说明，产品设计、开发和生产信息，漏洞处理流程，SBOM、协调漏洞披露政策、漏洞报告联系地址、安全更新分发方案，网络安全风险评估，支持期确定依据，适用标准或替代技术方案，测试报告，以及欧盟符合性声明等内容。
这对企业提出了一个非常现实的要求：CRA 技术文档不可能完全由法务或合规部门独立完成。它需要产品、研发、安全、测试、运维、供应链、售后、法务和合规团队共同提供输入。企业越早建立统一的文档模板和证据归集机制，后续符合性评估和市场监督应对的成本就越低；反之，如果等到产品上市前才倒推补材料，很容易出现版本不一致、风险结论缺失、测试证据不足、供应商材料不可得、用户说明与真实支持政策不匹配等问题。
三、符合性评估决定了企业能否顺利完成市场准入动作
CRA 下的符合性评估，是验证产品是否满足附件 I 基本网络安全要求的过程。欧盟委员会说明中也将其定义为确认附件 I 基本网络安全要求是否已经被满足的程序。
从企业实务角度看，符合性评估至少包含两个层面的判断。第一，企业要判断产品属于普通产品、重要产品还是关键产品。第二，企业要判断自己是否可以采用内部控制程序进行自我评估，还是必须通过公告机构开展第三方评估，或者在可用且适用的情况下使用欧洲网络安全认证方案。
CRA 第32条列明了不同符合性评估路径，包括内部控制程序、EU 型式检验加内部生产控制、完整质量保证，以及在可用且适用时采用欧洲网络安全认证方案。对于部分重要产品或关键产品，企业可能无法自由选择最轻量的自我评估路径，而需要进入第三方评估或更高强度的认证路径。
这意味着，企业现在就应当启动产品组合梳理，而不是等到 2027 年底主要义务全面适用前才判断产品分类。尤其是拥有多条产品线、多个软件版本、软硬件组合产品、云端远程数据处理能力或大量第三方组件的企业，更应当尽早建立产品分类台账，判断哪些产品可能属于重要产品或关键产品，哪些产品需要提前预留公告机构评估周期，哪些产品可以通过内部控制程序完成符合性评估。
四、企业应建立“要求—措施—证据—责任人”矩阵
对大多数企业而言，CRA 技术文档和符合性评估的最大挑战，不是完全没有安全能力，而是安全能力与合规要求之间缺少映射关系。企业可能已经有漏洞扫描、代码审计、渗透测试、访问控制、日志监测、供应商审查、补丁发布等机制，但如果这些机制没有对应到 CRA 的具体要求，也没有形成稳定证据，就很难在符合性评估或监管问询中发挥作用。
因此，建议企业围绕每一类产品建立“要求—措施—证据—责任人”矩阵。第一列列明 CRA 附件 I 中适用的基本网络安全要求；第二列说明企业针对该要求采取的具体控制措施；第三列对应相关证据材料，例如风险评估报告、架构图、威胁建模记录、测试报告、SBOM、漏洞处理记录、补丁发布记录、用户通知、供应商安全资料等；第四列明确证据的责任部门、更新频率和保存位置。
这一矩阵的价值在于，它可以把 CRA 合规从抽象的法规解读转化为企业内部可执行、可分工、可检查的工作清单。对研发团队而言，它说明安全设计和测试结果如何服务合规；对安全团队而言，它说明漏洞管理和检测活动如何形成证据；对供应链团队而言，它说明第三方组件和供应商资料为何必须持续更新；对法务和合规团队而言，它则提供了判断声明、说明书、支持期承诺和市场沟通是否一致的基础。
五、150天倒计时阶段，企业最应优先完成什么
在距离报告义务适用还有约四个月的阶段，企业不可能一次性完成所有 CRA 合规建设，但可以优先完成几项关键基础工作。
第一，建立产品适用性和分类台账。企业应识别哪些产品属于具有数字要素的产品，哪些产品已在欧盟市场提供，哪些产品计划进入欧盟市场，哪些产品包含远程数据处理、第三方组件或开源依赖，并初步判断是否可能落入重要产品或关键产品类别。
第二，建立技术文档目录和证据归集机制。企业不应等到正式符合性评估前才开始整理材料，而应先根据 CRA 第31条和附件 VII 建立统一目录，明确每一类材料由谁提供、何时更新、保存在哪里、与哪些产品版本绑定。
第三，完善风险评估与控制措施映射。第二期已经讨论过风险评估的重要性。第三期需要进一步强调，风险评估的结论不能孤立存在，而应当直接映射到安全设计、测试验证、漏洞处理、供应链管理、更新机制和用户说明。
第四，提前设计符合性评估路径。企业应判断哪些产品可能适用自我评估，哪些产品可能需要第三方评估，是否需要等待或跟踪协调标准、通用规范或欧洲网络安全认证方案的进展。对于可能需要公告机构参与的产品，应当尽早预留时间和预算。
第五，检查用户说明、支持期承诺和漏洞处理流程是否一致。CRA 要求制造商向用户提供相关信息和说明，包括支持期结束日期；欧盟委员会也指出，制造商需要确定产品支持期，并在购买时清晰、可理解地说明支持期结束时间。如果企业对外承诺的支持期、内部漏洞修复能力、安全更新机制和技术文档中的记录不一致，将成为后续合规风险点。
六、从“合规项目”走向“产品治理能力”
CRA 给企业带来的真正变化，不只是新增了一套欧洲市场准入规则，而是推动企业把网络安全纳入产品治理的核心流程。过去，安全活动可能更多被视为研发过程中的技术要求，或漏洞事件发生后的响应机制；但在 CRA 框架下，安全设计、风险评估、漏洞处理、供应链管理、用户说明、技术文档和符合性评估共同构成产品能否进入并持续留在欧盟市场的基础条件。
因此，第三期最重要的结论可以概括为一句话：CRA 合规的下一步，不是再写一份风险评估报告，而是把风险评估、技术措施和组织流程转化为可证明的合规证据链。
对于出海企业而言，谁能更早建立这条证据链，谁就能在 2026 年报告义务适用后更从容地处理漏洞事件，也能在 2027 年主要义务全面适用前更顺利地完成符合性评估、欧盟符合性声明和 CE 标志相关准备。相反，如果企业仍将 CRA 理解为单一的“漏洞通报规则”，而忽视技术文档和符合性评估要求，那么即便短期内能够应对个别漏洞事件，也可能在产品准入、监管问询、客户尽调和供应链合作中面临更大的不确定性。
