EN 18031-1解读：欧盟无线电设备网络安全合规新规与落地指南

最近在认证圈子里，“EN 18031-1”成了高频词。很多做无线设备的朋友一开始没当回事，等欧洲客户发邮件来问“你们有没有对应测试报告”的时候，才意识到这不是普通版本更新，而是欧盟对无线电设备网络安全合规的一次系统性收紧。EN 18031-1是RED指令（2014/53/EU）第3.3(d)条的协调标准，通俗说法就是“通用网络安全认证新规”，核心逻辑很直接：能访问网络的无线设备，想继续在欧盟市场卖，必须证明自己不会变成攻击者手里的跳板，不会反过来祸害整个网络。

这篇文章不打算逐条翻译标准原文，而是从一个兼顾研发和合规的人的角度，把EN 18031-1的背景、技术考核点、落地步骤和容易翻车的细节讲清楚。无论你正在做Wi-Fi模块、蓝牙外设、智能家居单品还是工业无线网关，都可以拿这篇内容作为合规工作的起点，省掉一部分自己查资料绕弯路的成本。

1. 2025年8月1日这个强制节点，是怎么一步步落地的

1.1 从RED的3.3(d)(e)(f)说起

RED指令（2014/53/EU）本身不算新东西，过去大家做CE相关测试，注意力主要集中在射频、电磁兼容、电气安全这些传统维度。但欧盟在2018年对RED进行了修订，给第3.3条增加了几项与网络安全、隐私保护、防欺诈相关的条款。其中：

• 3.3(d)：无线电设备不得损害网络及其功能；
• 3.3(e)：无线电设备必须保护用户个人数据和隐私；
• 3.3(f)：无线电设备必须具备防止欺诈的能力，特别是与货币、虚拟货币相关的场景。

条款写进了指令，但真正的问题是，当时没有一部成熟标准能告诉制造商“怎样证明自己满足这些要求”。没有协调标准，就没有统一的评估依据，市场监管机构难以实际执法，制造商也无法开展符合性声明。这种情况僵持了好几年。

1.2 授权法规2022/30和协调标准的出现

2022年，欧盟发布了授权法规（EU）2022/30，给3.3(d)(e)(f)搭出了可执行的框架。它规定了新增网络安全要求适用于哪些无线电设备类别，同时将“怎么算合规”的答案指向了待制定的协调标准。到了2024年，CEN/CENELEC正式发布EN 18031-1、EN 18031-2、EN 18031-3三份标准，随后欧盟官方公报正式引用，使其成为具有“推定合规”效力的协调标准。也就是说，按EN 18031系列走，就会被推定满足RED第3.3(d)(e)(f)的对应要求。

EN 18031系列在技术上与ETSI EN 303 645（消费者物联网安全基线）有清晰的承继关系，又针对无线电设备的特点做了大量细化。理解这一点很重要：它更像一份“安全工程规范”，而不是一份传统意义上的“实验室测试标准”。

1.3 关键时间轴

需要注意的是，强制执行针对的是“投放市场”这个动作。对于2025年8月1日前已经合法投放市场的存量设备，一般不受这条新规追诉。但存量设备如果后续出现重大安全更新、固件重构或变更预期用途，是否需要重新评估，建议让消费品合规律师针对具体产品判断，别自己拍脑袋。

1.4 为什么标准落地拖了这么久

不少同行问过：为什么授权法规2022年就出台了，协调标准2024年才发布？个人理解，核心原因是网络安全性没法像射频传导测试那样用一组固定阈值来判定。同一个设备放在不同使用场景、不同威胁模型下，风险边界差异很大。EN 18031系列采取的方法论，是先做威胁分析和风险评估，再根据评估结果确定安全措施，最后通过测试和文档证明措施真的落了地。这意味着制造商不能像以前那样“送一台样机，测几天，拿一份报告”，而是要把安全评估做成一套文档化、可追溯的过程。这个过程比传统测试复杂得多，标准制定的工作量自然也大得多。

