The draft national standard on network intrusion protection system (NIPS) products is currently under consultation, provisionally numbered TCVN XXXXX:2026 and titled “Cyber security – Network Intrusion Protection System – General requirements”. It was drafted by the Police Department for Cyber Security and High-Tech Crime Prevention, proposed by the Ministry of Public Security, appraised by the National Committee for Standards, Metrology and Quality and published by the Ministry of Science and Technology. This is the fourth document in the series of draft cyber security standards we analyse, after SIEM, threat intelligence platforms (TIP) and orchestration, automation and response products (SOAR). This article summarises the structure, scope and requirement groups at a general level, including the thresholds and lists the draft sets directly.
1. What this document is and where it stands
As with the previous three, this is a draft: the number is blank, the content may change and the draft has no legal effect. The foreword sets out the drafting body, the proposing ministry, the appraising committee and the publishing ministry.
The introduction states the purpose briefly: the standard sets technical requirements for NIPS products to strengthen monitoring capability, information sharing and proactive protection of systems against threats; agencies and organisations are encouraged to deploy NIPS products meeting this standard, in step with management, technical and operational measures, to build a comprehensive defensive ecosystem.
Clause 2 is a single sentence: “In this standard, no document is referenced.” The draft nevertheless ends with a reference list of eleven documents, the most notable being TCVN 14423:2026 on basic requirements for information systems, TCVN 12820:2020, NIST SP 800-94 on intrusion detection and prevention systems, ISO/IEC 27039, RFC 9411 (NetSecOpen), and Decision No. 1591/QD-BTTTT issuing basic technical requirements for network intrusion protection products. The presence of Decision 1591 shows this is not the first technical requirement set for this product category, so organisations that assessed against the older set should compare what has been added once the standard is issued.
Two drafting details are worth noting when quoting the text: the draft uses both “phòng, chống xâm nhập” and “phòng chống xâm nhập” in different places, and the table of contents contains a few typographical slips (for example “actvie-standby”).
2. Where NIPS sits in the cyber security standard family
The four drafts divide the layers of a defence architecture. SIEM collects and correlates event logs to detect and alert. TIP collects, processes and shares threat knowledge from many sources. SOAR orchestrates, automates and executes response. NIPS is the inline blocking layer: it sits on the traffic path, inspects packets deeply and stops malicious traffic before it reaches the protected system.
The relationships run both ways and are written into the requirements. The NIPS draft requires data sharing with SIEM in a standard format, demands that the “system/administration log” stream be kept separate from the “intrusion detection log” stream, and requires an open API so SOAR can interact in both directions to automate queries, investigation and blocking actions. In the other direction, the SOAR draft lists NIPS among the platforms it must integrate with. For buyers, this means a NIPS is no longer selected as a standalone appliance.
3. Scope and structure of the draft
The scope statement is one sentence: the standard sets general cyber security requirements for network intrusion protection products. The draft runs to 25 pages with five clauses and a reference list: Clause 1 scope; Clause 2 normative references; Clause 3 terms, definitions and abbreviations; Clause 4 general, governance and safety requirements for the product; Clause 5 business function requirements.
Clauses 4 and 5 differ structurally from the previous three drafts: each is split into an overview (4.1, 5.1) and specific requirements (4.2, 5.2) with multi-level sub-clauses. The most notable difference is that this draft has no annex at all, including no assessment method annex, whereas the SOAR draft has Annex A on assessment methods and the TIP draft has an informative Annex A. When preparing an assessment dossier for NIPS, there is therefore no ready-made method framework; the requirements in Clauses 4 and 5 have to be read with ordinary practice.
4. Terms and abbreviations
Clause 3 defines 23 terms, the most of the four drafts: NIPS; intrusion detection and prevention system (IDPS); anomaly/anomalous; inline mode; active-active; active-standby; application layer; digital signature; digital certificate; retrospective analysis; micro-segmentation; container; virtualisation; scripting engine; multi-factor authentication; whitelist; blacklist; indicator of compromise; fail-open; fail-close; deep packet inspection; hardware security module; and baseline.
The set of terms shows the draft is written for two audiences. Operational terms (fail-open, fail-close, inline mode, baseline, retrospective analysis) serve the people who deploy the product; infrastructure terms (container, virtualisation, micro-segmentation, hardware security module, scripting engine) serve the people who design the architecture. Defining fail-open and fail-close explicitly is a practical touch, since these two choices bear directly on service continuity when the device fails.
The abbreviation list has about 20 entries, including both NIPS and IDS/IPS, the ecosystem terms (SIEM, TI, SOAR, IoC, MFA) and infrastructure terms (API, CI/CD, DevSecOps, VM, TLS, Syslog, TCP, UDP, CPU, RAM). The presence of CI/CD and DevSecOps signals that the draft is written for automated deployment environments, not only for hardware in a machine room.
5. General, governance and safety requirements for the product
Clause 4 contains four requirement groups, roughly a third of the draft, deciding whether the appliance can operate in a real environment.
| Clause | Requirement group | Main content |
|---|---|---|
| 4.2.1 | Documentation | Installation, deployment and configuration guides; tuning guidance for fewer false positives and fewer missed attacks, with baseline setup guidance; usage, administration and operations documentation |
| 4.2.2 | System administration | Operational management; remote administration; authentication and authorisation management |
| 4.2.3 | Fault control | Configuration protection; protection of log and application data; time synchronisation; backup and restore; system patch updates |
| 4.2.4 | Log management | System administration logs; alert logs (intrusion detection and prevention); log format; log retention lifecycle |
6. Documentation and operational management
The documentation group (4.2.1) has three requirements and is notable for placing tuning on a par with installation. Besides the installation, deployment and configuration guide, the draft requires documentation on tuning NIPS to optimise monitoring, reduce false positives and reduce missed attacks, together with guidance on setting up a baseline for anomaly detection. This is the documentation group suppliers tend to handle most thinly, yet for NIPS the quality of tuning decides the practical value of the product.
Operational management (4.2.2.1) requires whitelists and blacklists over more network objects than before: IP addresses, IP ranges, MAC addresses and geolocation; the ability to change system time and session timeout; the ability to set and change limiting parameters for remote administration connections, such as restricted IP addresses or a cap on concurrent administration sessions; the ability to log out accounts that still hold a valid session; and keyword search over log data for review.
7. Remote administration, authentication and authorisation
Remote administration (4.2.2.2) is tightly specified with three requirements: support for and mandatory configuration of multi-factor authentication for every remote administration connection over secure protocols; automatic logout and termination of the remote administration session on session timeout; and configurability of administration IP restrictions, login session counts and brute-force protection. Making MFA mandatory for every remote administration connection is stronger than older requirement sets that settle for “support”.
Authentication and authorisation management (4.2.2.3) requires account-and-password authentication with administrator control over password complexity; at least two account groups, administrators and regular users, with specific permissions for each; for the highest-privilege group, an option to mandate MFA for both local and remote login sessions; and re-authentication with a second factor when account permissions change or when privileges are escalated within a session. Re-authentication on privilege escalation is something many products do not yet do properly. The draft also encourages central authentication through LDAP, Active Directory or RADIUS.
8. Fault control, backup and patch updates
Configuration protection (4.2.3.1) requires that when NIPS restarts because of an error (other than hardware failure), seven configuration types in force must be preserved and unchanged after the next start-up: NIPS configuration; remote administration configuration; authentication and authorisation configuration; protection rule set configuration; IP whitelist; IP blacklist; and the list of IP addresses currently blocked from connecting. Stored log data must also be unchanged across the next start-up, and system time must re-synchronise to the current time.
Backup and restore (4.2.3.4) requires backup and restore of those same seven configuration and data groups, on condition that restoration must be able to bring back the configurations and data in force before the failure. For a device sitting on the traffic path, this is the minimum needed to avoid losing the protection policy after an incident.
System patch updates (4.2.3.5) contains three requirements and is one of the most notable parts of the draft: patches must pass verification of the manufacturer’s digital signature, or an equivalent integrity mechanism, before being applied; the NIPS operating system must be hardened and securely configured, with unnecessary services and connection ports removed according to recognised secure practice frameworks; and NIPS must have a secure boot mechanism to prevent malware being inserted into the start-up process. The last requirement addresses the risk of a security appliance becoming a supply-chain weakness.
9. Log management
System administration logs (4.2.4.1) must record six event groups: account login and logout; authentication before granting access to resources or functions; application and rollback of changes to system configuration, remote administration configuration, authentication and authorisation configuration, and protection rule set configuration; issuance of restart or shutdown commands; manual changes to system time; and changes in the link state of a monitoring interface. Seven mandatory fields are: log creation time to the second, IP address or workstation identifier, actor identity, action information, success or failure result, the stated reason for failed actions, and classification by risk or severity level.
The alert log group is specific to NIPS. The intrusion detection and prevention log must record every detected intrusion event with these fields: time to the second; source and destination IP addresses; source and destination port numbers; protocol name; a description of the detected intrusion with severity, action result and event code where available; the physical or virtual network interface on which the offending packet was received; and the data structure, header field or specific byte string of the packet that triggered the protection rule.
Two requirements in this group stand out. First, the attack detection log must include or support mapping to international frameworks for classifying attack techniques and tactics to clarify the risk context. Second, NIPS must be able to automatically store and allow download of raw packets of the communication flow before and after a high-risk alert. Being able to retrieve raw packets is a condition for incident investigation, but it also raises storage requirements and questions about personal data that may appear in packets.
On format and lifecycle, NIPS must normalise logs to at least one predefined format for transmission to management, analysis and investigation tools; allow configuration of storage and deletion settings such as capacity thresholds and retention periods; allow keyword search across all fields, including lower-level fields; and allow export of log data for integration into SIEM or other solutions.
10. The business function requirement groups
Clause 5 divides business functions into four large groups, each with multi-level sub-clauses.
| Clause | Function group | Main content |
|---|---|---|
| 5.2.1 | Data collection, intake and modelling | Network interface management; network protocol support; application identification; context awareness |
| 5.2.2 | Analysis data processing | Packet header field analysis; packet payload analysis; attacks in the payload; normalisation, reassembly and anti-evasion |
| 5.2.3 | Indicator and threat knowledge lifecycle | Protection rule set management and updates; IP whitelists and blacklists; blocked IP set; threat intelligence integration; signature-based and anomaly-based detection; asset and vulnerability management |
| 5.2.4 | Sharing, distribution, integration and data use control | Data sharing; SIEM and other system integration; SOAR integration; API and automation; cloud environment integration |
| 5.2.5 | Trend statistics, alerts and reporting | Report management; protection enforcement order; attack types the product must detect; alerting and traffic control |
| 5.2.6 | Processing performance, scalability and recovery | Processing performance; operational fault tolerance; redundancy and availability; virtual patching |
11. Data collection, intake and context awareness
The first group (5.2.1) is mostly about reading and understanding traffic. On interface management, NIPS must allow one or more monitoring interfaces in active, passive or combined monitoring mode, plus at least one administration interface separate from the monitoring interfaces for system administration and interaction with other network devices.
On protocols, the draft requires analysis of IPv4 (RFC 791), IPv6 (RFC 8200), ICMPv4 (RFC 792), ICMPv6 (RFC 4443), TCP (RFC 9293), UDP (RFC 768), and the SMB, DCERPC, DNS and HTTP protocols. The notable point is the requirement for at least basic recognition and analysis of four common industrial protocols: Modbus TCP, DNP3, IEC 60870-5-104 and MQTT. For manufacturing plants, power and water utilities and smart buildings, naming these protocols in a national standard is a significant signal, because pure IT appliances often cannot read them.
On application identification (5.2.1.3), the draft requires identifying, analysing and applying traffic control rules based on the technical characteristics and nature of the application at the application layer, using deep inspection techniques such as behavioural inference and pattern matching, remaining accurate even where applications use non-standard TCP/UDP ports, shared ports or dynamic port changes. On context awareness (5.2.1.4), the product must be able to incorporate user identity and role tied to the connection, endpoint device identification, device status and geolocation into protection rules and event analysis.
12. Packet analysis and anti-evasion
The data processing group (5.2.2) is the deepest technical part of the draft and what distinguishes NIPS from an ordinary firewall. On header analysis, the draft lists the fields that must be readable for each protocol: for IPv4, Version, Header Length, Packet Length, ID, Flags, Fragment Offset, Time to Live, Protocol, Header Checksum, source and destination addresses and Options; for IPv6, Version, Payload Length, Next Header, Hop Limit, source and destination addresses and Routing Header; for ICMPv4 and ICMPv6, Type, Code and Header Checksum; for TCP, eleven fields from Source Port, Destination Port, Sequence Number and Acknowledgment Number through Flags, Window, Checksum, Urgent Pointer and Options; and for UDP, Source Port, Destination Port, Payload Length and Checksum.
On payload analysis, the draft requires reading the data string after the header and checking it according to the protocol, for example the command list for FTP (USER, PASS, RETR, STOR, LIST, CWD and others), the GET and POST methods for HTTP with matching against URL/URI and page content, and the start, commands, mail header, mail body and abort states for SMTP. NIPS must also maintain state machines for application protocols to identify and block communication that violates the valid context sequence, and must provide a scripting engine allowing custom parsers to be defined for deep inspection of specific protocols or applications.
The normalisation, reassembly and anti-evasion group (5.2.2.4) has seven requirements and is one of the strongest parts of the draft: reassembly of IP fragments; TCP stream reassembly with handling of out-of-order packets and removal of duplicate or spoofed TCP packets; decoding before processing payloads that are scrambled or encrypted before signature scanning; support for inline decryption to inspect encrypted flows deeply without seriously degrading bandwidth; integration with dedicated key management systems or hardware security modules to protect the key lifecycle; a mechanism for secure key destruction when configuration changes or a certificate is removed, so that previously decrypted data cannot be recovered unlawfully; and the ability to extract and analyse metadata of encrypted flows, such as certificate information, cipher suite and client/server fingerprint hashes, to detect traffic generated by malware or evasion tools without fully decrypting the payload.
That last requirement deserves close reading because most traffic today is encrypted. Rather than forcing decryption of everything, the draft allows fingerprint and TLS metadata analysis while still requiring inline decryption capability where needed. The two-layer framing acknowledges both deployment realities: organisations with the legal basis and infrastructure to decrypt, and those that can only analyse metadata.
13. Rule sets, threat knowledge and detection
The indicator and threat knowledge lifecycle group (5.2.3) has eight sub-clauses. Protection rule set management (5.2.3.1) requires seven operations: adding a new rule, tuning a rule, searching rules, deleting a rule, enabling or disabling a rule, exporting the rule set to a file and restoring the rule set from a file.
Rule set updates (5.2.3.2) require automatic notification of new updates, online download and manual application of updates, and, for rule sets issued by the manufacturer, verification of the digital signature of the downloaded file or an equivalent mechanism, together with the ability to restore the rule set if an update fails.
IP whitelist and blacklist management (5.2.3.3) requires adding, deleting and editing an address or range; searching by address or range; setting traffic control actions for an address or range; enabling or disabling an applied control action; exporting and restoring lists from a file; and, for whitelists, setting and changing the validity period. That last detail matters because whitelists without expiry are among the most commonly exploited gaps.
Managing the set of currently blocked IP addresses (5.2.3.4) requires searching by IP address or keyword; viewing information about a blocked address, at minimum the time blocking started, the blocking duration in force from that moment and the identifier of the rule that caused the block; and unblocking one or more addresses at once. For a device that blocks automatically, knowing exactly which rule caused a block is a condition for fast recovery when a partner address is blocked by mistake.
Threat intelligence integration (5.2.3.5) requires intake and automatic updating of indicators of compromise from external intelligence sources without updating the whole rule set, and support for receiving intelligence feeds in international or equivalent standard formats. Signature-based detection (5.2.3.6) requires detecting and blocking intrusions by comparing traffic against a database of known attack signatures; allowing administrators to customise and assign different signature sets to specific interfaces, network segments or traffic directions; and support for common standard signature formats so protection rules can be defined manually.
Anomaly-based detection (5.2.3.7) has four requirements: support for building and defining a traffic baseline; automatic alerting and blocking action for anomalies based on throughput limits, event frequency and unusual times of day; the use of machine learning algorithms to analyse identification characteristics and detect abnormal communication behaviour such as domain generation algorithms, command-and-control contact and low-and-slow data transfer; and retrospective analysis, allowing automatic matching of new indicators and updated rule sets against historical logs and network metadata. Retrospective analysis is conceptually strong but demanding in storage and compute. The group closes with asset and vulnerability management (5.2.3.8), requiring integration of asset, configuration and vulnerability information for incident context analysis.
14. Sharing and integration with SIEM, SOAR and cloud
The sharing and integration group (5.2.4) is the bridge between NIPS and the rest of the ecosystem. On data sharing, NIPS must support at least one of Syslog, CEF, LEEF or JSON, and must transmit logs over a secure encrypted channel such as TLS or equivalent.
On SIEM integration (5.2.4.2), the draft requires connection to SIEM systems for data sharing and, importantly, requires that the product clearly distinguish and provide independent data stream configuration between “system/administration logs” and “intrusion detection logs” when sharing with external SIEM systems. This is a practical requirement: mixing the two log types into one stream adds noise, complicates analysis on the SIEM side and affects access control over the data. NIPS must also connect to other monitoring, analysis and investigation systems through supported standard data formats.
On SOAR integration (5.2.4.3), NIPS must provide an open API enabling two-way interaction to automate queries, incident investigation and blocking actions. The API and automation clause (5.2.4.4) adds two points: a secure API supporting automation of configuration, protection rule set updates and integration with CI/CD pipelines; and API integration that supports authentication, authorisation and channel protection.
On cloud environments (5.2.4.5), the draft requires flexible deployment as a virtual machine or container architecture; automatic application of security baselines when cloud infrastructure scales up or down; and monitoring and protection of internal network traffic through distributed sensors or integration with micro-segmentation architectures. These three requirements show the draft does not aim only at on-premises appliances.
15. Reporting, enforcement order and attack catalogue
Report management (5.2.5.1) requires a graphical interface allowing creation, review and deletion of reports; report creation from predefined templates; application of search rules over information and log data to add, filter and refine report content; selection of an export file format meeting at least two of the WORD, EXCEL, PDF, HTML and XML formats; and download of the exported report file.
The protection enforcement mechanism (5.2.5.2) requires NIPS to analyse monitored traffic in the exact processing priority order of the configured protection rule sets, IP whitelists and IP blacklists, with at least one order pre-configured by the manufacturer as the default. In practice the order of application between rules, whitelists and blacklists determines the final result when an address appears in both lists, so requiring disclosure of the default order is valuable in an assessment.
Attack detection (5.2.5.3) is one of the most concrete parts of the draft: in a test environment, NIPS must detect at least 17 common network-layer attacks: IP Fragments Overlap attacks such as Teardrop and Bonk/Boink; attacks with identical source and destination IP addresses such as Land; Fragmented ICMP Traffic such as Nuke; Large ICMP Traffic such as Ping of Death; TCP NULL flags; TCP SYN+FIN flags; TCP FIN flags; TCP SYN+RST flags; UDP Bomb; UDP Chargen DoS; flooding a host such as Smurf, Ping Flood and SYN Flood; flooding a network; IP protocol scanning; TCP port scanning; UDP port scanning; and ICMP scanning. This catalogue is useful for both suppliers and testers because it is a minimum, reproducible checklist.
On alerting and traffic control (5.2.5.4), NIPS must generate alerts for intrusion detection, intrusion prevention and anomaly events; and must allow a traffic control action and its validity period to be set for each protection rule, at least one of: allow the connection to continue; send a TCP RST packet towards the source address; send a TCP RST packet towards the destination address; send an ICMP Destination Unreachable response; or drop the packet without response. The two TCP RST actions apply only to rules matching TCP traffic. In active monitoring mode, NIPS must allow connection blocking by source IP address or by destination IP address of the triggering event.
16. Performance, fault tolerance, redundancy and virtual patching
On performance (5.2.6.1), the draft chooses to leave publication to the supplier while constraining how measurement is done: NIPS must be deployed exactly according to the minimum hardware configuration published in the installation and configuration guide; the manufacturer must publish minimum performance figures against that configuration, at minimum the number of connections per second and the maximum number of concurrent connections; and bandwidth and latency assessment must be carried out with tests applying mixed layer 7 traffic such as HTTP/HTTPS. The product is deemed compliant if measured results are not lower than the published figures. This wording allows products to differ in performance while preventing published and measured values from diverging.
On operational fault tolerance (5.2.6.2), there are three requirements: when an error occurs in active monitoring mode, NIPS must automatically activate the bypass function and also allow manual activation by an administrator, generating an alert and a log entry when activated; fail-open or fail-close must be configurable; and in fail-close mode, there must be a mechanism to completely prevent traffic passing the inline interface if deep inspection is interrupted, with a mandatory alert when hardware resources, including CPU, RAM and connection sessions, reach their maximum thresholds.
On redundancy (5.2.6.3), NIPS must support cluster deployment in at least one of active-active or active-passive mode, and failover must include a state synchronisation mechanism ensuring valid network sessions are not interrupted. Notably the draft does not fix a failover time figure but sets the bar at “does not interrupt valid sessions”, a criterion that needs to be pinned down through a specific test scenario during assessment.
Virtual patching (5.2.6.4) is one of the newer requirements compared with older sets: NIPS must provide a virtual patching mechanism applying protection rules mapped directly to common vulnerability identifiers, and must be able to suggest or automatically activate the corresponding virtual patch rules based on the operating system and target application configuration being protected. For systems that cannot be patched immediately, such as legacy operating systems in production lines, this is a practically valuable requirement.
17. Two editorial points to keep in mind
When reading the draft, one point about naming deserves attention so as not to infer the wrong content. The headings in Chapter 5 use intelligence-flavoured wording such as “collecting, receiving and modelling intelligence data”, “processing intelligence data” and “managing the indicator and threat knowledge lifecycle”, while the content underneath is specific NIPS engineering: network interface management, packet header analysis, protection rule sets and traffic control. In other words, for Chapter 5 of this draft, read by content rather than by heading.
The second point is that the draft states no assessment method and has no technical annex, unlike the SOAR draft. When preparing, it is therefore worth agreeing in advance with the assessing party how each requirement group will be verified, especially qualitative requirements such as “fewer false positives and fewer missed attacks”, “does not interrupt valid sessions” and “does not seriously degrade bandwidth”.
18. What businesses and organisations should prepare
For manufacturers and suppliers of NIPS solutions, four layers need review: documentation, where tuning guidance and baseline setup guidance are most often neglected; governance and safety, noting mandatory requirements such as MFA for all remote administration connections, re-authentication on privilege escalation, signature verification for patches and rule sets, and a secure boot mechanism; business functions, especially anti-evasion, reassembly, metadata analysis of encrypted flows and retrospective analysis; and performance, where the minimum hardware configuration and figures for connections per second and concurrent connections must be published and measured with mixed layer 7 traffic.
For deploying organisations, preparation should cover what the standard will demand: an inventory of interfaces and network segments, with the administration interface separated from monitoring interfaces; a fail-open or fail-close decision per deployment position, since the two options trade safety against service continuity; a plan to separate administration and detection log streams when sending data to SIEM; a policy for storing raw packets and handling any personal data they contain; and, for sites with industrial systems, an inventory of devices using Modbus TCP, DNP3, IEC 60870-5-104 and MQTT.
For testing laboratories and assessment bodies, preparation centres on three things: building test scenarios for the 17 listed attack types; designing mixed layer 7 traffic tests to verify the performance figures suppliers publish; and building failover scenarios to verify the requirement that valid sessions are not interrupted. For buyers, at this stage the draft is best used as a vendor evaluation question list, particularly on anti-evasion, encrypted flow analysis and virtual patching.
19. Frequently asked questions
Is the draft in force?
No. It is under consultation and appraisal, provisionally numbered TCVN XXXXX:2026, and its content may change before publication.
Is the standard mandatory?
A national standard applies voluntarily and becomes mandatory only when referenced by a legal instrument, a technical regulation, a contract or a project dossier.
How does the NIPS draft differ from the SIEM, TIP and SOAR drafts?
The four cover different layers of the same defence architecture: SIEM detects on log data, TIP manages threat knowledge, SOAR executes and orchestrates response, and NIPS inspects packets deeply and blocks inline. The NIPS draft is also the only one of the four to define fail-open, fail-close and inline mode.
Does the draft include an assessment method annex?
No. Unlike the SOAR draft with its Annex A on assessment methods, the NIPS draft has no annex at all; the requirements sit entirely in Clauses 4 and 5.
Are the figures in this article final?
No. This article records the content and lists present in the draft 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 SOAR: general requirements for cybersecurity orchestration, automation and response products
- Circular 125/2026/TT-BCA: surveillance cameras added to the medium-risk goods list
- Circular 14/2026/TT-BKHCN: the eight certification methods and how to choose
21. References
- Draft TCVN XXXXX:2026, “Cyber security – Network Intrusion Protection System – General requirements”, drafted by the Police Department for Cyber Security and High-Tech Crime Prevention, proposed by the Ministry of Public Security, 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 structure, scope and requirement groups without reproducing clause text.
- Documents listed by the draft, notably: TCVN 14423:2026 on basic requirements for information systems; NIST SP 800-94 on intrusion detection and prevention systems; ISO/IEC 27039; RFC 9411 (NetSecOpen); and Decision No. 1591/QD-BTTTT issuing basic technical requirements for network intrusion protection products.
- The three companion drafts already analysed: TCVN XXXXX:2026 on SIEM, on cyber security threat intelligence platforms (TIP) and on orchestration, automation and response products (SOAR).
22. Contact
Manufacturers and suppliers of NIPS products, organisations building multi-layer defence systems and bodies preparing assessment dossiers for such appliances can send a request through the form below to discuss assessment scope, test scenarios and the documentation to prepare 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 figures and lists 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.
