NIS2 Network Security: The 4-Zone Segmentation Model That Satisfies CIR Annex Requirements

Most network diagrams show the same thing: a firewall at the perimeter, a corporate network behind it, and a passing mention of a DMZ. Under NIS2, that architecture is no longer a defensible starting point — and for entities subject to Commission Implementing Regulation (EU) 2024/2690, it fails two explicit Annex requirements before the audit question is even asked.

CIR Annex 6.8 requires that systems be divided into “separate networks or zones based on risk, separated from third-party systems,” with documented security requirements for each zone. Annex 6.7 requires that network architecture be documented, access and communication controls implemented, and remote access secured through “secure connections, trusted channels and modern (latest) and secure technologies.” A perimeter-only model satisfies neither.

This guide maps those requirements to a practical four-zone architecture, explains what controls each zone needs, shows why CIR’s access control provisions implement zero trust whether organisations frame it that way or not, and provides the documentation package an auditor will ask to see.

What Article 21 and CIR Annex 2024/2690 Actually Require

Network security under NIS2 operates on two levels. Article 21(2) of the Directive applies to all essential and important entities and establishes a ten-measure all-hazards framework. Four measures directly govern network controls:

• Article 21(2)(e) — Security in network and information systems acquisition, development, and maintenance
• Article 21(2)(g) — Basic cyber hygiene practices, including network segmentation (Recital 89 lists it explicitly alongside zero-trust principles)
• Article 21(2)(i) — Human resources security, access control policies, and asset management
• Article 21(2)(j) — Multi-factor authentication and secured communications

For digital infrastructure entities — cloud providers, data centres, managed service providers, CDN providers, online marketplace operators, online search engines, social network platforms, and trust service providers — Commission Implementing Regulation (EU) 2024/2690 applies since 18 October 2024. It translates Article 21 into more than 150 specific controls, with network security concentrated in three Annex sections:

• CIR Annex 6.7 (Network Security — NS.17): Document network architecture; implement access and communication controls; enforce secure configurations; manage remote access through “secure connections, trusted channels and modern (latest) and secure technologies.” Review and update measures after significant incidents or organisational changes.
• CIR Annex 6.8 (Network Segmentation — NS.17): Divide systems into separate networks or zones based on risk, separated from third-party systems. Define security requirements for each segment covering relationships, measures, access controls, and administration procedures. Review segmentation strategies after major incidents or changes.
• CIR Annex 11 (Access Control): Control access to network and information systems; explicit MFA and privileged account management requirements.

For entities not directly bound by CIR 2024/2690, Article 21 still applies — and the CIR Annex represents the current regulatory benchmark for what “appropriate and proportionate” technical measures look like. For an overview of all ten Article 21 obligations, see the full NIS2 requirements guide.

The 4-Zone Segmentation Model

CIR Annex 6.8 requires risk-based zone separation but does not prescribe an architecture. A four-zone model satisfies the regulation for most organisations — essential entities, managed service providers, and industrial operators alike. Each zone represents a distinct trust level, and the controls between zones enforce that boundary with documented rules that auditors can examine.

Zone 1 — Internet (Untrusted)

Everything outside your perimeter. Traffic from Zone 1 is untrusted by default. Public-facing infrastructure — web servers, DNS resolvers, email gateways, external APIs — sits at the boundary between Zone 1 and Zone 2. No system in Zone 3 or Zone 4 should have a direct interface into Zone 1.

Zone 2 — DMZ (Controlled Buffer)

A controlled buffer between external traffic and internal systems. Reverse proxies, load balancers, web application firewalls, mail relays, and — for industrial environments — data historians and jump servers reside here. The defining rule: no traffic passes directly from Zone 1 to Zone 3. Every external flow transits Zone 2.

Zone 3 — Internal Network (Trusted with Controls)

Corporate systems: user workstations, ERP, file servers, email servers, development environments. “Trusted” here means authenticated users operating under least-privilege access controls, not unrestricted lateral movement. A breach contained in Zone 3 should not reach Zone 4 without an explicit, separately authenticated step.