2. EN 18031-1到底管哪些设备，别急着对号入座

2.1 三个分册到底怎么分工

很多人把EN 18031-1、2、3混在一起说，其实它们面向的是不同侧重点：

一个设备不一定只对应一本标准。比如一款带摄像头和指纹识别的智能门锁，它要访问网络，又采集个人生物特征数据，大概率同时适用EN 18031-1和EN 18031-2；如果后续加了在线支付远程开锁功能，EN 18031-3也要一并考虑。所以做适用性判断时，要按“网络功能 + 个人数据处理 + 货币交易”三个维度分别过一遍。

2.2 “无线电设备”和“访问网络”怎么理解

判断一个产品是否在RED范围内，首先要看它是否具备无线电发射或接收功能。这里覆盖的产品类别非常广：Wi-Fi、蓝牙、蜂窝通信、Zigbee、Z-Wave、NFC、RFID、UWB、毫米波雷达都在范围内。哪怕你的产品用的是外购无线模块，只要整机以无线电设备身份投放市场，同样适用。

“访问网络”这个概念也容易被窄化理解。EN 18031-1要求的不只是“能上公网”，设备只要具备网络连接能力、能参与数据交换，哪怕只是局域网内点对点通信，也需要纳入评估。很多做蓝牙传感器的朋友觉得“我的设备不上云，走的是手机App点对点”，然后判定自己不需要管，这个思路在新规下很危险。蓝牙链路本身是网络通路，固件被OTA覆盖、App绕过身份验证直接控制设备、配对过程被重放攻击，这些问题照样会被安全评估人员翻出来。

2.3 常见误区对照

3. EN 18031-1具体考核什么：从威胁模型到安全措施落地

3.1 设备自身：安全启动、完整性校验和密钥管理

设备自身安全的第一道关，是安全启动和安全固件更新链路。EN 18031-1要求产品具备基本的安全启动能力，固件在启动阶段要有签名校验，防止攻击者刷入篡改过的镜像。这里的关键不仅是“启动时有校验”，还包括密钥的存储方式，如果私钥以明文躺在Flash里，那签名校验基本等于给攻击者看表演。

实际操作中，很多MCU平台已经内置安全启动、OTP密钥区、加密引擎，只是产品默认没有开启。评估时可以从“攻击者能不能物理接触设备”“能不能拿到固件包”“拿到固件包能否解包、重打包并再次刷入”这些角度反推自己需要做到哪一步。对于不可信输入的处理也是审查重点，比如设备监听MQTT消息，消息体没有做格式校验，攻击者用畸形报文就可能让设备崩溃甚至执行代码。标准不会把它当成一个普通Bug，而是要求厂商在安全设计说明里讲清楚输入校验、异常处理和对应测试覆盖。

3.2 通信链路：加密、认证与协议安全

通信加密是EN 18031-1里最直观的考核点。Wi-Fi设备至少应支持WPA2/WPA3这类安全协议；TCP/IP应用层尽量使用TLS 1.2以上；蓝牙设备要评估配对机制、最小密钥长度、是否支持那些存在已知缺陷的老版本配对算法。审核中很常见的问题包括：OTA下载固件时走HTTP明文、登录管理接口时用自签名证书但不做证书校验、云端接口包含硬编码API Key。这些问题一旦出现，通常会被直接记为高风险项。

除了加密，身份认证也要过一遍。设备连接服务器时是否使用唯一的设备证书或安全Token？所有设备是否共用同一个云端密钥？如果一台设备被逆向后，攻击者提取到全局密钥，整个产品线都存在沦陷风险，这在标准评审里是重点打击对象。

协议层面的检查还包括默认服务和端口。很多物联网设备为了开发调试方便，出厂时开着SSH、Telnet或一组调试用UDP端口。新规下这些都属于不必要的攻击面，评估人员会要求你证明“非必要服务默认关闭，且无法从网络侧被远程调用”。

3.3 身份与访问控制：默认口令、会话管理和最小权限

