工程师一句话：Annex U 是 Ed 6.0 的全新规范性附录，专门解决智能家电连上公共网络后的安全问题。它不是让所有联网家电都做全套网络安全测试——Clause 22.62 先帮你判定是否适用；适用的话，核心要求就三条：软件分区隔离、通信数据完整性保护、认证授权+密码学。
条款速查表
| 条款 | 核心要求 | 工程师关注点 |
|---|---|---|
| Clause 22.62 | 判定 Annex U 是否适用的入口条款 | 远程通信是否影响 Annex R 功能安全或 Clause 8-32 产品安全 |
| Annex U | 通过公共网络远程通信的器具，需防止未授权访问和传输故障损害标准合规性 | 不覆盖数据保密性和消费者隐私 |
| U.3.1 | 通信软件与安全软件必须分区/隔离 | 架构设计：通信模块 vs 安全核心模块的边界 |
| U.3.2 | 远程通信软件需提供数据完整性保护 | 防数据损坏、地址错误、时序混乱、自动重发、传输中断 |
| U.3.3 | 防护多源同时/顺序消息带来的危害 | 消息队列管理、冲突仲裁机制 |
| U.3.4 | 远程通信启用前必须经过认证和授权 | 双向认证 + 密码学技术确认双方身份 |
| U.3.5 | 防止未授权访问，检测传输故障/错误 | Table U.1 列出的可接受措施组合 |
| U.3.6 | 器具安全操作不得依赖远程通信 | 断网时器具必须仍能安全运行；本地UI优先于远程指令 |
| U.3.7 | 授权建立后，密码学技术提供数据完整性保护 | 算法必须在器具端执行，不能依赖路由器 |
| U.3.8 | 制造商通过远程通信推送的软件更新需验证 | 防通信损坏 + 版本兼容性检查 |
| U.3.9 | 每次软件安装需经器具责任人许可 | 可允许用户开启自动更新模式 |
| U.3.10 | 软件安装过程及安装后不得损害标准合规性 | 更新失败回滚、断电保护 |
适用范围判定：Clause 22.62 是入口
Annex U 并非对所有联网家电强制适用。Clause 22.62 是判定 Annex U 是否触发的关键门槛。
三种不适用场景（直接豁免 Annex U）
| 场景 | 说明 | 典型产品 |
|---|---|---|
| 软件独立 | Clause 8-32 的合规完全不依赖软件，全是硬件实现 | 传统机械温控电熨斗、基础电饭煲 |
| 仅单向发送 | 远程通信只发送数据/事件消息/推送监控，不接收外部命令或软件更新 | 智能电表、环境监测传感器 |
| 已充分分区 | 非安全软件与安全软件已物理或逻辑隔离，漏洞无法跨边界 | 双MCU架构：通信MCU + 安全MCU |
两种适用场景（必须执行 Annex U）
| 场景 | 说明 | 典型风险 |
|---|---|---|
| a) 影响安全软件 | 远程通信涉及 Annex R 功能安全软件下载/更新，或影响 Clause 8-32 合规的应用软件/参数传输 | OTA更新破坏了电机热保护算法；远程修改了洗衣机脱水转速导致温升超限 |
| b) 分区不当 | 远程通信只影响非安全软件，但非安全软件与安全软件之间隔离不充分，可能通过漏洞跨边界影响安全 | 通信模块被入侵后，通过共享内存篡改温控参数 |
工程师白话：Clause 22.62 就像一个"安检门"。如果你的产品只是单纯上报数据（比如每天发一次用电量），或者所有安全功能都是硬件实现的（比如双金属片温控器），那 Annex U 不管你的产品。但如果你的 OTA 升级包里有温控算法，或者 WiFi 模块和主控 MCU 跑在同一个处理器上且没有内存隔离，那就必须做 Annex U。
Annex U 核心安全框架
Annex U 的安全目标只聚焦信息安全模型中的两个维度：完整性（Integrity） 和 真实性（Authenticity）。它不覆盖保密性（Confidentiality）、不可否认性（Non-repudiation）和可用性（Availability）。
为什么不覆盖可用性和保密性？
- 可用性：公共网络本身不保证永远在线（断网、延迟、带宽不足）。标准要求器具在断网时仍能安全运行（U.3.6）。
- 保密性/隐私：数据加密和用户隐私属于法规合规（如 GDPR、RED 2014/53/EU Article 3.3、ETSI EN 303 645），不是产品安全（product safety）的范畴。
工程师白话：Annex U 只关心"坏人能不能篡改你的指令"和"这条指令是不是真的来自你家服务器"。至于"坏人能不能偷看你的数据"，标准说那是隐私法规的事，不归我管。
与 Annex R 的配合关系
Annex U 不是孤立存在的，它与 Annex R（软件评估） 紧密耦合：
| Annex U 条款 | 对应的 Annex R 要求 | 配合点 |
|---|---|---|
| U.3.1 软件分区 | R.3.2.2.1 软件架构分区 | 同一概念：通信软件与安全软件隔离 |
| U.3.2 故障控制 | Table R.1 / R.2 故障/错误条件 | 外部通信故障是 Table R.1 的组件 6 |
| U.3.8 更新验证 | R.3.3 软件验证 | OTA 更新流程需通过 Annex R 的软件安全验证 |
| U.3.10 安装合规 | R.3.2.2 软件架构规格 | 更新后的软件架构仍需满足 R.3.2.2 要求 |
实操建议：在型式试验时，Annex U 和 Annex R 通常由同一份软件安全文档覆盖。先按 Annex R 建立软件评估基础（架构、故障分析、验证方法），再在此基础上叠加 Annex U 的远程通信安全要求。
软件分区与隔离 (U.3.1)
要求：使能公共网络通信的软件，必须分区为独立模块，与满足标准其他条款所需的软件分离。
合规检查：通过检视（inspection）软件架构文档完成。
分区实现方式
| 方式 | 说明 | 优缺点 |
|---|---|---|
| 物理分离 | 通信功能和安全功能分别跑在两个独立处理器/MCU上 | 最安全，但 BOM 成本高 |
| 逻辑分离 | 同一处理器上通过操作系统分区（如 MPU/MMU 内存保护、TrustZone）隔离 | 成本适中，需软件架构设计 |
| 软件架构分离 | 同一处理器上通过模块化设计分离，无硬件保护 | 成本低，但需通过 Annex R 软件评估证明隔离有效性 |
工程师白话：最理想的方案是"通信 MCU + 安全 MCU"双芯片——WiFi 模块被黑了也碰不到主控。如果成本不允许，至少要用 MPU（内存保护单元）把通信任务和安全任务的内存空间隔开。单芯片裸奔的方案不是不行，但 Annex R 的软件评估会很难通过。
通信安全机制：完整性与认证授权 (U.3.2–U.3.7)
数据完整性保护 (U.3.2 / U.3.3)
U.3.2 要求：远程通信的建立、执行和终止，必须由器具通过软件完成，且该软件需提供以下数据完整性保护：
| 威胁类型 | 防护措施 | 工程师实现思路 |
|---|---|---|
| 数据损坏 | CRC、校验和、哈希 | 每条消息带 CRC-32 或 SHA-256 摘要 |
| 地址损坏 | 源/目的地址验证 | 检查消息头中的设备 ID 和端点地址 |
| 时序/顺序错误 | 序列号、时间戳 | 消息带递增序列号，丢弃乱序/过期包 |
| 永久自动重发 | 超时 + 反馈确认 | 请求-应答机制，无 ACK 不重复发送 |
| 传输中断 | 连接状态监控 | 心跳包检测，断链后进入安全状态 |
U.3.2 额外要求：软件必须能检测并响应以下异常通信：
- 消息不完整或截断
- 消息含错误
- 消息格式正确但内容超出该消息类型的预期范围
U.3.3 要求：防护来自多个源同时或顺序发送消息带来的危害。
工程师白话：数据完整性就是"防篡改"。你的智能烤箱收到一条"设置300°C"的指令，必须能确认这条指令在传输过程中没被改成"500°C"，也不是一条被黑客重复发了100遍的旧指令，更不是来自一个伪装成你家服务器的恶意设备。
认证、授权与密码学 (U.3.4 / U.3.7)
三阶段访问控制
| 阶段 | 要求 | 标准条款 |
|---|---|---|
| 认证 (Authentication) | 通信双方通过密码学技术确认彼此身份 | U.3.4 |
| 授权 (Authorization) | 认证通过后，才允许启用远程通信 | U.3.4 |
| 数据完整性保护 | 授权建立后，密码学技术保护传输数据的完整性 | U.3.7 |
关键约束
- 认证前不算远程通信：为准备认证和授权过程而进行的双方握手通信，不被视为远程通信（U.3.4 注）。
- 密码学必须在器具端执行：不能依赖路由器或外部设备完成加密/签名（U.3.7）。
- 密码学技术无白名单：标准未指定具体算法，但要求采用"全球公认、尚未发现漏洞"的算法。常见选择包括：
- 对称加密：AES-128/256
- 非对称加密：RSA-2048、ECC P-256
- 哈希/签名：SHA-256、HMAC-SHA256
工程师白话：你的智能空调在接收远程指令前，必须先"验明正身"——确认对方真的是你家 App 的服务器，而不是隔壁黑客的笔记本。这个验证过程必须用密码学（比如 TLS 1.2+ 双向证书认证），而且加密解密必须在空调自己的芯片里完成，不能指望路由器帮你做。
软件更新安全 (U.3.8 / U.3.9 / U.3.10)
U.3.8：更新包验证
制造商通过远程通信推送的软件更新，在安装前必须验证：
- 通信完整性：更新包在传输过程中未被损坏（CRC/哈希/签名验证）
- 版本兼容性：更新包与目标器具型号/硬件版本匹配
- 故障控制：执行上述验证的软件本身需能控制 Table R.1 规定的故障/错误条件
U.3.9：用户许可
- 每次软件安装必须获得器具责任人的明确许可
- 允许用户一次性开启"自动更新"模式，但首次必须手动确认
U.3.10：安装安全
- 安装过程中不得损害标准合规性
- 安装后不得损害标准合规性
- 建议实现：断电保护、更新失败回滚、双区备份（A/B 分区）
工程师白话：OTA 升级是 Annex U 的高风险场景。标准要求你的升级包必须"验明正身+验明完整+验明对口"，而且用户必须点头同意。升级过程中如果断电，器具不能变砖，更不能变成"失控加热器"。A/B 分区升级（后台下载新固件到 B 区，验证通过后重启切换）是目前行业最佳实践。
传输故障防护措施 (Table U.1)
Table U.1 是 Annex U 的实操核心，列出了 7 种传输故障/威胁模式，以及 7 类可接受的防护措施。
威胁模式与典型措施组合
| 威胁模式 | 推荐措施组合 | 实现示例 |
|---|---|---|
| 重复消息 (重放攻击) | 序列号 + 超时 | 每条消息带递增 Seq，服务器/器具记录最近 N 个 Seq，重复则丢弃 |
| 消息删除/丢失 | 超时 + 反馈消息 | 心跳包 30s 一次，3 次未响应则断链告警 |
| 非法插入消息 | 源/目的标识符 + 识别程序 + 密码学 | 仅接受来自白名单设备 ID 且签名验证通过的消息 |
| 消息顺序错乱 | 序列号 + 时间戳 | 带时间窗口的序列号检查，过期/乱序包丢弃 |
| 数据损坏/篡改 | 安全代码 (CRC) + 密码学 (哈希/签名) | 消息体附 HMAC-SHA256，接收端重新计算比对 |
| 消息延迟 | 超时 | 指令带时间戳，超过允许延迟则视为无效 |
| 未授权访问/伪装 | 源/目的标识符 + 识别程序 + 密码学 | 双向 TLS + 设备证书 + 用户 Token |
工程师白话：Table U.1 不是让你逐条打勾，而是让你根据产品风险选措施。一个带 WiFi 的智能烤箱，至少要有：序列号防重放 + 超时防丢包 + HMAC 防篡改 + 双向认证防伪装。纯蓝牙的遥控器可能风险低一些，但核心逻辑一样。
Annex U 与欧盟网络弹性法案 (CRA) 的关系
工程师白话：Annex U 是产品安全标准里的"网络安全补丁"，只保安全不保隐私。Cyber Resilience Act (CRA)是欧盟法律，管的是所有带数字元素的产品能不能进欧洲市场。两者不冲突，但各管各的——做智能家电出口欧盟，Annex U 和 CRA 都要过。
定位差异：产品安全 vs 网络安全法规
| 维度 | IEC 60335-1 Annex U | EU Cyber Resilience Act (CRA) |
|---|---|---|
| 法规性质 | 产品安全标准 (Product Safety Standard) | 欧盟法规 (Regulation EU 2024/2847) |
| 管辖目标 | 防止远程通信损害产品安全合规性 | 确保数字元素产品全生命周期的网络安全 |
| 安全维度 | 完整性 (Integrity) + 真实性 (Authenticity) | 保密性 + 完整性 + 可用性 + 隐私保护 |
| 生效时间 | 2020 (Ed 6.0) | 2024-12-10 生效；2027-12-11 全面实施 |
| 违规后果 | 型式试验不通过，无法获得 CB/CE-LVD 证书 | 最高 €1,500 万罚款或全球年营业额 2.5% |
| 协调标准 | 不适用（本身是标准条款） | 依赖 CEN/CENELEC/ETSI 制定的 41 项协调标准 |
CRA 核心要求速览
CRA 适用于所有在欧盟市场销售的带数字元素的产品 (Products with Digital Elements, PDE)，智能家电自然在其列。制造商必须满足以下核心义务：
| 义务 | 要求要点 | 对智能家电的直接影响 |
|---|---|---|
| 安全设计 (Secure by Design) | 产品在设计、开发、生产阶段即嵌入网络安全 | 硬件选型需考虑安全启动 (Secure Boot)、安全存储 |
| 漏洞管理 | 持续识别、记录、修复漏洞；发布协调漏洞披露 (CVD) 政策 | 需建立漏洞监控流程，产品上市后持续跟踪 CVE |
| SBOM 透明 | 提供机器可读的软件物料清单 (CycloneDX/SPDX 格式) | 固件中所有开源/第三方组件必须可追溯版本 |
| 安全更新 | 免费安全更新至少覆盖产品预期寿命或 5 年（以较长者为准） | OTA 更新机制必须长期维护，不能卖完就不管 |
| 漏洞报告 | actively exploited 漏洞 24 小时内向 ENISA 报告 | 2026-09-11 起生效，需建立 24h 应急响应流程 |
| CE 标志 | 产品须加贴 CE 标志方可进入欧盟市场 | 2027-12-11 后，无 CE 标志的智能家电将被禁售 |
为什么两者都要满足？
Annex U 和 CRA 不是"二选一"，而是叠加关系：
- Annex U 解决的是"产品安全"问题——确保黑客不能通过网络篡改你的烤箱温度设定，导致火灾或烫伤。它是 LVD (低电压指令) 协调标准 IEC 60335-1 的一部分，通过 Annex U 才能获得 CE-LVD 合规推定。
- CRA 解决的是"网络安全"问题——确保你的产品在整个生命周期内不会成为僵尸网络的一员，不会泄露用户隐私，不会在被发现漏洞后无人修复。它是独立的横向法规，与 LVD、RED、EMC 等指令并行适用。
通俗比喻：Annex U 像是汽车的安全气囊标准（出了事故要保护人），CRA 像是汽车的网络安全标准（防止黑客远程控制刹车）。两者都管车，但管的是不同层面的风险。
协调标准进展与家电行业的关联
欧盟委员会于 2025-02-03 向 CEN/CENELEC/ETSI 发出标准化请求 (M/606)，要求制定 41 项协调标准：
- 15 项横向标准：覆盖所有 PDE 的通用安全要求（如安全设计、漏洞处理、SBOM 格式）
- 26 项纵向标准：针对特定产品类别（包括智能家居、可穿戴设备、工业控制系统等）
对家电制造商而言，以下现有标准最可能被采纳为 CRA 协调标准：
| 标准 | 内容 | 与 Annex U 的交集 |
|---|---|---|
| ETSI EN 303 645 | 消费者物联网网络安全 | 覆盖认证、完整性、更新安全，与 Annex U 技术要求高度重叠 |
| IEC 62443-4-1 / 4-2 | 工业自动化系统安全开发生命周期 / 组件安全 | 安全开发流程要求可补充 Annex U 的软件评估 |
| EN 18031 系列 | 无线电设备网络安全评估（RED 2022/30 配套） | 技术措施与 CRA Annex I 的 (2)(a)–(2)(m) 对应 |
关键提示：截至 2025 年底，CRA 协调标准尚未正式发布。在协调标准缺位期间，制造商可通过 Common Specifications (CS) 或 欧盟网络安全认证方案 来证明合规。IEC 60335-1 Annex U 本身不是 CRA 的协调标准，但其技术措施（完整性保护、认证授权、更新验证）可直接用于满足 CRA 的部分技术要求。
给出口工程师的实操对照表
| 工作项 | Annex U 要求 | CRA 要求 | 建议合并做法 |
|---|---|---|---|
| 软件分区 | U.3.1 通信/安全软件隔离 | 安全设计、最小攻击面 | 同一套架构文档，同时满足两者 |
| 认证授权 | U.3.4 / U.3.7 双向认证+密码学 | 身份认证与访问控制 | TLS 1.3 + 设备证书，一鱼两吃 |
| OTA 更新 | U.3.8–U.3.10 验证+许可+回滚 | 安全更新机制、5 年支持 | 签名验证 + A/B 分区 + 版本追溯 |
| 漏洞响应 | 无直接要求（通过 Annex R 间接覆盖） | 24h 报告 ENISA + CVD 政策 | 建立产品安全事件响应团队 (PSIRT) |
| 软件透明 | 无要求 | SBOM (CycloneDX/SPDX) | CI/CD 中集成 SBOM 自动生成 |
| 合规标志 | 通过 IEC 60335-1 获得 CE-LVD | 单独 CE 标志（CRA 专用） | 2027 年后产品须同时满足 LVD+CRA 双 CE |
工程师白话：如果你只做国内市场，Annex U 就够了。但如果你要出口欧盟，2027 年之后 CRA 是硬门槛——没有 CE 标志（CRA）的智能家电会被海关拦下。好消息是，Annex U 做的很多工作（双向认证、OTA 签名、软件分区）可以直接复用到 CRA 合规上，不用从头再来。
给工程师的 3 条实操建议
1. 尽早做 Clause 22.62 适用性判定
很多项目在最后阶段才发现 Annex U 适用，导致软件架构需要返工。建议在立项评审时就回答三个问题：
- 产品是否有公共网络远程通信？
- 软件是否参与 Clause 8-32 的安全合规？
- 通信软件与安全软件是否在同一处理器上且未隔离？
如果三个问题中后两个都为"是"，Annex U 适用，需在软件需求规格书中预留安全分区设计。
2. 密码学实现要"在器具内、在传输前"
U.3.7 明确要求密码学操作必须在器具端完成，不能外包给路由器或云端。这意味着：
- 如果通信模组（WiFi/BLE）是外购的，要确认模组是否支持在器具主控端做签名/验签
- TLS/SSL 终止在器具端，而不是在通信模组端
- 设备证书和私钥必须存储在器具的安全存储区（如 OTP、Secure Element、TEE）
3. 型式试验时准备"断网测试"
U.3.6 要求安全操作不依赖远程通信。认证实验室在测试时，可能会：
- 在 Clause 11 发热测试中屏蔽 WiFi 信号，验证器具是否仍按设计参数运行
- 在 Clause 19 非正常测试中断开网络，验证保护电路是否仍能正常动作
- 检查本地物理按键/旋钮的优先级是否高于远程 App 指令
建议在送检前内部做一轮"断网安全测试"，确保本地安全逻辑完全独立。