Zone 4 — Critical/OT Zone (Maximum Protection)

Industrial control systems, SCADA, PLCs, safety instrumented systems, or critical IT assets requiring maximum isolation. Physical and logical separation from Zone 3 is the baseline. No direct Zone 3 → Zone 4 connections are permitted. Every data flow passes through an industrial DMZ layer — detailed in the IT/OT boundary section below.

Controls Per Zone

CIR Annex 6.8.2 requires that “security requirements for segmentations, including relationships, measures, access controls, administration and development procedures” be documented for each segment. The following table provides the baseline controls and the documentation each zone requires for an audit-ready evidence package.

Zone	Traffic Policy	Access Control	Monitoring	Audit Documentation Required
Zone 1 — Internet	Default deny all inbound; explicit allow only for published services	No trust granted — all traffic treated as hostile	DDoS detection, perimeter IDS/IPS, geo-blocking logs	Perimeter firewall rule set; inbound allow-list with business justifications
Zone 2 — DMZ	Explicit allow only; absolutely no direct Zone 1 ↔ Zone 3 paths	Proxy-based authentication; no persistent sessions from Zone 1	Full traffic logging; WAF alerts; proxy access records	DMZ topology diagram; proxy and WAF configuration records
Zone 3 — Internal	Least-privilege lateral movement controls; default deny east-west traffic	MFA for all privileged access; RBAC per system and data classification	SIEM integration; user behaviour analytics; DNS query logging	Access control matrix; privileged account register; VLAN documentation
Zone 4 — Critical/OT	Application whitelist; deny-all default; no external origination permitted	Strong authentication + physical access controls for ICS consoles	Passive OT-specific monitoring — non-disruptive to industrial processes	OT asset register; segmentation diagram; change management log

Zero Trust: Implied by CIR Controls Without Being Named

Zero trust is not a technical requirement in Article 21 or CIR 2024/2690 by that name. It is, however, explicitly referenced in Recital 89 of the Directive, which states that entities should adopt “zero-trust principles” as part of basic cyber hygiene — listed alongside network segmentation, software updates, and identity and access management.

More practically: the CIR Annex controls collectively implement zero trust regardless of how organisations frame their architecture. The mapping is direct:

• No implicit trust based on network location — CIR Annex 6.8.1: zone separation means internal network position grants no automatic access to adjacent zones. Being on the corporate network does not mean being trusted by Zone 4.
• Verify explicitly before every access — CIR Annex 11 plus Article 21(2)(j): identity-based MFA and privileged account controls verify identity before access is granted, regardless of network location.
• Least-privilege access — CIR Annex 11: access rights limited to what is operationally necessary per role. A finance workstation should not be able to reach an OT historian.
• Assume breach; limit blast radius — CIR Annex 6.8.2: zone segmentation is designed on the assumption that any segment can be compromised. Controls prevent lateral spread, not just perimeter intrusion.
• Continuous monitoring and review — CIR Annex 6.7.3: security measures reviewed and updated after significant incidents or organisational changes — active monitoring is implied, not optional.

Treat every access request to sensitive systems as untrusted regardless of its network origin — whether it arrives from the external internet or from a workstation inside Zone 3. A breach in Zone 3 should be structurally unable to directly access Zone 4 resources without passing through an additional authentication checkpoint. For implementation detail on the identity controls that enforce these boundaries, see the NIS2 access control guide.

Remote Access Security Requirements

CIR Annex 6.7 specifically requires that remote access be managed through “secure connections, trusted channels and modern (latest) and secure technologies.” That language disqualifies legacy VPN configurations with weak authentication — which remain common in both SME and industrial environments.

For corporate IT environments, compliant remote access requires:

