The draft national standard on IoT security and privacy is currently under consultation. It is provisionally numbered TCVN XXXXX:2026, marked “First edition”, and titled “Cybersecurity – IoT security and privacy – Device baseline requirements”. According to the foreword, the standard is identical to ISO/IEC 27402:2023. It was drafted by the Government Cipher Authority (Ban Cơ yếu Chính phủ), proposed by the Minister of National Defence, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology.
This matters to organisations making IoT devices (cameras, smart locks, sensors, connected appliances, routers, remote industrial monitors) and to testing and certification bodies: for the first time Vietnam would have a baseline set of requirements that can serve as a reference for cybersecurity conformity assessment of IoT devices. The draft runs to about 20 pages, with five clauses, one informative annex and 26 references.
1. What this draft is and where it stands
This is a draft national standard: the number is blank (XXXXX), it has no legal effect, and the content may change before publication. It follows the adoption route of taking over an international standard wholesale: “identical to ISO/IEC 27402:2023”.
A detail worth noting is that the draft was prepared by the Government Cipher Authority and proposed by the Ministry of National Defence, unlike most draft TCVNs on products we have analysed (usually prepared by technical subcommittees under the Vietnam Directorate for Standards, Metrology and Quality). This reflects the subject area: cybersecurity standards for devices fall within the remit of the specialised cipher authority.
2. Why this draft matters
Three reasons. First, it is a horizontal standard: it is not aimed at one product but applies to every kind of IoT device, from consumer products to industrial equipment. Second, the standard does not prescribe a specific technical configuration; it requires a process: risk assessment at device level, documentation of the results, information disclosure to users, and implementation of the corresponding security features. It therefore demands a dossier, not only a product. Third, it is designed as a baseline set that vertical sectors (health, financial services, industry, consumer electronics, transport) can extend, meaning it can become the common foundation for several conformity assessment programmes.
3. How the standard is meant to be used
The standard provides baseline ICT requirements so that IoT devices can support security and privacy controls. The additional information in the draft states that stakeholders such as IoT device developers, system integrators, importers, retailers or regulators may all carry out such risk assessments.
In essence the standard separates roles: the device developer is responsible for the documentation and the device features; the user organisation is responsible for deploying the controls in its system. The draft also makes clear that the controls in ISO/IEC 27400 cannot be deployed if IoT devices lack the corresponding supporting functions, which is the reason this standard exists.
4. Structure
The draft contains: a foreword; an introduction; Clause 1 scope; Clause 2 normative references; Clause 3 terms, definitions and abbreviations (13 definitions, 12 abbreviations); Clause 4 overview; Clause 5 requirements; Annex A (informative) on risk management guidance; and a bibliography.
Clause 5 carries the weight and has two branches: 5.1 requirements for IoT device policies and documentation, covering risk management, information disclosure and vulnerability disclosure and handling; 5.2 requirements for IoT device capabilities and behaviour, covering seven groups: configuration, software reset, user data deletion, data protection, interface access, software and firmware updates, and user notification.
5. Normative references and bibliography
The draft references only three documents, two of which already exist as TCVNs:
- TCVN ISO/IEC 27000:2019 (ISO/IEC 27000), Information technology – Security techniques – Information security management systems – Overview and vocabulary;
- ISO/IEC 27400:2022, Cybersecurity – IoT security and privacy – Guidelines;
- TCVN ISO 31000:2020 (ISO 31000:2018), Risk management – Guidelines.
The bibliography lists 26 documents, which shows the drafting context. Notable entries include NISTIR 8259 and NISTIR 8259A (NIST work on foundational cybersecurity activities and a core baseline for IoT devices), ETSI EN 303 645 for consumer devices, IEC 62443-4-1 and 62443-4-2 for industrial devices and systems, ISO/IEC 29147 and ISO/IEC 30111 on vulnerability disclosure and handling, and ISO/IEC 19790 on security requirements for cryptographic modules. Keeping only three normative references while pointing to those larger bodies of work is a sensible approach: the binding part stays small, the references open the way for readers who want to go deeper.
6. Terms to know before reading Clause 5
Clause 3 defines 13 terms, mostly sourced from ISO/IEC standards. The most important for reading the requirements:
| Term | Core content in the draft |
|---|---|
| IoT device | An entity of an IoT system that interacts and communicates with the physical world through sensing or actuation; an assembled device usable for its intended IoT functions without being embedded in another product |
| IoT system | A system providing IoT functions; may include IoT devices, IoT gateways, sensors and actuators, along with cloud and network connectivity |
| IoT gateway | An entity connecting one or more proximate networks and the IoT devices on them to one or more access networks |
| IoT device developer | The entity that creates a fully assembled IoT device |
| Trusted computing base (TCB) | All protection mechanisms within a computer system, including hardware, firmware and software, whose combination enforces the security policy |
| Critical security parameter (CSP) | Information whose disclosure or modification can undermine the security of a cryptographic module; examples include secret and private keys, authentication data such as passwords, PINs, certificates and other trust anchors |
| Sensitive security parameter (SSP) | Critical security parameters and public security parameters |
| Factory default | The state of the device after a factory reset or after manufacturing/assembly is completed |
| Fail-safe mode | A device or feature that, on failure, responds in a way that does not harm or minimises damage to other devices and does not endanger or minimises danger to operators |
The abbreviation list covers API, ASLR, CPU, CSP, ICT, IoT, PIN, PSP, RoT, TCB, SWID and XML. Two matter most because they appear in the recommendations: ASLR (address space layout randomization) and RoT (root of trust).
7. Risk management requirements
Clause 5.1.1 is the most distinctive part of the standard and also the easiest to skim past. Its main content:
- IoT devices must have documentation recording the results of a risk assessment performed at device level, in the context of system-level risk assessment;
- The process must consider the intended outcomes for the intended use case and the needs and expectations of stakeholders (for example parties on the network the device connects to), including unintended physical and logical impacts;
- The risk assessment must consider that IoT devices may be constrained (limited battery, little memory, a “weak” CPU), because this shapes how risk is treated;
- The documentation must be available throughout the supported product lifetime.
The additional recommendation states that the assessment and treatment processes should follow a widely accepted method such as the one in ISO 31000, and Annex A gives guidance on applying it.
8. The nine steps of risk assessment and treatment
Clause 5.1.1.1.5 lists nine steps that must be defined and applied. This part can be used directly as a checklist when building a dossier:
- determine whether separate risk assessment and treatment processes are needed for different products;
- select suitable risk treatment options based on the risk assessment results;
- determine all controls needed to implement the selected options;
- determine all security and privacy features of the IoT device from those controls;
- compare the identified features with those in 5.2 and verify that no necessary feature is missing;
- produce a statement of applicability covering the necessary features and the rationale for inclusion and for exclusion of features in 5.2;
- where other device standards are used, fulfil their requirements after steps a) to f);
- produce a risk treatment plan;
- inform the risk owner of the plan and the residual risks, or where applicable obtain their approval of the plan and acceptance of the residual risks.
The draft notes in its footnotes that 5.2 contains a baseline list of features but not an exhaustive one: depending on the vertical market segment or higher-risk use cases, further features and controls may be needed. The requirement to produce a “statement of applicability” with reasons for exclusion is what distinguishes this standard from an ordinary technical checklist: it forces the developer to justify, not merely to declare yes or no.
9. Information disclosure requirements
Clause 5.1.2 sets three requirements: IoT devices must have user documentation listing the features the device provides to support security and privacy controls, clarifying if any requirement in 5.2 is not included; this information must be publicly available for the period during which the device is supported; and devices must come with a security support policy and other supporting documentation in which users are given advance notice of when security updates will cease.
The additional recommendations go further and are where businesses are most often questioned in an assessment: information should be provided first at the point of sale; guidance should be given after purchase, possibly as part of setup, highlighting future events such as software updates and providing a means for users to receive future communications; the stated support period should match the risks and expected product lifetime, and changing a published support period should be avoided because it can disrupt users’ planning cycles; documentation should explain how users can tell whether the support period has changed after publication.
Also notable: the draft requires information about the third-party software components the device depends on, to the extent relevant to its security, and suggests this may be provided in machine-readable form using software identification tags (SWID) under ISO/IEC 19770-2. This is close to the software bill of materials (SBOM) expectations appearing in several markets, even though the draft does not use that term.
10. Vulnerability disclosure and handling
Clause 5.1.3 has two requirements: IoT devices must have documentation specifying the vulnerability disclosure and handling processes to be applied throughout the supported lifetime; and those processes must include, at a minimum, the ability to receive reports of potential vulnerabilities from the public. The additional recommendation points to ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes).
The requirement to “receive reports from the public” looks modest, but in practice it demands an intake channel, a triage process and a response commitment. For smaller businesses this is often the first hard gap when implementing the standard.
11. The seven capability groups
Clause 5.2 details the required features. Its structure is worth noting: each sub-clause is split into “Requirements”, “Additional recommendations” and “Additional information”, while 5.2.8 has only the “Information” part. The table below summarises the core requirement of each group, taking only the “Requirements” part:
| Group | Core requirement in the draft |
|---|---|
| Configuration | If configuration settings can be modified, only authorized entities may modify them; devices may change the configuration of other devices only when authorized |
| Software reset | If a device can be reset, the process must be secure and may only be executed by an authorized entity |
| User data deletion | If the device stores user data, it must provide a function to delete appropriate user data in any type of memory, restricted to authorized entities |
| Data protection | Must protect stored and transmitted data from unauthorized access, modification and disclosure; must cover configuration, identity data, user data, event logs and sensitive security parameters; must protect software and firmware; must use cryptography |
| Interface access | Must restrict logical access to interfaces to authorized entities; must use appropriate authentication and access control mechanisms; must replace common values of critical security parameters with values unique per device before operation |
| Software and firmware updates | Updates must be performed by a secure process, initiated only by authorized entities; when an update is abruptly interrupted, the device must be brought to a state that minimises potential harm |
| User notification | This clause has only the “Information” part: it describes situations and ways of notifying users, without a numbered technical requirement |
12. The first three groups: configuration, reset and data deletion
These three share one pattern: an “if” condition plus a requirement about authorized entities. Configuration may only be changed by authorized entities; resets may only be executed by authorized entities; so may user data deletion. The draft notes that “authorized entities may be a person or another device”, meaning the requirement does not presume a password, but does presume a verifiable authorisation mechanism.
The additional information under software reset gives a technically important reason: sometimes a vulnerability is remediated by changing configuration, but if the device is then restored to factory default, the vulnerability may be exploitable again. A typical example is a configuration changed to block insecure cipher suites while the factory default allows all of them. For conformity assessment, both states need checking, not only the active one.
On user data deletion the draft is candid about a trade-off: deleting more than one user’s data may be acceptable, but it can lead to data being retained longer than necessary, so it should only be done for good reason. The draft also notes that users expect deletion to apply across the whole IoT system (mobile app, cloud), not just the device.
13. Data protection
This is the technically heaviest group. Beyond the four requirements summarised in the table above (protecting stored and transmitted data; covering configuration, identity data, user data, event logs and sensitive security parameters; protecting software and firmware from unauthorized access and modification; using cryptography), the recommendations list a series of measures:
- at start-up, devices should check the integrity and authenticity of software and firmware; if the checks fail, the device should notify the user, become inoperable, operate in a fail-safe mode, or start a device recovery process if recovery can be performed securely;
- on first installation or maintenance, devices should establish a secure default configuration; user configuration options should prevent selecting an insecure configuration or give an appropriate warning;
- where possible, devices should provide partitioning; use functional modules to restrict access to system resources; and keep the trusted computing base (TCB) as small as possible to reduce the exposed attack surface;
- memory protection mechanisms such as memory-safe languages, stack canaries, address space layout randomization (ASLR) and restricting or disabling executable permissions are recommended wherever applicable;
- event logging should record enough detail per event for an authorized entity to identify anomalous events and analyse data meaningfully; devices and logs should be synchronised with an authoritative system or forwarded to centralised repositories if the data has been properly de-identified;
- the risk assessment results should help determine whether a device may include hard-coded or shared sensitive security parameters, provided those parameters are unique per device and not universal.
The additional information explains the role of hardware: solutions such as integrated cryptographic accelerators, a hardware-based root of trust (RoT) and a hardware-anchored authenticated boot help protect keys and secure platform integrity; trusted platform modules (TPMs) are cited as an example of a hardware root of trust that can support cryptographically bound device identity and interface access. The draft also states a practical exception: integrity checks and recovery modes may not be appropriate in safety-critical applications where continuous operation is essential.
14. Interface access and identity
Clause 5.2.6 has four requirements: mechanisms to restrict logical access to device interfaces to authorized entities; appropriate authentication and access control mechanisms; assessment of security and privacy requirements when designing and implementing functions related to creating and using identifiers; and ensuring that common values for critical security parameters (such as shared private keys or standard passwords) are replaced with values unique per device, or are clearly determined by an appropriate external entity, before devices are put into operation.
That last requirement is a familiar checkpoint that still trips up practice: default passwords identical across devices are a common flaw in low-cost IoT products. The draft adds a short note: the risk assessment is the basis for what “appropriate” means here.
The recommendations add content that conformity assessors often probe: devices should be logically identifiable, but persistent identifiers should be avoided unless unavoidable, and when they exist their presence should be made clear to users; logical access restrictions should cover enabling or disabling any interface (local and network), requiring authentication for all remote interfaces, and the ability to identify or block unsupported devices attempting to access interfaces; all input and output data should be validated for length, character type, accepted values or ranges and message format; secure programming practices should be followed, including the use of a type-safe language, failing which the device should still perform bounds checking, use safe typing and safe string handling functions; and allow-lists should be preferred over deny-lists when filtering data.
15. Software and firmware updates
Three requirements: updates must be performed by a secure procedure; updates may only be initiated by authorized entities; and when an update is abruptly interrupted, the device must be brought to a state minimising potential harm, taking into account the risks arising when the device does not operate as expected.
The recommendations are detailed enough to serve as a checklist for the update process: a way to confirm the validity, authenticity and integrity of any update before installation; configuration options covering whether automatic updates are enabled or disabled, whether download and installation for remote updates is automatic or manual, a method to schedule automatic download and installation, and whether a notification occurs when an update is available (and who or what is notified). The draft adds that devices should support automatic updates, and should run a periodic process to check for new security updates and notify the user if any exist.
Technically, the draft recommends verifying authenticity and integrity before installation, possibly using digital signatures and public key infrastructure, and securing the update infrastructure, especially private key management; considering hardware root of trust capabilities to measure and verify the validity of software and firmware updates; and verifying software through secure boot mechanisms, warning the user or a local hub/IoT gateway if an unauthorised change is detected, and terminating all network communication except for sending the warning or initiating device recovery. The draft notes that revoking an update or using an older version may be used to recover from an interrupted update, and that hardware replacement is a legitimate and acceptable way to deliver an update.
16. User notification and Annex A
Clause 5.2.8 differs structurally: it has only the “Information” part, with no numbered requirements. It states that devices notifying users of various situations may be necessary or useful, and that several recommendations in the standard describe such situations. The draft also acknowledges practice: some IoT devices cannot proactively notify users (showing a message, emitting sound or light) but can respond with a message when queried or accessed remotely; devices that cannot notify directly may send notifications through a local hub, or to alarming, monitoring or logging devices in the IoT system.
Annex A is an informative annex on risk management guidance, referring in turn to clauses 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.5.1, 6.5.2, 6.6 and 6.7 of TCVN ISO 31000:2020 (ISO 31000:2018) for risk identification, analysis, evaluation, treatment, monitoring and review, and recording and reporting. Notably, A.5 lists risk treatment options: avoiding the risk, doing further analysis, reconsidering objectives, removing the risk source, sharing the risk (contract, insurance) and accepting the risk by an informed decision. A.7 adds a practical step: the organisation should establish, record and maintain a system for collecting and verifying information about IoT devices, gather and review publicly available information about similar products on the market, and assess its possible relevance to the device’s trustworthiness.
17. Six points to keep in mind
First, distinguish “must” from “should”. The draft clearly separates three layers: “Requirements” (using “must”, the conformity assessment content), “Additional recommendations” (using “should”) and “Additional information”. Many assessment disputes arise from treating recommended content as a requirement, or ignoring a requirement because it sits in a sub-clause that looks like guidance.
Second, Clause 5.2.8 has no requirements. “User notification” is the only sub-clause in 5.2 with only an information part. Notification obligations therefore sit in the recommendations of other clauses, for example warning on detection of an unauthorised change or notification when an update is available.
Third, this is a standard, not a regulation. It is a TCVN and applies voluntarily. Any mandatory obligation would come from technical regulations, risk-based goods lists or the requirements of a specific certification programme. The draft should be read alongside the quality management picture, not treated as creating obligations by itself.
Fourth, “identical to” means the translation must be faithful. Because the standard adopts ISO/IEC 27402:2023 wholesale, the Vietnamese wording of terms directly affects how a dossier is checked against the international text. Where there is dispute, compare with the original English, particularly for terms such as “authorized entity”, “factory default” and “fail-safe mode”.
Fifth, the standard number and presentation errors. The cover reads “TCVN XXXXX:2026” while page headers and the table of contents read “TCVN XXXX:2026” (four X’s). In addition, the title in the contents and on the cover has broken characters in places (“BẢ O MẬ T”). These editorial points need to be unified before publication.
Sixth, the word “baseline” may mislead about sufficiency. The draft states clearly that the feature list in 5.2 is not exhaustive and that vertical sectors will add requirements. Meeting this standard therefore does not mean a device is “secure” for every market; it means the device has a minimum baseline.
18. What businesses should prepare
For IoT device developers, five things to start now: produce and retain device-level risk assessment records with a statement of applicability giving reasons for including and excluding each feature in 5.2; prepare user documentation listing security and privacy features and stating clearly which requirements are not covered; decide the support period and build a security support policy with advance notice of the date security updates will end; set up a public vulnerability reporting channel and handling process; and review the technical points most likely to be challenged, namely passwords and keys shared across devices, start-up integrity checking and the update verification mechanism.
For importers and retailers the focus differs: they need to know the support period and update policy of each model, because this information must be publicly available and can be checked by buyers. For testing laboratories and certification bodies, this standard opens a new service line but demands capabilities different from conventional physical testing: document review, configuration checking and behavioural testing. The Vietnamese product certification landscape, such as the case of high-risk goods requiring QCVN 4 testing, is the wider framework to place next to this standard when building a service.
19. Frequently asked questions
Is the draft in force?
No. It is a first-edition draft with a blank number; the content may change and it has no legal effect.
Is the standard mandatory?
TCVN standards apply voluntarily. Any mandatory obligation would come from technical regulations, risk-based goods lists or the requirements of a certification programme a business chooses to join.
Which devices does it cover?
IoT devices generally, without sector limitation: consumer devices, industrial equipment, sensors, actuators and connected network devices. It is designed so that vertical sectors can add their own requirements.
How does it differ from ETSI EN 303 645 and IEC 62443?
ETSI EN 303 645 focuses on consumer devices and IEC 62443 on industrial devices and systems. This standard is a horizontal baseline for all IoT devices, written so those sector-specific sets can extend it. Both are listed in the draft’s bibliography.
Does it require certification?
The draft itself does not establish a certification programme. However, its introduction notes the standard may provide requirements for a conformity assessment programme, and vertical sectors may build their own programmes on this baseline.
Are the figures and clauses in this article final?
No. This article summarises the draft content at the time of analysis; once the standard is issued, the official text should be consulted.
20. Related reading
- Draft TCVN on SIEM: general requirements for security information and event management products
- Draft TCVN on TIP: general requirements for cyber security threat intelligence platforms
- Draft TCVN on NIPS: general requirements for network intrusion protection system products
- Draft TCVN on SOAR: general requirements for cybersecurity orchestration, automation and response products
- High-risk goods requiring QCVN 4 testing under Circular 36/2026/TT-BKHCN
21. References
- Draft TCVN XXXXX:2026 (first edition), “Cybersecurity – IoT security and privacy – Device baseline requirements”, identical to ISO/IEC 27402:2023, drafted by the Government Cipher Authority, proposed by the Minister of National Defence, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology. The draft has no legal effect; this article summarises the content without reproducing the full clause text.
- Normative references: TCVN ISO/IEC 27000:2019 (ISO/IEC 27000); ISO/IEC 27400:2022; TCVN ISO 31000:2020 (ISO 31000:2018).
- Selected bibliography entries: 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.
22. Contact
Manufacturers, importers and distributors of IoT devices, along with testing laboratories, certification bodies and consultants preparing device security dossiers, can send a request through the form below to discuss scope, how to prepare risk assessment records and a statement of applicability, and the steps to take before the standard is issued.
This article analyses a draft standard that has not been issued, for information purposes only, and does not replace the standard or technical and legal advice for a specific case. The draft content may change before publication; the content and clauses quoted are those present in the draft at the time of analysis. Once the standard is issued, use the official text together with the legal instruments in force.