身份与访问控制是审核中的“重灾区”。默认口令问题老生常谈，但执行层仍然混乱：有的设备默认密码是admin/admin，有的写死在说明书里，有的产品根本没有首次登录强制修改的逻辑。EN 18031-1并没有简单粗暴地禁止设置默认密码，而是要求设备必须具备合理机制，确保默认凭据不会让设备处于可被轻易滥用的状态。更稳妥的做法是首次启动强制用户创建自定义密码，或者出厂时生成随机唯一凭据并打印在设备标签上。

会话管理同样会被审查。管理端长时间不操作不应保持永久登录；Token应有合理过期时间；密码如果允许明文存储，基本可以直接判定不符合。审核人员通常会调阅安全设计文档，检查这些参数的设计理由，而不是只看最终测试结果。把安全设计思路写清楚，在EN 18031-1评估里占用和功能实现同等重要的位置。

3.4 软件更新与漏洞管理：不止是“能OTA”就行

很多厂商以为产品支持OTA就满足了软件更新要求，这是整份标准里被误解最深的一条。EN 18031-1对更新机制的要求是立体的：更新包必须做签名校验；更新过程要有失败回退机制，不能因断电或异常变成砖；更新服务器要保持可用，别等漏洞爆发时平台已经停止运营；最重要的是，厂商要有一套明确的漏洞处理策略。

漏洞处理策略听起来虚，但会实实在在落到文档和流程上：有没有公开的漏洞披露渠道，比如安全邮箱、安全公告页面？收到漏洞报告后，计划在多少天内响应、评估、出修复版本？对已投放市场的设备，承诺提供多长时间的安全支持期？这些都会被写入安全评估报告。

软件物料清单（SBOM）在漏洞管理中的作用也会被放大。没有SBOM，就答不好“这一版固件里用了哪些第三方组件、这些组件有哪些已知漏洞、我们做了哪些处理”这个连环问题。很多公司被问到时才临时去整理，结果漏掉一堆藏在老版本库里的风险项。

3.5 默认安全状态与攻击面收敛

“开箱即用”的安全性，是EN 18031-1反复强调的理念。默认配置不能为了方便牺牲安全：出厂时默认关闭远程管理端口；默认不开放调试接口；默认不向第三方平台推送数据，除非用户明确配置。理由很朴素，绝大多数消费者不会去改默认设置，如果默认配置存在明显安全弱点，安全风险就是系统性的，而不是个例。

攻击面收敛还包括物理接口暴露。USB口、UART调试口、JTAG口在产品发布后仍然保留，需要有充足理由和访问控制方案。还有一个容易忽略的细节：固件里不能把敏感调试信息直接打进日志，否则泄露的日志一旦被拿到，密钥、Token、用户数据可能一起暴露。

3.6 日志、监测与事件响应

日志系统不是所有设备都有条件做，但如果做了，标准会期望日志内容能够支撑安全事件回溯。日志至少应该覆盖登录成功与失败、配置变更、固件更新、异常重启等关键事件，并且应防止日志被普通用户随意清除或篡改。

事件响应方面，需要结合产品实际形态设计。设备暴露在公网上时，有没有手段在安全事件发生后远程关闭服务或强制设备下线？有没有渠道通知用户采取行动？这些不一定要做成复杂的云平台，但要在安全文档里提供明确可行的方案，而不是一句“暂无相应机制”草草带过。

把这一章连起来看，EN 18031-1的评审绝不是“跑一个测试软件，输出Pass/Fail”那么简单，它更像是对一个产品安全工程能力的综合审查。文档、流程、测试、供应链管理都在审查范围内，文档和设计流程的权重会比很多人预想的高很多。

4. 合规落地：从差距分析到CE标识更新的完整链路

4.1 差距分析怎么做

拿到EN 18031-1后，第一件事不是急着找实验室，而是先做一次内部差距分析。建议按标准的主要安全目标建一张自查表，逐项给出现状、证据位置、缺失项和负责人：