• MFA on all remote connections — Article 21(2)(j) and CIR Annex 11 make this a hard requirement, not a recommendation. See the NIS2 MFA requirements guide for a breakdown of compliant authentication methods including FIDO2 hardware keys, TOTP authenticator apps, and certificate-based authentication.
• Encrypted tunnels — TLS 1.2 minimum for browser-based access; TLS 1.3 or IKEv2/IPsec for site-to-site VPN. WireGuard is increasingly accepted as a modern, auditable alternative to legacy IPsec configurations with large attack surfaces.
• Endpoint posture verification — before network access is granted, the connecting device must meet defined security requirements: current OS patch level, endpoint protection active, disk encryption enabled. Unmanaged personal devices should not gain Zone 3 access.
• Session logging — all remote sessions logged to provide an audit trail; anomalous behaviour triggers alerting. CIR Annex 6.7.2 requires access controls to be implemented and documented.
• Automatic session termination — idle sessions disconnect after a defined timeout. Re-authentication is required for new sessions rather than silently resuming old ones.

ZTNA (Zero Trust Network Access) solutions align more closely with CIR 6.7’s intent than traditional VPNs. A conventional VPN grants broad network segment access once authenticated. ZTNA grants access to specific applications or resources per session, enforcing least privilege at the network access layer. Organisations still running legacy VPN with single-factor authentication should treat this as a high-priority compliance gap — it fails both Article 21(2)(j) and CIR Annex 6.7.

For OT and industrial environments, ISA/IEC 62443 standards complement NIS2 with specific detail. Required controls include: immediate change of all default credentials before any device connects to the network; account lockout after a defined number of failed login attempts; least-privilege access scoped to specific OT assets (a maintenance engineer accessing one PLC does not gain access to the full OT network); and complete session logging including commands executed during the maintenance window.

Wireless Network Security

Wireless access points are logically part of a zone but physically accessible beyond controlled perimeters — which makes them a segmentation risk if not explicitly assigned to defined zones with matching controls. CIR Annex 6.7’s requirement to implement access and communication controls extends to all network access methods, which includes wireless.

Baseline wireless security posture under NIS2:

• Corporate wireless (Zone 3 access): WPA3-Enterprise or WPA2-Enterprise with 802.1X authentication. Users authenticate against the corporate identity provider. Shared PSK keys are non-compliant for any SSID that provides Zone 3 network access — a compromised PSK gives any nearby device the same access as an authenticated employee.
• Guest SSID: Isolated to a dedicated VLAN mapped to Zone 2 or a guest segment with internet-only access. No lateral routing to Zone 3 internal systems. Guest traffic should be inspected at the firewall boundary and subject to bandwidth controls.
• IoT and device wireless: Separate SSID with certificate-based device authentication, VLAN-isolated from both Zone 3 and guest networks. IoT devices routinely carry unpatched firmware with known vulnerabilities — isolation prevents a compromised sensor from becoming a Zone 3 entry point.
• OT wireless (Zone 4): Strongly discouraged. Where operationally unavoidable — mobile HMI terminals, wireless field devices — use dedicated industrial wireless protocols (ISA100.11a or WirelessHART) on separate frequency bands with full VLAN isolation from corporate wireless infrastructure. No shared access points between IT and OT wireless networks.

The IT/OT Boundary and Industrial DMZ

The IT/OT boundary is the highest-risk network junction in any industrial or critical infrastructure environment. An attacker who compromises Zone 3 and moves directly into Zone 4 reaches physical process controls, not just data systems. The consequence is operational disruption or physical damage — not a data breach that can be remediated by restoring from backup.

CIR Annex 6.8.1 requires separation “from third-party systems” — which in manufacturing, energy, water, and transport contexts means IT systems that do not directly control physical processes. The industrial DMZ (IDMZ) adds a dedicated buffer layer at the IT/OT boundary, implemented as a dual-firewall architecture. One firewall faces the IT network, one faces OT — creating what Siemens describes as a “digital airlock” with application-level traffic analysis at both boundaries, not just port-level filtering.

The IDMZ contains specifically configured intermediary systems:

