很多企业在准备 CRA《网络弹性法案》合规时，都会先问一个问题：我们的产品是不是一定要找认证机构做认证？
在 CRA 法案框架下，不同产品类别对应不同的合格评定路径。对于部分具有数字元素的产品，如果满足适用条件，制造商可以采用模块 A：基于内部控制的合格评定程序。
简单理解，模块 A 是一种以制造商自我控制、自我证明为核心的合格评定方式。企业需要通过内部流程、技术文档、产品设计控制、漏洞处理机制、欧盟符合性声明和 CE 标志，证明产品符合 CRA 的基本网络安全要求。
但需要注意的是，模块 A 并不等于"自己说符合就可以"。它对企业的技术文档、研发过程、安全验证、漏洞管理和合规声明提出了明确要求。一旦产品投放欧盟市场，制造商需要对符合性结果承担完整责任。
一、模块 A 是什么？不是简单自我声明
CRA 中的模块 A，也就是基于内部控制的合格评定程序，核心是制造商通过自身内部控制来履行合规义务，并确保和声明其全权负责产品符合 CRA 的基本网络安全要求。
这里有两个关键词：内部控制 和全权负责。
内部控制意味着，企业需要在产品设计、开发、生产、测试、漏洞处理、技术文档和上市合规中建立可证明的管理机制。
全权负责意味着，如果企业采用模块 A，最终的符合性声明不是由第三方替企业背书，而是由制造商自己承担责任。后续如果主管机构检查、客户要求审查，企业需要能够拿出完整证据证明产品符合 CRA 要求。
因此，模块 A 不是降低合规要求，而是把证明责任更多放在制造商内部。
二、哪些企业会关注模块 A？
模块 A 通常更容易被普通类产品或满足特定条件的重要 I 类产品关注。
对于很多出海欧盟的智能硬件、IoT 设备、嵌入式软件、网络设备、工业终端、SaaS 平台、远程管理工具等企业来说，如果产品不属于需要更高强度评定的类别，或者能够完整适用相关协调标准、通用规范或适用认证方案，就可能考虑模块 A 路径。
企业最关心的是：如果可以走模块 A，是否意味着成本更低、周期更短？
从流程上看，模块 A 相比第三方评定确实更灵活。但它并不意味着企业可以少准备材料。相反，企业需要自己把技术文档、测试证据、风险评估、漏洞处理、符合性声明等内容准备充分。
模块 A 的难点在于：没有第三方前置把关时，企业自身的合规判断必须更准确。
三、制造商首先要编制技术文档
模块 A 明确要求制造商编制技术文档。
技术文档是 CRA 合规中非常核心的材料。它不是一份简单产品说明书，而是一套能够证明产品符合基本网络安全要求的证据集合。
一般来说，技术文档应能够说明：
产品是什么；
产品的预期用途是什么；
产品是否属于具有数字元素的产品；
产品的软硬件组成是什么；
产品是否联网、是否远程更新、是否处理数据；
产品适用哪些 CRA 要求；
企业如何开展网络安全风险评估；
产品采取了哪些安全设计措施；
企业如何测试和验证安全功能；
如何管理漏洞和安全更新；
如何准备用户安全说明和支持周期；
如何支撑欧盟符合性声明和 CE 标志。
很多企业过去已有 CE 技术文件、产品说明书、测试报告，但这些材料往往不直接覆盖 CRA 网络安全要求。采用模块 A 时，企业需要把传统产品合规材料与网络安全合规证据结合起来。
四、产品设计、开发、生产和漏洞处理都要受控
模块 A 不只关注最终产品，也关注制造商是否对产品设计、开发、生产和漏洞处理进行了控制。
在设计阶段，企业需要基于风险评估确定安全要求。例如产品是否需要强身份认证、是否需要加密传输、是否需要安全启动、是否需要访问控制、是否需要日志记录、是否需要自动更新机制。
在开发阶段，企业需要将安全要求落实到研发活动中。例如安全编码规范、代码审查、组件管理、依赖漏洞扫描、接口权限控制、配置安全检查等。
在生产和发布阶段，企业需要确保最终交付版本与技术文档和测试对象一致。例如版本基线、发布记录、配置管理、交付包校验、固件签名、默认配置检查等。
在漏洞处理阶段，企业需要建立漏洞识别、记录、评估、修复、安全更新、用户通知和披露机制。CRA 的基本网络安全要求第二部分专门强调漏洞处理，说明漏洞管理不是附加项，而是制造商必须履行的持续义务。
五、模块 A 下的漏洞处理不能忽视
很多企业容易把模块 A 理解成"上市前自我声明"，但 CRA 对漏洞处理的要求会持续到产品支持期内。
制造商需要识别和记录产品中的漏洞和组件，编制至少覆盖顶级依赖项的软件物料清单，也就是 SBOM。还需要及时处理漏洞、提供安全更新、定期测试和审查产品安全性、建立协调漏洞披露政策、提供漏洞报告联系地址，并安全分发更新。
六、符合性声明和 CE 标志是最终外部体现
模块 A 还要求，制造商应在每个满足 CRA 适用要求的具有数字元素产品上加贴 CE 标志。
这说明 CRA 与 CE 合规体系是衔接的。对于适用 CRA 的产品，网络安全要求将成为产品 CE 合规的一部分。企业不能只关注传统 CE 测试，还要确认 CRA 网络安全要求是否已经纳入技术文档和符合性声明。
同时，制造商还应为每个产品编制书面的欧盟符合性声明，也就是 EU Declaration of Conformity。
这份声明应明确指明为哪个产品编制，并说明产品符合相关适用要求。它不是简单格式文件，而是制造商对产品合规性的正式承诺。
根据 CRA 要求，欧盟符合性声明应与技术文档一起保存至少 10 年，自产品投放市场之日起计算；如果产品支持期更长，则应保存至支持期结束，以较长者为准。主管机构要求时，企业需要提供符合性声明副本。
七、授权代表可以履行部分义务，但责任边界要写清楚
CRA 允许制造商的部分义务由授权代表代表其履行，并在制造商责任下执行，前提是这些义务在授权书中明确写明。
八、企业采用模块 A 前，建议先做一次合规判断
模块 A 看起来流程相对简化，但企业不能一开始就默认自己可以走模块 A。
在正式确定路径前，建议先判断几个问题：
第一，产品是否属于 CRA 范围。
如果产品包含软件、联网能力、数据处理能力、远程更新能力，就需要重点判断是否属于具有数字元素产品。
第二，产品类别是什么。
产品是普通类、重要 I 类、重要 II 类，还是关键产品？不同类别可能对应不同评定路径。
第三，是否可以完整适用相关协调标准或通用规范。
对于某些产品，是否能采用模块 A，可能与是否完整适用相关标准有关。
第四，企业是否有足够证据支撑自我声明。
如果技术文档、风险评估、测试报告、SBOM、漏洞管理、安全更新机制都不完整，即使路径上可以选择模块 A，实际合规风险也很高。
第五，客户是否接受该路径。
有些客户可能会基于采购要求或供应链安全要求，要求第三方测试、额外认证或更详细的合规证据。企业需要把法规路径和客户要求结合起来看。
九、模块 A 常见误区
误区一：模块 A 就是不需要准备材料。
实际上，模块 A 对技术文档、产品过程控制、漏洞处理、符合性声明和 CE 标志都有明确要求。
误区二：模块 A 就是没有监管风险。
制造商自我声明后，仍可能面临主管机构检查、客户审核和市场监管。没有证据支撑的声明风险很高。
误区三：只要产品做过 CE，就自动满足 CRA。
原有 CE 可能只覆盖 EMC、LVD、RED、RoHS 等要求，并不代表已经满足 CRA 网络安全要求。
误区四：授权代表可以替制造商承担所有责任。
授权代表可以在授权范围内履行部分义务，但制造商仍需对产品符合性负责。
误区五：模块 A 只关注产品上市前。
CRA 还要求制造商在支持期内持续处理漏洞并提供安全更新，模块 A 下同样不能忽视上市后维护。