CE-RED网络安全认证的周期，为什么同一个产品有人一个半月走完有人花了大半年。

替无线产品做欧盟市场准入规划的人，这两年都躲不开一个东西：CE-RED的网络安全认证要求。从2025年8月1日开始强制执行，到眼下已经快一年了。

网上搜一圈，铺天盖地都是"合规分析、准备文档、送样测试、拿到声明，顺利的话一个半月到两个半月"。这个流程拆解本身没毛病，但落到真实项目排期上，它基本帮不上忙。

为什么这么说。你在现实里一定会碰到一个困惑：一样的蓝牙耳机产品，A公司一个半月搞定了，B公司拖了半年还没结束。跟同行聊起来，有人说走自我声明就行，有人告诉你必须找公告机构，两边说的周期差了三四倍。你到底该信谁的。

答案其实不复杂：CE-RED网安认证没有固定的时间表。它的实际周期，是"你走了哪条认证路径"决定的基础时长，叠加上"你的技术文档准备到了什么程度"引出的风险，再被"你在执行过程中出了多少岔子"拉长或者缩短。

也就是说，在项目启动的头几天，你还没找实验室、还没写文档，这个认证的大致周期范围就已经定了。只是很多人没意识到。

两条路，两种完全不同的时间量级

先说不碰三条"红线"的情况。

如果你的产品网络安全设计没有触碰EN 18031标准里的那几条限制条款（后面具体说），那么可以走自我声明。这条路效率高，节奏也稳定，因为整个合规责任在制造商自己身上。按RED指令第3.3条(d)(e)(f)的要求，对应EN 18031系列协调标准完成评估，然后自己签符合性声明、贴CE标志，就做完了。

这个过程中第一步是技术判定，你的产品到底归哪个子标准管、有没有踩线、要不要找公告机构。东西全的话，一天左右能出结果。没有任何花头。

真正占时间的环节在第二步：安全设计文档。这里说的不是一份测试报告，而是风险评估报告、条款对照说明、加密算法清单、安全更新机制描述这一整套。你产品里做了哪些安全措施、为什么做、怎么做的，全要写清楚。

如果研发团队从产品立项阶段就考虑了安全设计，这些文档本质上就是把已有结论整理成体系化的格式。一部分功能简单的蓝牙单品，材料理顺了，一周多就能交出去。

但如果研发是产品都快定型了才开始补安全功课，那这事就麻烦了。所有文档从零开始编、安全功能还得回头补开发，一个月打底，拖到三四星期的非常常见。

而且说个现实情况：项目卡壳最多的地方不是实验室，是文档。风险评估覆盖的攻击面不全、条款对标逻辑写得不自洽、加密算法描述跟实际固件里用的对不上，实验室打回来、内部评审打回来、来回改，两周甚至更长时间就这么没了。

文档差不多了才到实验室。但有个关键区别很多人没搞明白：EN 18031的评估跟传统的RF、EMC测试完全不搭界。RF测试是上仪器、读数据、出报告，EN 18031的评估是看文档、扫漏洞、验功能。实验室要查你的风险评估报告有没有逻辑硬伤，要拿漏洞扫描工具跑一遍固件看有没有已知CVE或者过期的开源组件，还要在实际环境里操作设备，确认你说"做了安全启动"它就真的在跑安全启动，你说"传输数据加密了"它就真的在加密。

这个环节的时间，产品越简单越快。一个基本只有蓝牙收发功能的单品，资料齐、文档对，几天就审完了。WiFi多模组再加上云端后台交互的设备就不一样了，要看的网络资产和安全资产多出好几倍，数周是很正常的事。

最后一步签字交材料，一两天的事。整条自我声明路径走下来，素材准备扎实、过程中不需要返工的产品，一个月到三个月之间，简单产品靠下限，复杂产品或文档基础差一点的靠上限，这是业内比较踏实的参照。

现在说另一条路。

如果你的产品踩了EN 18031那三条限制条款，就得走公告机构。

这条路跟自我声明最大的区别，不是流程多了几步，而是你自己的签字不再算数了。欧盟指定的公告机构必须做第三方合格评定，给你出一份型式检验证书，你才能贴CE标志。

前期的合规分析和文档准备，跟自我声明那条路几乎一样。所以不存在"我要走公告机构就可以少准备文档"这种事。文档该写的还是要写，实验室该去的还是要去。而且公告机构通常对实验室的评估报告要求更细，测试覆盖范围要求更宽。

真正的分歧点从提交申请开始。