• Data historians: Receive one-way data replication from OT process systems and expose read-only views to IT analytics platforms. No IT system writes directly into OT through the historian. The historian is the only IDMZ system with an authorised connection into Zone 4 — and that connection is inbound-only from the OT perspective.
• Remote access jump servers: Maintenance engineers authenticate in the IDMZ before accessing specific OT assets. The access path is Zone 3 → IDMZ jump server → specific OT target. A direct Zone 3 → Zone 4 connection is never permitted.
• File transfer proxies: No direct file shares exist between IT and OT. Files are transferred via proxy, inspected for malware, and made available on the OT-side share. This eliminates shared drives as a malware propagation path — a documented entry vector in multiple industrial incidents.
• Protocol converters: Where IT and OT use different network protocols (OPC-UA, Modbus, PROFINET), converters in the IDMZ handle translation without exposing OT-native protocols to IT-side network scanning or enumeration tools.

This architecture satisfies CIR Annex 6.8’s zone separation requirement and aligns with IEC 62443-3-3, the international standard for security levels in industrial automation and control systems. No direct Zone 3 ↔ Zone 4 connections are permissible under a compliant IDMZ design.

Documentation Checklist for Network Security Compliance

CIR Annex 6.7.2 requires entities to “document network architecture.” CIR Annex 6.8.2 requires “security requirements for segmentations” to be defined in writing. ENISA’s Technical Implementation Guidance (June 2025) identifies documentation as a primary evidence category for network security audits — meaning the first thing a supervisory authority requests is not your firewall, but your diagram and your policy. The package below satisfies both CIR requirements:

• ☐ Network architecture diagram — all zones, inter-zone connections, firewall positions, and major system categories per zone. Must reflect current operational state, not a design aspiration or a diagram from three years ago.
• ☐ Segmentation policy document — each zone defined, risk classification rationale documented, traffic rules between zones stated, review schedule established. CIR Annex 6.8.3 requires review after significant incidents or organisational changes.
• ☐ Firewall rule set — all explicit allow rules documented with business justification, review date, and responsible owner. Default deny posture documented as the baseline.
• ☐ Remote access policy — approved technologies listed, authentication requirements stated, session management rules defined, OT-specific remote access procedures documented separately.
• ☐ Wireless security policy — SSID inventory, authentication method per network, VLAN assignment, access point inventory with physical location records.
• ☐ IT/OT boundary controls document — IDMZ architecture diagram, authorised data flows and flow directions, jump server configuration, historian replication policy.
• ☐ Access control matrix — who has access to which zone, using what authentication method, under what conditions. Reviewed quarterly and updated on every role change.
• ☐ Post-incident review log — records of CIR Annex 6.8.3-triggered segmentation reviews following significant incidents. Absence of this log is itself an audit finding.

Who Owns Network Security: Role and Responsibility

Responsibility	CISO	IT Security	IT Operations	OT / Engineering	Legal / Compliance
Network security policy	Owns	Reviews	Implements	Advises on OT sections	Reviews legal exposure
Zone architecture design	Approves	Designs	Implements	Advises on Zone 4	—
Firewall rule management	Reviews	Manages	Applies changes	Manages OT firewalls	—
Remote access policy	Owns	Implements	—	OT-specific controls	Verifies
Documentation and audit evidence	Reviews	Prepares technical docs	—	OT documentation	Owns and submits

Gap Analysis: Current State vs CIR Compliance

Most organisations entering NIS2 compliance have partial network controls — some segmentation, VPN for remote access, basic monitoring — but gaps in documentation, zone formalisation, or OT boundary controls. This framework maps common current states to the required state and estimates the effort to close each gap.