这张自查表在后续技术文档里可以直接作为“安全设计说明”的目录骨架，节省大量整理时间。

4.2 技术文档需要承载哪些内容

在RED框架下，技术文档是符合性声明的基础。EN 18031-1的引入让技术文档的内容要求大幅增加。一份能顺利通过审阅的文档，通常要包含：产品描述和预期用途；威胁模型与风险评估记录；安全目标以及对应的保障措施；实现细节，比如硬件安全能力、软件架构、密钥管理流程；测试报告，包括功能测试、安全性测试、漏洞扫描；SBOM与第三方组件清单；漏洞处理流程和安全支持期说明。

小团队常问这些文档自己做还是请顾问。如果内部没有懂安全设计的工程师，第一次建议请外部顾问带一轮，核心价值是把标准语言翻译成研发团队能听懂的设计任务。后续固件迭代时，就可以由内部团队自行维护文档，不至于每次都抓瞎。

4.3 自声明还是需要通知机构

RED指令下最常用的符合性评估路径是内部生产控制（Module A），也就是自我声明。前提是制造商完全采用了协调标准。既然EN 18031系列已经是协调标准，绝大多数设备在纸面上可以走自声明路线，不强制送样到通知机构（Notified Body）发证。

但有两个现实问题需要注意。第一，如果设备没有完全采用EN 18031，或者声称采用但存在未覆盖的要求，市场监督机构有权要求更严格的评估，甚至要求通知机构介入；第二，某些特定类别的设备，或者在市场抽检中被列为重点监管对象的产品，可能需要提供更充分的评估证据。所以“自声明”不等于“自己说了算”，证据链仍然要完整、可追溯。

4.4 测试验证与实验室选择

即便不走NB发证，很多厂商依然会选择第三方实验室参与预测试或正式测试。原因很实际：客户和渠道商往往要求一份看得见的报告；实验室也能从独立视角帮团队发现已经“看习惯”的危险设计。

选实验室时建议直接问三个问题：是否具备EN 18031系列相关测试能力？是否有消费类物联网设备的安全评估经验？能不能针对你的威胁模型给出定制化测试计划而不是套模板？能做传统射频和EMC的实验室很多，但懂威胁建模、固件逆向、通信协议安全测试的团队没那么多，选择时值得多花点时间背调。

4.5 更新DoC、CE标识与时间规划

如果评估后发现需要整改，常见周期大致是：文档整理4到8周，研发整改8到16周，测试验证2到6周，具体视产品复杂度浮动很大。整个流程建议至少预留6个月。如果涉及到重新布板或更换主控芯片，按一年规划并不夸张。

完成评估后，要更新EU符合性声明（DoC），在其中明确引用3.3(d)(e)(f)及对应的协调标准编号。CE标志本身不需要重新设计，但包装和说明书中关于网络安全支持周期的信息需要同步更新。这个问题如果不处理，在市场监管抽检中可能被单独挑出来。

5. 在实操中容易踩的坑，以及我个人的处理经验

5.1 默认口令必须当合规缺陷处理

我遇到过不止一家客户，产品说明里白纸黑字写着“默认用户名admin，默认密码123456，建议用户首次登录后修改”。在EN 18031-1的语境下，这属于典型高风险项。别指望说明书里那句“建议修改”能当挡箭牌，评估人员看的是出厂状态的安全性，不是事后补救的可能性。更麻烦的是，这类问题往往在测试后期才暴露，一旦要改会造成产品逻辑和说明书同步修改，牵一发动全身。

5.2 第三方组件和SBOM的连锁影响

很多产品的安全风险不来自自研代码，而来自第三方组件。前几年Log4j漏洞爆发时，大量联网设备中招，根源就是SBOM缺失，没人能清楚知道自己的产品在哪个版本里用了存在漏洞的库。EN 18031-1评估时，审核人员会抽查SBOM的更新记录，看你对第三方依赖是否有基本的管理机制。别心存侥幸，这个问题绕不过去，早建SBOM早安心。

5.3 安全支持期没人认领

