关于物联网安全与隐私的国家标准草案目前正在征求意见。文件暂编号为TCVN XXXXX:2026，标注”第1版”，名称为《网络安全 – 物联网安全与隐私 – 设备基本要求》。据前言，该标准与ISO/IEC 27402:2023完全相同，由政府密码局起草、国防部部长建议、国家计量质量标准化委员会审定、科学技术部公布。
这对物联网设备制造企业（摄像头、智能门锁、传感器、联网家电、路由器、工业远程监测设备）以及检测与认证机构都值得关注：越南首次具备一套可作为物联网设备网络安全合格评定参照的基础要求。草案约20页，含5条、1个资料性附录与26项参考文献。
一、草案是什么，处于什么阶段
这是草案国家标准：标准号留空（XXXXX），不具有适用效力，内容在公布前可能调整。采用的方式是整体采纳国际标准：”与ISO/IEC 27402:2023完全相同”。
值得注意的是，本草案由政府密码局起草、国防部建议，与我们此前分析的多数产品类TCVN草案（通常由标准质量院下设技术分委员会起草）不同。这反映了领域属性：设备网络安全类标准属于密码主管机构的职责范围。
二、本草案为何值得关注
三点。第一，这是横向标准：不针对某一产品，而适用于各类物联网设备，从消费类到工业类。第二，标准不规定具体技术配置，而是要求一套过程：在设备层级开展风险评估、将结果形成文件、向用户披露信息，并实现相应安全功能。因此它要求的是一份档案，而不仅是产品。第三，它被设计为可供医疗、金融、工业、消费电子、交通运输等垂直领域扩展的基础要求，可能成为多个合格评定项目的共同底座。
三、标准的用法与相关方
标准为物联网设备提供基础的信息通信技术要求，使其能够支持安全与隐私控制措施。草案”补充信息”明确：物联网设备开发者、系统集成商、进口商、零售商或监管机构等相关方均可以开展此类风险评估。
本质上，标准区分了角色：设备开发者负责文件与设备功能，用户组织负责在其系统中部署控制措施。草案也指出，若物联网设备不具备相应的支持功能，ISO/IEC 27400中的控制措施就无法实施，这正是本标准存在的理由。
四、文件结构
草案包含：前言；引言；第1条适用范围；第2条引用文件；第3条术语、定义与缩略语（13条定义、12个缩略语）；第4条概述；第5条要求；附录A（资料性）风险管理指南；以及参考文献目录。
第5条为分量最重的部分，分为两支：5.1物联网设备策略与文件要求，涵盖风险管理、信息披露、漏洞披露与处理；5.2物联网设备能力与运行要求，涵盖七组：配置、软件重置、用户数据删除、数据保护、接口访问、软件与固件更新、用户通知。
五、引用文件与参考文献
草案仅引用三份文件，其中两份已有TCVN版本：
- TCVN ISO/IEC 27000:2019（ISO/IEC 27000），信息技术 – 安全技术 – 信息安全管理体系 – 概述与词汇；
- ISO/IEC 27400:2022，网络安全 – 物联网安全与隐私 – 指南；
- TCVN ISO 31000:2020（ISO 31000:2018），风险管理 – 指南。
参考文献目录共26项，可见起草背景。其中值得注意的有NISTIR 8259与NISTIR 8259A（美国NIST关于物联网设备基础网络安全活动与核心能力基线的文件）、面向消费设备的ETSI EN 303 645、面向工业设备与系统的IEC 62443-4-1与62443-4-2、关于漏洞披露与处理流程的ISO/IEC 29147与ISO/IEC 30111，以及关于密码模块安全要求的ISO/IEC 19790。仅保留三项规范性引用、同时指向这些大型标准体系，是合理的做法：约束性内容保持精简，参考部分留给需要深入的读者。
六、阅读第5条前需要掌握的术语
第3条定义了13个术语，多引自ISO/IEC标准。与要求部分最相关的术语如下：
| 术语 | 草案中的核心内容 |
|---|---|
| 物联网设备 | 物联网系统中通过传感或执行与物理世界交互与通信的实体；是已完成装配、无需嵌入其他产品即可用于其预期物联网功能的设备 |
| 物联网系统 | 提供物联网功能的系统；可包括物联网设备、物联网网关、传感器与执行器，以及云与网络连接 |
| 物联网网关 | 将一个或多个邻近网络及其上的物联网设备与一个或多个接入网络相连的实体 |
| 物联网设备开发者 | 创造出已完成装配的物联网设备的实体 |
| 可信计算基（TCB） | 计算机系统内全部防护机制，含硬件、固件与软件，其组合负责执行安全策略 |
| 关键安全参数（CSP） | 其泄露或修改可能削弱密码模块安全性的信息；例如保密密钥与私钥、口令等鉴别数据、PIN、证书及其他信任锚 |
| 敏感安全参数（SSP） | 关键安全参数与公开安全参数 |
| 制造商默认状态 | 设备恢复出厂设置后或完成生产/装配后的状态 |
| 故障安全模式 | 发生故障时，以不损害或尽量减轻对其他设备损害、且不危及或尽量降低对操作人员危险的方式作出响应 |
缩略语包括API、ASLR、CPU、CSP、ICT、IoT、PIN、PSP、RoT、TCB、SWID、XML。其中两个因出现在建议条款中而尤为重要：ASLR（地址空间布局随机化）与RoT（信任根）。
七、风险管理要求
第5.1.1条是标准最具特色的部分，也最容易被忽略。主要内容：
- 物联网设备必须有文件记录在设备层级开展的风险评估结果，且置于系统层级风险评估的背景中；
- 该过程必须考虑预期用例的预期结果，以及相关方（例如设备所接入网络上的各方）的需求与期望，包括非预期的物理与逻辑影响；
- 风险评估必须考虑物联网设备可能受到资源限制（电池受限、内存少、CPU较弱），因为这会影响风险处置方式；
- 文件必须在产品受支持的生命周期内可获取。
补充建议指出，风险评估与处置过程宜遵循广泛认可的方法，如ISO 31000中的方法，附录A给出了应用指南。
八、风险评估与处置的九个步骤
第5.1.1.1.5条列出必须确定并实施的九个步骤。这部分可直接作为编制档案的检查清单：
- 确定不同产品是否需要各自独立的风险评估与处置过程；
- 依据风险评估结果选择适用的风险处置方案；
- 确定实施所选方案所需的全部控制措施；
- 由上述控制措施确定物联网设备的全部安全与隐私功能；
- 将所确定的功能与5.2中的功能对照，核实未遗漏必要功能；
- 编制适用性声明，包含必要功能以及5.2中各功能纳入与排除的理由；
- 如使用其他针对设备的标准，在完成a)至f)后落实这些标准的要求；
- 编制风险处置计划；
- 将风险处置计划与剩余风险告知风险所有者，或（适用时）取得其对计划的批准与对剩余风险的接受。
草案在注中说明：5.2包含的是基础功能清单，并非完整清单，视垂直细分市场或更高风险用例，可能需要更多功能与控制措施。要求编制载明排除理由的”适用性声明”，正是本标准与普通技术检查表的区别：它促使开发者作出说明，而不仅是填写”有/无”。
九、信息披露要求
第5.1.2条规定三项要求：物联网设备必须有用户文件列出设备为支持安全与隐私控制所提供的功能，并明确指出5.2中是否有任何要求未被包含；该信息必须在设备受支持期间公开可获取；设备必须随附安全支持政策及其他支持文件，其中就停止提供安全更新的时点向用户作出事先通知。
补充建议更为具体，也是评估中最常被追问之处：信息宜在首次销售时即提供；购买后宜给出指引（可作为安装过程的一部分），提示未来事件（如软件更新）并提供让用户接收后续联系信息的方式；公布的支持期限宜与产品风险与预期寿命相匹配，并且宜避免变更已公布的支持期限，因为这会打乱用户的规划周期；设备文件宜说明用户如何得知支持期限是否在公布后发生变更。
另一点值得注意：草案要求提供设备所依赖的第三方软件组件信息（涉及其安全性的部分），并指出可以机器可读格式提供，采用软件识别标签（SWID）（见ISO/IEC 19770-2）。这与多个市场日益推行的软件物料清单（SBOM）要求相近，尽管草案未使用该术语。
十、漏洞披露与处理
第5.1.3条含两项要求：物联网设备必须有文件规定在受支持生命周期内适用的漏洞披露与处理过程；这些过程至少必须包含接收公众提交潜在漏洞报告的能力。补充建议指出宜按ISO/IEC 29147（漏洞披露）与ISO/IEC 30111（漏洞处理流程）实施。
“接收公众报告”看似轻，但实际上要求具备接收渠道、分类流程与响应承诺。对中小企业而言，这往往是实施该标准时的第一个硬缺口。
十一、设备能力七组要求
第5.2条细化所需功能。其结构值得注意：每个子条均分为”要求””补充建议”与”补充信息”，唯独5.2.8只有”信息”部分。下表仅取”要求”部分，概述各组核心要求：
| 组别 | 草案中的核心要求 |
|---|---|
| 配置 | 若配置设置可修改，仅授权实体可修改；设备仅在获得授权时才可更改其他设备的配置 |
| 软件重置 | 若设备可被重置，该过程必须安全，且仅可由授权实体执行 |
| 删除用户数据 | 若设备存储用户数据，必须提供在任意类型存储器中删除相应用户数据的功能，并限于授权实体 |
| 数据保护 | 必须保护存储与传输的数据免遭未授权访问、修改与泄露；范围须包括配置、身份数据、用户数据、事件日志与敏感安全参数；必须保护软件与固件；必须使用密码技术 |
| 接口访问 | 必须限制对接口的逻辑访问，仅授权实体可访问；必须采用适当的鉴别与访问控制机制；必须在投入使用前将关键安全参数的通用值替换为每台设备唯一的值 |
| 软件与固件更新 | 更新必须通过安全流程实施，且仅由授权实体发起；更新被突然中断时，设备必须进入尽量减轻潜在危害的状态 |
| 用户通知 | 本条只有”信息”部分，描述通知用户的情形与方式，未设编号技术要求 |
十二、前三组：配置、重置与数据删除
这三组共用同一模板：”若”条件加”授权实体”要求。配置仅可由授权实体修改；重置仅可由授权实体执行；删除用户数据亦然。草案注明”授权实体可以是人员或另一台设备”，即该要求并不预设必须有口令，而是必须有可验证的授权机制。
软件重置的补充信息给出一个技术上的重要理由：有时漏洞是通过更改配置修补的，但若设备随后被恢复为制造商默认状态，漏洞可能再次被利用。典型例子是：现有配置被修改以阻止使用不安全的密码套件，而制造商默认状态却允许全部套件。对合格评定而言，这意味着需要检查两种状态，而不只是运行中的状态。
关于用户数据删除，草案坦率指出取舍：删除超过某一用户所需的更多数据可能是可接受的，但可能导致数据保存时间超过必要期限，因此宜在有正当理由时才这样做。草案还指出，用户期望删除适用于整个物联网系统（移动应用、云），而不只是设备本身。
十三、数据保护
这是技术要求最重的一组。除上表四项要求（保护存储与传输的数据；范围涵盖配置、身份数据、用户数据、事件日志与敏感安全参数；保护软件与固件免遭未授权访问与修改；使用密码技术）外，建议部分列出一系列措施：
- 设备启动时宜检查软件与固件的完整性与真实性；若检查未通过，设备宜通知用户、转为不可运行状态、进入故障安全模式，或在能够安全执行的情况下启动设备恢复过程；
- 首次安装或维护时，设备宜建立安全的默认配置；面向用户的配置选项宜阻止选择不安全配置，或给出适当警告；
- 在可能时，设备宜提供分区功能；使用功能模块限制对系统资源的访问；并把可信计算基（TCB）保持得尽可能小，以减少暴露面；
- 在适用处宜采用内存保护机制，如内存安全语言、栈保护（stack canaries）、地址空间布局随机化（ASLR），以及限制或禁止可执行权限；
- 事件日志宜对每个事件记录足够细节，使授权实体能够识别异常事件并有意义地分析数据；设备与日志宜与权威系统同步，或在数据已适当去标识的情况下转发至集中存储；
- 风险评估结果宜帮助判断设备是否可采用硬编码或共享的敏感安全参数，前提是这些参数对每台设备唯一且不具普遍性。
补充信息解释了硬件的作用：集成密码加速器、基于硬件的信任根（RoT）与硬件支撑的验证启动等方案有助于保护密钥与平台完整性；可信平台模块（TPM）被列为硬件信任根的示例，可支持以密码方式绑定的设备标识与接口访问。草案也指出一个实际例外：在安全关键应用中，持续运行至关重要，此时完整性检查与恢复模式可能并不适用。
十四、接口访问与标识
第5.2.6条含四项要求：具备限制对设备接口逻辑访问、仅授权实体可访问的机制；采用适当的鉴别与访问控制机制；在设计并实现与标识的创建和使用相关的功能时评估安全与隐私要求；并确保关键安全参数的通用值（如共享私钥或标准口令）在设备投入使用前被替换为每台设备唯一的值，或由适当的外部实体明确确定。
最后一项是常见但仍常被忽视的检查点：所有设备共用同一默认口令是低价物联网设备的常见缺陷。草案加了一条简注：”风险评估是判断此处何为’适当’的依据。”
建议部分补充了合格评定方常追问的内容：设备宜可被逻辑识别，但宜避免创建或使用持久标识，除非不可避免，且存在时宜向用户说明；逻辑访问限制宜覆盖通过软件或硬件方式启用或禁用任何接口（含本地与网络）、对全部远程接口限制访问（例如通过鉴别），以及识别或阻止不受支持的设备尝试访问接口的能力；所有输入输出数据宜按长度、字符类型、可接受取值或范围及消息格式进行校验；宜遵循安全编程实践，包括使用类型安全语言，若不可行则仍须进行边界检查、使用安全类型与安全字符串处理函数；在过滤数据时宜使用允许清单而非拒绝清单。
十五、软件与固件更新
三项要求：更新必须通过安全流程实施；仅可由授权实体发起；更新被突然中断时，设备必须进入尽量减轻潜在危害的状态，并考虑设备未按预期运行时产生的风险。
建议部分详细到可作为更新流程的检查清单：在安装前确认更新的有效性、真实性与完整性的方式；配置选项包括自动更新启用或禁用、远程更新的下载与安装为自动还是手动、自动下载与安装的排程方式，以及是否有更新通知（以及通知谁或通知什么）。草案还指出设备宜支持自动更新，并宜有周期性流程检查是否有新的安全更新，若有则通知用户。
技术层面，草案建议在安装前验证更新的真实性与完整性，可采用数字签名与公钥基础设施，并保护更新基础设施尤其是私钥管理；宜考虑利用硬件信任根能力度量与验证软件、固件更新的有效性；宜通过安全启动机制验证软件，若发现未授权更改，则向用户或本地hub/物联网网关告警，并终止除发送告警或启动设备恢复之外的一切网络通信。草案指出，撤销更新或回退到较早版本可用于从中断的更新中恢复，并且更换硬件是实施更新的一种正当且可接受的方式。
十六、用户通知与附录A
第5.2.8条在结构上不同：只有”信息”部分，没有编号要求。内容指出，设备就多种情形通知用户可能是必要或有益的，标准中若干建议描述了这类情形。草案也承认实际状况：部分物联网设备无法主动通知用户（显示消息、发出声光），但可在被查询或远程访问时以消息回应；不能直接通知的设备可通过本地hub发送通知，或发送至物联网系统中的报警、监测或日志设备。
附录A为资料性附录，提供风险管理指南，依次引用TCVN ISO 31000:2020（ISO 31000:2018）第6.4.1、6.4.2、6.4.3、6.4.4、6.5.1、6.5.2、6.6、6.7条，对应风险识别、分析、评价、处置、监视与评审、记录与报告。值得注意的是，A.5列出风险处置方案：规避风险、进一步分析、重新审视目标、消除风险源、分担风险（合同、保险），以及在充分知情下接受风险。A.7另增一项实务做法：组织宜建立、记录并维持用于收集与核实物联网设备信息的体系，同时收集并审视市场上类似产品的公开信息，再评估其对设备可信度的相关程度。
十七、阅读草案时需留意六点
第一，区分”必须”与”宜”。草案明确划分三层：”要求”（使用”必须”，属合格评定内容）、”补充建议”（使用”宜”）与”补充信息”。实践中许多争议源于把建议内容当作要求，或因为条款看起来像指引而忽略其中的要求。
第二，5.2.8没有要求。“用户通知”是5.2中唯一只有信息部分的子条。因此与用户通知相关的义务体现在其他条款的建议中，例如检测到未授权更改时的告警、有更新时的通知。
第三，本标准不是技术法规。它是TCVN，属自愿适用。强制性义务（如有）来自技术法规、风险类别货物清单或具体认证项目的要求。应将本草案放在质量管理整体框架中理解，而不应推断TCVN本身创设义务。
第四，”完全相同”意味着译文须忠实。由于整体采纳ISO/IEC 27402:2023，越南语术语的表述直接影响档案与国际文本的对照。发生争议时，宜比对英文原文，尤其是”authorized entity””factory default””fail-safe mode”等表述。
第五，标准号与排版问题。封面写”TCVN XXXXX:2026″，而页眉与目录写”TCVN XXXX:2026″（四个X）。此外，目录与封面中的标准名称有字符断裂（”BẢ O MẬ T”）。这些编辑细节宜在发布前统一。
第六，”基础”一词可能引起对充分性的误解。草案明确5.2的功能清单并非完整清单，垂直领域将增加要求。因此符合本标准不等于设备对任何市场都”安全”，只意味着具备最低基础。
十八、企业需要准备什么
对物联网设备开发者，宜立即启动五件事：建立并保存设备层级风险评估记录，并附载明5.2各功能纳入与排除理由的适用性声明；准备列出安全与隐私功能并说明哪些要求未涵盖的用户文件；确定支持期限并制定含停止安全更新事先通知的安全支持政策；建立接收公众漏洞报告的渠道与处理流程；并复核最易被质疑的技术点，即口令与密钥是否多机共用、启动时的完整性检查、以及更新验证机制。
对进口商与零售商，重点不同：需掌握各型号的支持期限与更新政策，因为这些信息必须公开可获取，买家也可核查。对检测机构与认证机构，本标准开辟了新的服务方向，但要求的能力不同于常规物理检测：需要文件审查、配置检查与行为测试能力。越南产品认证的义务背景，例如需按QCVN 4试验的高风险货物，是构建此类服务时需要与本标准并列考虑的框架。
十九、常见问题
该草案已生效了吗？
还没有。这是第1版草案，标准号留空，内容在公布前可能调整，且不具有适用效力。
该标准是否强制？
TCVN属自愿适用。强制性义务（如有）来自技术法规、风险类别货物清单或企业所参加认证项目的要求。
适用于哪些设备？
适用于一般意义上的物联网设备，不按行业限定：消费类设备、工业设备、传感器、执行器与联网设备。标准被设计为可由各垂直领域补充要求。
与ETSI EN 303 645、IEC 62443有何不同？
ETSI EN 303 645侧重消费类设备，IEC 62443面向工业设备与系统。本标准是面向全部物联网设备的横向基础要求，并可供这些专门要求在其基础上扩展。两者均列于草案参考文献目录中。
是否需要认证？
草案本身未规定认证项目。但引言指出标准可为合格评定项目提供要求，垂直领域也可在本基础之上建立各自项目。
文中条款与内容是否已为最终？
不是。本文概述分析时草案的内容；标准正式发布后应核对正式文本。
二十、延伸阅读
- SIEM标准草案：安全信息与事件管理产品通用要求
- TIP标准草案：网络安全威胁情报平台通用要求
- NIPS标准草案：网络入侵防护产品通用要求
- SOAR标准草案：网络安全编排、自动化与响应产品通用要求
- 需按QCVN 4试验的高风险货物：第36/2026/TT-BKHCN号通知的规定
二十一、参考来源
- TCVN XXXXX:2026（第1版）草案《网络安全 – 物联网安全与隐私 – 设备基本要求》，与ISO/IEC 27402:2023完全相同，由政府密码局起草、国防部部长建议、国家计量质量标准化委员会审定、科学技术部公布。草案不具有适用效力；本文概述其内容，不摘录全部条款原文。
- 引用文件：TCVN ISO/IEC 27000:2019（ISO/IEC 27000）；ISO/IEC 27400:2022；TCVN ISO 31000:2020（ISO 31000:2018）。
- 参考文献选摘：ISO/IEC 27402:2023；NISTIR 8259；NISTIR 8259A；ETSI EN 303 645；IEC 62443-4-1；IEC 62443-4-2；ISO/IEC 29147；ISO/IEC 30111；ISO/IEC 19790:2012；ISO/IEC 19770-2；ISO/IEC 11889-1。
二十二、联系我们
物联网设备的制造商、进口商与经销商，以及正在准备设备安全档案的检测机构、认证机构与咨询单位，可通过下表提交需求，就适用范围、风险评估记录与适用性声明的编制方式，以及标准发布前需准备的事项进行沟通。
本文分析的是尚未发布的标准草案，仅用于信息普及，不代替标准文本，也不构成针对具体情形的技术与法律咨询。草案内容在公布前可能调整，文中内容与条款为分析时草案中的内容。标准正式发布后，请使用正式文本及现行法律规范性文件。