Current State	CIR Required State	Steps to Close	Effort
Flat network, single VLAN	Risk-based zone segmentation (CIR Annex 6.8)	VLAN design, firewall zone rules, segmentation policy documentation	High
No DMZ; servers on internal network	Zone 2 buffer between external and internal	DMZ firewall setup, server migration, topology redesign	High
Legacy VPN, single-factor authentication	MFA + modern remote access technology (CIR Annex 6.7)	MFA implementation; VPN upgrade or ZTNA deployment	Medium
Shared WiFi PSK for corporate users	Enterprise WiFi with 802.1X; guest SSID isolation	RADIUS/NPS setup, SSID restructure, policy update	Medium
Direct IT-to-OT connections	IDMZ with dual-firewall; no direct Zone 3 → Zone 4 paths	IDMZ architecture, historian migration, jump server setup	High
No documented network architecture	Architecture diagram + segmentation policy (CIR Annex 6.7.2, 6.8.2)	Documentation project — no infrastructure change required	Low

Frequently Asked Questions

Does CIR 2024/2690 apply to my organisation?
CIR 2024/2690 applies directly to cloud providers, data centres, managed service providers, CDN providers, online marketplace operators, online search engines, social network platforms, and trust service providers. All other NIS2 essential and important entities are bound by Article 21 directly. The CIR Annex represents the current detailed specification of what “appropriate and proportionate” network security measures look like — treat it as the compliance benchmark regardless of whether your entity type is in the CIR’s direct scope.

Is zero trust a mandatory requirement under NIS2?
Recital 89 of the Directive explicitly lists zero-trust principles among basic cyber hygiene practices entities should adopt. CIR 2024/2690 does not use the term in its technical controls, but its access control, MFA, and zone segmentation requirements collectively implement zero trust architecture. An organisation that fully implements CIR Annex controls operates a zero trust network in practice — whether it uses that framing or not.

How many firewalls are required between zones?
CIR Annex 6.8 requires documented zone separation with defined access controls but does not specify a firewall count. A single next-generation firewall with VLAN-based zone separation is compliant for most organisations. For the IT/OT boundary, a dual-firewall IDMZ provides significantly stronger separation and aligns with IEC 62443-3-3 — this is the recommended architecture for any entity operating industrial control systems.

What authentication method satisfies CIR Annex 6.7 for remote access?
Article 21(2)(j) mandates multi-factor authentication; CIR Annex 6.7 requires modern and secure remote access technologies. Single-factor VPN access with a password alone satisfies neither requirement. The NIS2 MFA guide covers compliant options including FIDO2 hardware keys, TOTP authenticator apps, and certificate-based authentication for OT environments.

Does NIS2 require a documented wireless security policy?
CIR Annex 6.7’s requirement to “implement access and communication controls” and to document network architecture extends to wireless segments. Wireless networks must be assigned to defined zones, access points inventoried, and authentication methods documented. Shared PSK keys for Zone 3 access are non-compliant — 802.1X enterprise authentication is the required baseline for any SSID that reaches internal corporate systems.

Network security compliance under NIS2 is an architecture decision, not a checklist item. CIR Annex 6.7 and 6.8 translate Article 21’s proportionality requirement into specific obligations: document your network, segment it by risk level, control access between zones with defined and reviewed rules, and manage remote connections through current secure technologies.

The four-zone model provides a compliant foundation that scales across organisation types and sizes. Start with documentation if your segmentation is already partially in place — a missing network architecture diagram is a low-effort, high-audit-impact gap that requires no infrastructure change to close. Then address the high-effort gaps: flat networks, direct IT/OT connections, and legacy single-factor remote access each require infrastructure investment but move your risk profile substantially. MFA upgrades and enterprise wireless sit in the middle — medium effort, and increasingly the first area supervisory authorities examine during on-site reviews.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com (cited above)
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (cited above)
3. NIS2 Implementing Act (EU) 2024/2690: NIS2, ISO 27001 Mapping — OpenKRITIS
4. NIS 2 Directive, Preamble 81–90 (Recital 89 — cyber hygiene and zero-trust principles) — nis-2-directive.com
5. NIS2 Requirements for Industrial Remote Access (Part 1) — HMS Networks
6. Industrial DMZ: Secure IT/OT Data Exchange and Segmentation — Siemens
7. NIS2 Technical Implementation Guidance — ENISA (June 2025)