每次有新客户过来问CE-RED网络安全认证，聊到后面总会问一句："那材料要准备哪些？证书能用多久？"
这个问题问得其实特别好。因为厂商日常关心的就这两件事，不是什么法规修订了几轮、标准出了多少版本，而是"我到底要交什么东西、交完之后能不能一劳永逸"。
CE-RED网络安全认证的材料，不管你是走自我声明（DoC）还是公告机构（NB）型式评审，底层需要的文档框架是一样的。区别只在NB路径多一道第三方审核签字。
按RED指令和EN 18031协调标准（非唯一路径，你也可以用等效安全方案满足3.3条，但业内主流做法是对标EN 18031走），核心材料分三套。
第一套：技术文档。
这是整份合规材料里分量最重的一份。RED指令要求设备投放欧盟市场后，制造商须保存技术文档至少10年；对非欧盟制造商来说，还需委托欧盟授权代表（欧代）在欧盟境内代管全套技术档案，进口商也负有确保文档可被市场监管部门调阅的义务——光这条就告诉你它有多重要。
技术文档要包含的东西不少：
·产品描述——功能和用途，这是基础，得让审核方看清楚你的设备到底干什么。
·设计和制造信息——电路原理图、PCB布局、物料清单、天线报告——从硬件角度展示安全功能怎么实现的。
·测试报告——电磁兼容、网络安全功能验证、无线电性能——测试数据必须跟你的安全声明对得上。
·用户手册——使用说明和安全警告。
·软件和固件信息——版本号、更新机制、安全补丁策略——嵌入式设备这块最容易出问题。
第二套：风险评估。
这一步在EN 18031体系里是独立的、必须的。不是说功能做进去了就可以不评。
风险评估要做四步：
·威胁建模——分析你的设备可能面临的攻击类型，数据泄露、未授权访问、固件篡改、通信劫持，按你的产品场景来。
·漏洞评估——硬件和软件里有哪些潜在弱点，有没有已知CVE，有没有不安全的默认配置。
·缓解措施——针对识别出来的威胁和漏洞，你用了什么手段，加密协议、访问控制、安全启动、通信保护，一条一条对应。
·持续监控计划——设备上市之后你怎么跟踪新漏洞、怎么推送安全更新。
第三套：合规报告 + 符合性声明（DoC）。
合规报告是把前面的技术文档和风险评估整合成一份正式的合规证据文件。测试结果汇总、风险评估结论、相关认证文件——都得在这份报告里串成一条逻辑线。
符合性声明（Declaration of Conformity）由制造商签署，声明设备符合RED指令和适用标准。这是最终的法律文件，签了字就代表你对合规负全责。
如果走NB路径，合规报告还需要附上公告机构出具的型式审查证书。另外(EU)2025/138三项限制条款——密码可跳过使用、儿童看护/玩具设备无家长控制、金融设备安全更新单一方式——踩了任意一条就不能自我声明，必须走NB，材料里就多了这份第三方签字。
二、有效期：不是一纸证书管一辈子
这块是行业误解的重灾区。好多人以为拿了CE-RED网安证书就万事大吉了，以后什么都不用管。
1.NB型式证书。 RED网安NB证书本身没有法规层面的固定有效期，也没有强制年审周期。只要产品硬件、安全架构、固件核心安全逻辑不发生重大变更，证书持续有效。
2.自我声明（DoC）。 制造商签署的符合性声明没有"过期"这个概念。它是持续有效的——前提是你的产品和技术文档始终维持一致。一旦你改了硬件设计、升级了固件，而且变更内容影响到了安全架构、加密逻辑、OTA机制等涉及3.3(d/e/f)合规的核心部分，原来的声明就覆盖不了新产品了，需要重新评估、重新签署。反过来，纯UI调整、换个不是关键安全的周边组件这类改动，不涉及安全设计，不需要重做评估，也不用重新签署声明。
什么时候必须重新认证：
·一是产品发生了影响网络安全的变更——硬件换了主控芯片、固件改了安全启动逻辑、通信协议改了加密方式——这些都会触发重新评估，NB路径可能需要重新提交审核。
·二是法规变了——RED指令或协调标准更新后，旧版合规文件可能不再被认可。
还有两种不需要重新认证但需要你动一下的情况：
1.出了新的高危CVE——你的风险评估文档该更新得更新，你的漏洞响应机制该动作得动作，但这不是自动触发NB复审。简单的补丁修复，内部做好、记录存档。只有漏洞牵涉到产品的核心安全设计、发生了重大架构变更，才需要跟NB沟通是否重新评估。
技术文档保存义务。 上面提过了，设备投放欧盟市场后，制造商须保存技术文档至少10年，非欧盟制造商须通过欧代在境内代管，进口商配合确保文档可调阅。这是法定最低要求，跟你的证书有没有效是两个独立义务。
2.知道了要哪些材料，怎么把这些材料编到位，是第二个问题。
技术文档这块，最怕的就是研发和法规脱节。安全架构设计师画的图、写的描述，法规工程师不一定看得懂；反过来法规工程师要的结构化表述，研发又觉得啰嗦。
解决办法也简单：找既懂嵌入式开发又跑过EN 18031项目的认证机构做中间沟通。不是代你写，是帮你把研发的语言翻译成合规的语言。
风险评估要避免的事：不要等到文档阶段才做风险评估。应该从产品设计阶段就启动——安全功能是在设计阶段定型的，不是后面靠文档补的。如果设计阶段有安全评审记录，风险评估文档写起来就是整理现有结论，远比你从头推演省时间。
版本管理也是个容易被忽略的事：技术文档不是写一次就封存的。固件迭代、安全补丁发布、功能调整，这些都会有文档更新需求。建议从一开始就建立版本化管理——每次更新注明版本号、修改日期、变更内容、对应哪个固件版本。审核的时候拿得出一套干净完整的版本记录，比扔一堆散文件效果好得多。
作者在蓝亚技术（深圳）有限公司做无线设备出口认证咨询，CE-RED网络安全认证（EN 18031）、CB、ISED/IC、NOM都做。具体产品的合规评估和方案报价，可联系蓝亚技术检测认证机构顾问：13632500972（Benson）
