NIS 2 network security under Article 21(2)(e)
NIS 2 says your network and information systems must be secure across acquisition, development and maintenance. Article 21(2)(e) is where the duty lives, CIR (EU) 2024/2690 §6.7 and §6.8 spell out the network-specific pieces, and §30(2)(5) BSIG is the German transposition.
The short version
Article 21(2)(e) is the fifth on the list of ten cybersecurity duties under NIS 2. It covers the full lifecycle of network and information systems: how you buy them, how you build them, and how you keep them running safely. CIR (EU) 2024/2690 §6 then operationalises this across several sub-sections. The network-specific pieces are §6.7 (network security) and §6.8 (network segmentation).
§6.7 is the harder of the two to read. Twelve concrete actions, from documenting your network architecture to running DNS hygiene and securing email. §6.8 is the simpler one: split your network into zones based on what each zone needs to do, and keep production, test and admin traffic apart.
Germany puts the same duty into national law through §30(2)(5) BSIG. The BSI points at IT-Grundschutz NET.1 (Netze und Kommunikation) and NET.3.2 (Firewall) as the practical implementation route. This page walks the directive, the CIR, and the German layer in that order.
Article 21(2)(e) NIS 2 Directive (2022/2555)
Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
Point (e) on the Article 21(2) list. It covers the full lifecycle of your network and IT systems, not just the running state. CIR §6 then breaks that into multiple sub-sections. §6.7 and §6.8 are the network-specific ones.
CIR (EU) 2024/2690, Annex §6.7 and §6.8
§6.7 Network security. The relevant entities shall take the appropriate measures to protect their network and information systems from cyber threats. §6.8 Network segmentation. The relevant entities shall segment their systems […] into networks or zones in accordance with the results of the risk assessment […]; they shall also segment their own systems and networks from third-party systems and networks.
Because this is a regulation (not a directive), it is directly binding EU law. §6.7 lists twelve concrete actions, from documented network architecture to DNS and email hygiene. §6.8 lists eight segmentation actions, including DMZ, separation of administration networks, and separation of production from development and test.
§30(2)(5) BSIG (Germany)
Security measures in the acquisition, development and maintenance of information technology systems, components and processes, including vulnerability management and disclosure.
Germany copies the EU text almost word for word. The BSI then points at IT-Grundschutz NET.1 (Netze und Kommunikation) and NET.3.2 (Firewall) as the recognised implementation route for the §6.7 and §6.8 detail.
Document the network, control internal access
Keep a current and clear diagram of your network architecture. Define and apply controls to protect internal domains from unauthorised access. Block connections and services that are not needed. Define separate controls for remote access, including supplier remote access. Do not let admin systems be used for anything else. Switch off or explicitly forbid connections and services you do not use.
Device-, protocol-, DNS- and email-level hygiene
Where appropriate, restrict access to approved devices only. Let supplier connections in only after an approval request and only for a defined time window (for example, maintenance). Run system-to-system communication over trusted channels, separated logically, cryptographically or physically, with secure endpoint identification. Plan and accelerate the move to modern network-layer protocols. Adopt modern interoperable email standards to close email-related vulnerabilities. Apply proven DNS-security and routing-hygiene practices for inbound and outbound traffic.
Segment by risk, separate prod from test and admin
Segment your systems into networks or zones using the §2.1 risk-assessment output, not just convenience. Consider functional, logical, physical and location ties between trusted systems. Grant zone access based on the security requirements of that zone. Put systems indispensable to operations or security inside secured zones. Run a DMZ on communications networks. Restrict access to and within zones to what operations need. Run a dedicated administration network for systems, separated from the operational network. Keep network-administration channels separate from other traffic. Keep production systems for live services separate from development and test, including their backups.
Segment by risk, not by convenience
CIR §6.8.2 ties segmentation back to §2.1: the risk assessment is what tells you which zones you need and how strict the boundaries between them have to be. A flat network with one firewall is not segmentation. Zones based on what each part of the business actually does, and on the risk it carries, is. If you cannot point at the risk-assessment line that justifies a zone, you do not have segmentation by the standard's definition.
Document the architecture, keep it current
§6.7.2(a) is the first action on the list for a reason. Everything else in §6.7 and §6.8 relies on a documented and current network diagram. Auditors look at the diagram first. If it does not exist, or it is two years out of date, every other control becomes harder to verify. Treat the diagram as a living document, not as a one-off Visio file.
BSI / §30(2)(5) BSIG / IT-Grundschutz
The BSI points at IT-Grundschutz NET.1 (Netze und Kommunikation) for general network design and NET.3.2 (Firewall) for the perimeter and segmentation controls. Both Bausteine map onto the §6.7 and §6.8 actions almost one for one. If you already run a Grundschutz-conform network, you can use the existing documentation as your evidence base.
ENISA Technical Implementation Guidance
ENISA's TIG covers Art. 21(2)(e) and the CIR §6 sub-sections, including network security and segmentation. It maps the requirements onto ISO/IEC 27001:2022 controls (A.8.20 Network security, A.8.21 Security of network services, A.8.22 Segregation of networks) and onto NIST CSF 2.0 PR.IR (Technology Infrastructure Resilience). If you already run one of these, you can reuse the controls.
National transposition laws
Other member states transpose Art. 21(2)(e) into their own laws (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The substance is identical because the CIR §6 detail binds the named sectors directly. What differs is which agency you talk to and which national implementation guidance you read alongside the CIR.
We have a firewall, so we are covered.
A firewall is good. It is not the whole §6.7. §6.7.2(a) wants a documented and current network architecture. §6.7.2(c) wants unused connections and services blocked by default. §6.7.2(f) wants unused services explicitly forbidden or deactivated. §6.8 wants segmentation by risk. A firewall without those four pieces meets one line of §6.7, not the section.
Production and test sit on the same network because it is easier.
§6.8.2(h) is explicit: production systems for live services must be separated from development and test, including their backups. This is one of the hardest gaps to retrofit and one of the easiest for an auditor to spot. A shared subnet for prod and test will not survive the §6.8 review.
Our admins log into the firewall from their regular workstations.
§6.8.2(f) wants a separate administration network for systems. §6.8.2(g) wants the administration channels separated from other network traffic. Logging into a firewall from a workstation that also runs email and a browser breaks both. Use a dedicated jump host or a privileged-access workstation, on a separate management VLAN.
A typical 60-to-250-person Mittelstand network already has a firewall and often a DMZ. The §6.7 and §6.8 gaps we see are usually the same three: no documented network diagram, no dedicated administration network, and prod and test sitting on the same subnet. Each of those is cheap to write down once and painful to retrofit later.
The pragmatic order: draw the current network on one page, segment by what each zone actually does (office, server, DMZ, OT or production, admin), write down which connections are allowed between zones and why, and pull admin access into a separate management VLAN with a jump host. That covers §6.7.2(a), the segmentation core of §6.8, and the admin-network separation in §6.8.2(f) and (g). The rest is hygiene that follows from there.
The PRO module on the platform holds the network architecture inventory, the segmentation rules, and the admin-network register. You record each zone, what it does, what it connects to, and which risk-assessment line justifies it. The diagram and the segmentation logic live in one place, not split between a Visio file and a Confluence page.
Changes to the network are recorded as they happen, so §6.7.2(a) stays a living document instead of a snapshot. The audit trail captures who changed what and when, which is the evidence an auditor wants to see when they ask whether the documentation reflects reality.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §6.7 and §6.8 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(5) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) and NET.3.2 (Firewall) — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)