“产品卖出之后，安全更新跟到什么时候？”这个问题，很多公司都回答不上来。常见状态是售后团队觉得是研发的事，研发团队觉得销售已经出货跟自己没关系，最后安全支持策略写得极其模糊。标准希望看到的是明确的生命周期管理机制、承诺的支持期限、以及让用户获取安全公告的渠道。建议产品立项时就把“安全支持期多长”写成一条硬性参数，跟成本、上市时间一起评审。

5.4 时间规划太乐观，是最常见的翻车原因

最常见的坑是客户以为一个月就能搞定。很多产品的固件架构没有为安全更新和密钥管理预留空间，临时做安全启动意味着换Bootloader甚至换主控，不是修几个Bug的事。我的一般建议是：全新产品在立项时就要把安全要求纳入设计输入；存量产品评估后如果发现硬件能力不足，该换方案就换方案，该重新流片就重新流片，别因为怕麻烦把合规风险拖到上市前爆发。

5.5 小团队低成本起步方案

预算和人力有限的小团队，可以先从五件事起步：第一步，建一份最简单的SBOM并跟着固件版本维护；第二步，强制默认安全设置，关闭调试口和远程管理端口；第三步，给OTA升级加上签名校验，并把失败回退做好；第四步，设置公开的安全联系邮箱，哪怕每周只看一次；第五步，做一份简洁的威胁分析文档，把产品可能面对的威胁、应对措施写清楚。这五件事不一定第一天就做到满分，但机制一旦建立，后续在EN 18031-1和CRA这两套体系里都会顺畅很多。

6. 别只盯着EN 18031：它和CRA等法规其实是同一盘棋

6.1 CRA（网络弹性法案）的覆盖范围更大

如果只看EN 18031，很容易产生“这是欧盟对无线电设备做的一次性动作”的错觉。实际上，欧盟的网络安全合规是递进式的组合拳。2024年正式生效的《网络弹性法案》（CRA）把安全要求扩大到了所有具备数字功能的联网产品，包括纯软件产品。CRA的全面强制义务要到2027年末前后才落地，但其中关于产品安全设计、漏洞管理、支持周期、技术文档的底层逻辑，与EN 18031高度一致。

换句话说，EN 18031很大程度上是“先头部队”。你现在为了EN 18031建起来的威胁建模、SBOM、安全更新机制、漏洞响应流程，到了CRA阶段基本都能复用。反过来，如果现在完全不动作，等CRA进入强制期再从头学起，成本会更高，市场压力也更大。

6.2 与GDPR、NIS2等法规的协同

EN 18031-2处理个人数据和隐私时，要求和GDPR保持方向一致；NIS2指令强调供应链安全和事件通报能力，也与EN 18031系列要求的漏洞处理流程同源。网络安全合规已经不是一个标准的问题，而是产品安全治理的问题。与其每次都按新法规临时补课，不如提前把流程建起来，让一套机制在不同法规之间复用。

6.3 全球市场的趋势也很清晰

欧盟之外，其他地区也在做类似的事情。美国联邦通信委员会面向消费物联网设备推出了网络安全标签计划，新加坡有网络安全标签计划，英国也在持续推行消费者物联网安全基线。虽然各地区的强制程度和具体要求不完全相同，但核心原则惊人一致：默认安全配置、安全的更新机制、漏洞处理流程、明确的支持周期。

做产品合规越久，我越觉得EN 18031-1本质上不是“认证新规”，而是一次产品安全能力的全面体检。标准条款只是最低要求，它真正推动的事情，是把研发、测试、供应链、售后这些本来可能各管一段的环节，串成一条对用户负责的线。这条线理顺了，后续面对任何新法规都不会太慌张。建议产品经理、硬件负责人、固件负责人和合规同事找个时间一起坐下来，至少先把三件事聊清楚：产品适用哪几册标准、当前差距在哪里、半年后的投放计划到底赶不赶得上。把这三个问题讨论明白，EN 18031-1这座山就算翻了一半。