你把全部材料递交给公告机构之后，他们是不会立刻开始审核的。TÜV、SGS这种头部机构的排期特别紧，案子排到你可能要等一周到几周。

然后他们开始审。注意，公告机构审的不是你的测试数据对不对，是审你的安全逻辑。你的风险评估覆盖的攻击面够不够、威胁建模有没有遗漏、你声称的安全措施到底有没有真正解决问题。这个过程里他们大概率会提出问题，要求你补充说明、调整文档、甚至改动产品功能。

你补充完再提交，他们再安排新的审核档期来复核。这种"你交、他们等、他们审、他们提意见、你补、你再交、他们再等、他们再审"的来回拉锯，才是这条路径真正费时间的地方。有时第一轮意见回来你得花一两周改，第二轮可能又是一两周。所有意见闭环之后，证书才出来。

所以公告机构路径的周期，即便是产品本身没什么硬伤、找的机构排期也还行的情况下，四到六个月是正常范围。碰上头部机构排期特别紧，或者产品有几轮大改，奔着半年到八个月甚至更长去的，一点都不奇怪。

三条"红线"长什么样

EN 18031虽然为RED指令的网络安全要求提供了"符合性推定"（意思是完全按标准执行就可以推定合规），但标准里留了三条限制。触发了就会丧失这个推定力，然后必须走公告机构。

第一条，密码。如果产品允许用户不设密码或者跳过密码设置流程直接使用，EN 18031的三个子标准（-1网络保护、-2隐私保护、-3金融安全）全部丧失协调性。不是一个，是三个一起。因为在标准框架里用户认证是所有安全机制的地基，地基没了，上面三栋楼都得重审。

第二条，儿童设备的家长控制。如果你的产品属于儿童看护、儿童玩具或可穿戴设备，但没有实现父母或监护人对设备的访问控制，EN 18031-2就失效了。注意这里不是说"完全没有控制"才算，用了"自主访问控制"这种未成年人可以自己改配置的模式一样算。

第三条，金融设备的安全更新。如果产品涉及虚拟货币或货币价值的处理（支付终端、加密钱包之类），安全更新只用了单一手段，比如只有数字签名或只有访问控制，不满足多层防护的要求，EN 18031-3就失效了。

如果你的产品跟这三类场景完全不沾边，那就在协调标准框架下走自我声明。这在项目早期做技术判断的时候就能确定，不用等到后面。

真正拖时间的东西

知道两条路的区别还不够。实际上就算走了自我声明这条相对省心的路，有些事还是能让你从一两个月变成四五个月甚至更久。

最常见的问题，文档和产品对不上。文档里写的AES-256，固件里实际跑的是AES-128。文档里写了安全启动，固件里调试口压根没关。实验室发现这种不一致，测试直接停下来，让你回去对齐。整改固件或者修正文档，一来一回，一周到三四周就没了。

还有一类是评估过程中发现的问题太大，不能修修补补解决。渗透测试扫出弱密码、开放端口、配置漏洞这些，属于好修的。但如果发现协议层面的缺陷、加密逻辑的设计错误，那就不是关几个口子的事了。可能要重新设计一个功能模块，开发、自测、再送实验室复测。这套整改加复测的循环，随随便便就是几周甚至更久。

文档版本管理也是个不起眼但容易翻车的地方。研发在送检期间顺手修了个Bug、更新了个固件小版本，忘了通知实验室，忘了更新版本记录，文档里引用的版本号还是旧的。文档和产品对不上，评估直接卡住。

做排期的时候把这些变量单独列出来

做项目计划的时候，最大的毛病是在"基础周期一两个月"后面加一个笼统的弹性余量就觉得ok了。更管用的办法是把文档编制、测试整改、认证路径判定分别当成独立的里程碑，各自管理各自的质量和节奏。

文档能不能在两周内交出去？取决于研发有没有安全设计的前期积累，不是取决于"认证计划书里这个阶段预留了三周"。

渗透测试会不会踩大坑？取决于固件开发的质量到底怎么样，不是取决于"列表里写了弹性时间可覆盖"。

另外有个事值得在2026年这个时间点提一句。EN 18031作为协调标准，严格执行且不触发限制条款的情况下，你做出的符合性声明是有"符合性推定"法律效力的，在市场监管和海关查验中有实质作用。再往后看，2027年底欧盟的Cyber Resilience Act要全面生效，跟EN 18031的要求有重叠。现在按EN 18031做完的产品，证据是可以映射到未来CRA的附件I要求里的，等于提前做了一部分CRA的准备。

这个认证说到底是工程管理问题，不是背一个固定时间表的问题。