Network Security Architecture for NIS 2 Compliance

The NIS 2 Directive (EU) 2022/2555 transposition deadline was 17 October 2024. As of mid-2025, the majority of EU member states have adopted national implementing legislation. Supervisory authorities are active. Fines for essential entities reach up to €10 million or 2% of total worldwide annual turnover, whichever is higher. For important entities, the ceiling is €7 million or 1.4%.

This is not a future compliance problem. Organisations in energy, telecommunications, transport, water, digital infrastructure, and public administration that have not yet conducted a structured gap assessment against Article 21 are operating with known exposure.

This article covers the security measures NIS 2 requires, the network architecture implications, specific considerations for OT/IT environments, and the incident reporting obligations that sit alongside them.

What Changed from NIS to NIS 2

The original NIS Directive (EU) 2016/1148 applied to Operators of Essential Services (OES) and Digital Service Providers (DSPs). Member states had discretion in identifying which organisations qualified. The result was fragmented application — an energy operator considered essential in one member state might not have been designated in another.

NIS 2 replaces this with a harmonised scope. The key changes:

Expanded entity categories. NIS 2 Annex I (essential entities) and Annex II (important entities) significantly extend coverage. New sectors added include: waste water, waste management, space, public administration, postal and courier services, food production, and manufacturing of certain critical products. Many organisations that were not in scope under NIS 1 are now.

Size-based threshold replaces designation. Under NIS 2, medium-sized enterprises (50+ employees or €10M+ turnover) operating in the listed sectors are automatically in scope as important entities. Large enterprises (250+ employees or €50M+ turnover) qualify as essential entities. Member states retain the right to designate smaller entities where they are critical to national infrastructure.

Supply chain obligations are explicit. Article 21(2)(d) and (e) specifically address supply chain security and procurement security. This was implicit in NIS 1; NIS 2 makes it a mandatory element of the security measures.

Sanctions are harmonised upward. NIS 1 left penalties to member state discretion, producing significant variation. NIS 2 establishes the minimum floor for fines and introduces temporary suspension of management for persistent non-compliance by essential entities.

Article 21: The Ten Security Measures

Article 21(1) requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage the risks posed to the security of network and information systems.

Article 21(2) specifies ten categories of measures that must be included in those policies. These are minimums, not a complete list.

(a) Policies on risk analysis and information system security. Entities must have documented risk analysis methodologies and review them regularly. Risk analysis must inform security architecture decisions, not exist as a standalone compliance document.

(b) Incident handling. Policies must cover detection, response, and recovery from security incidents. This connects directly to the Article 23 reporting obligations.

(c) Business continuity, including backup management and disaster recovery. BCP and DRP must address ICT systems specifically. Backups must be tested. Recovery time objectives must be defined and validated.

(d) Supply chain security. Security requirements must extend to direct suppliers and service providers. For critical infrastructure operators, this includes both digital and physical supply chain components.

(e) Security in network and information systems acquisition, development, and maintenance. Vulnerability handling policies and patch management are explicitly required.

(f) Policies and procedures to assess the effectiveness of security measures. Regular testing — penetration testing, vulnerability assessments — must be part of the programme, with results feeding back into risk management.

(g) Basic cyber hygiene practices and cybersecurity training. Training is mandatory, not optional. "Cyber hygiene" is defined broadly enough to include patch cadence, access management, and endpoint configuration standards.

(h) Policies on the use of cryptography and encryption. Entities must have documented policies covering where encryption is required, what standards apply, and how keys are managed.

(i) Human resources security, access control, and asset management. Privileged access management, joiners/movers/leavers processes, and asset registers are all within scope.

(j) Use of multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems where appropriate. MFA is named explicitly in the directive text rather than implied through general access control requirements.

Network Architecture Requirements

NIS 2 does not specify firewall products or particular network topologies. It requires that the security measures an entity implements are appropriate and proportionate to the risk. For critical infrastructure operators, "appropriate" in practice means:

Segmentation

Flat networks — where a compromised endpoint can reach critical operational systems — are inconsistent with the risk management obligations in Article 21(1). Network segmentation must reflect the criticality classification of systems and data.

For most essential entities, this means at minimum: separation of corporate IT from operational technology (OT), separation of internet-facing systems from internal systems, and further segmentation of systems supporting critical functions from general enterprise systems.

Micro-segmentation — defining permitted communication flows at the workload or application level rather than the network zone level — reduces the lateral movement available to an attacker who has breached a perimeter control. For entities with a large number of assets in regulated scope, this is increasingly the baseline expectation in supervisory guidance, though not yet mandated by text.

Zero Trust Network Access

ZTNA principles — verify identity and device health before granting access, apply least-privilege access per session, assume breach — align directly with Articles 21(2)(i) and 21(2)(j). Organisations replacing legacy VPN infrastructure with ZTNA architectures are simultaneously improving both security posture and compliance alignment.

The practical implementation for a critical infrastructure operator: remote access to OT systems should not grant broad network access. It should grant specific, time-limited, monitored access to specific systems, with MFA on every session. Generic VPN solutions that provide network-level access to OT environments are difficult to justify against Article 21's requirements.

Privileged Access Management

Article 21(2)(i) specifically references access control. For essential entities, privileged access — access to systems that can affect critical functions — requires controls beyond standard user authentication.

Privileged access management programmes typically include: just-in-time access provisioning (access is granted for specific tasks, not held permanently), session recording for forensic purposes, automated password rotation for service accounts, and approval workflows for sensitive access requests. Each of these controls produces audit trail evidence that maps to NIS 2's documentation requirements.

OT/IT Convergence for Energy and Critical Infrastructure

Energy generation, transmission, and distribution systems increasingly run on networked digital infrastructure. What was once air-gapped is now connected — to energy management systems, to grid management platforms, to remote monitoring and diagnostics. This creates security exposures that did not exist in the previous architecture.

NIS 2 applies to the network and information systems that entities use. For an energy operator, this includes SCADA systems, industrial control systems (ICS), distributed control systems (DCS), and the IT infrastructure that manages and monitors them.

The specific challenges in OT environments:

Legacy systems with no patching path. Many OT components run on operating systems or firmware that are no longer supported. Patching in the conventional sense is not always possible. The compensating controls — network isolation, application whitelisting, enhanced monitoring — must be documented and must be demonstrably proportionate to the risk.

Availability is the primary objective. OT security must not compromise operational continuity. Security controls that would be standard in an IT environment — aggressive patching windows, endpoint agents with high resource consumption — may be inappropriate for OT systems where uptime is safety-critical. The security architecture must be designed for the OT context, not adapted from IT practice.

Incident detection in OT environments requires OT-specific tooling. Standard IT security monitoring tools are often incompatible with OT protocols (Modbus, DNP3, IEC 61850, PROFINET). Monitoring solutions must be capable of parsing OT traffic to detect anomalies without actively disrupting communications.

The convergence point — where corporate IT and OT networks connect — is consistently the highest-risk boundary in critical infrastructure environments. Unidirectional security gateways (data diodes), application-layer firewalls that understand OT protocols, and strict allowlisting of permitted traffic flows at this boundary are standard architecture components for essential entities.

Cryptography and Encryption Requirements

Article 21(2)(h) requires documented policies on cryptography and encryption. The policy must answer: which data requires encryption at rest, which requires encryption in transit, what standards and algorithms are approved, and how keys are managed.

For network security specifically, the implications include:

• TLS 1.2 at minimum for all inter-system communications carrying sensitive or regulated data; TLS 1.3 preferred

• Deprecated protocols (SSL 3.0, TLS 1.0, TLS 1.1) must be disabled across the environment

• VPN tunnels for site-to-site connectivity must use current cipher suites; legacy configurations based on DES or 3DES are not acceptable

• Certificate lifecycle management — expiry, renewal, revocation — must be tracked and automated where possible; expired certificates on public-facing systems are an audit finding and an operational risk

The ENISA publication Algorithms, Key Sizes and Parameters Report provides guidance aligned with current best practice. ENISA updates this periodically; the policy should reference the current version rather than hardcoding algorithm names that may become deprecated.

Threat Detection Capabilities

Article 21(2)(f) requires that entities assess the effectiveness of their security measures. This implies detection capability: an organisation that cannot detect a breach cannot assess whether its controls are working.

For essential entities, the supervisory expectation — visible in guidance from ENISA and sector-specific bodies — is continuous monitoring with the ability to detect anomalous activity across network, endpoint, and application layers. This does not prescribe specific product categories, but the functional requirement maps to what log management, SIEM, and EDR capabilities deliver.

OT environments require monitoring that can operate passively — without sending probes or active queries that could disrupt control systems. Passive network monitoring, protocol-aware anomaly detection, and baseline deviation analysis are the applicable approaches.

The key integration point: detection must feed into incident response. A monitoring capability that generates alerts into a queue that no one reviews does not satisfy Article 21. Detection without response is not incident handling.

Article 23: Incident Reporting Timelines

Article 23 establishes mandatory reporting for significant incidents. The definition of "significant" includes: incidents that have caused or are capable of causing severe operational disruption, financial loss, or harm to individuals.

The reporting structure has three stages:

Early warning — within 24 hours of becoming aware of a significant incident. The early warning must indicate whether the incident is suspected to be caused by unlawful or malicious action and whether it is likely to have cross-border impact. The 24-hour clock starts from awareness, not from detection.

Incident notification — within 72 hours. A more complete notification covering: initial assessment of the incident, severity, and impact; indicators of compromise where available; and the measures taken or planned. If the early warning was submitted, the notification updates it.

Final report — within one month of submitting the notification. A detailed description of the incident, type of threat or root cause, applied and ongoing countermeasures, and cross-border impact if applicable.

The practical implication for network security architecture: the 24-hour early warning timeline requires that detection and triage occur well within that window. An organisation that takes 20 hours to determine whether an alert represents a significant incident has no time to draft a regulator notification. Detection tooling and incident triage procedures must be fast enough to support this cadence.

For entities subject to both NIS 2 and DORA, the reporting obligations interact. DORA Article 19 has its own timelines (initial notification, intermediate report, final report) for major ICT incidents. The EBA and ESAs have published guidance on avoiding double reporting where possible, but entities must verify which obligation applies to each incident type.

Preparing for NIS 2 Supervisory Examination

Competent authorities are conducting examinations under their national NIS 2 implementing legislation. Based on published inspection frameworks from ENISA and member state authorities, the typical examination sequence for network security covers:

1. Documentation of risk analysis methodology and outcomes

2. Network architecture diagrams — current state, including OT/IT boundaries

3. Segmentation design and evidence of implementation

4. Privileged access management procedures and evidence of operation

5. Incident detection and response procedures

6. Cryptographic policy documentation

7. Recent test results — penetration test reports, vulnerability assessment outputs

8. Evidence of management review and board-level governance

Gaps identified in examination typically result in binding instructions with remediation timelines, followed by follow-up examination. Financial penalties are imposed where instructions are not met or where the gap represents a systemic failure of the security measures required by Article 21.

If you are assessing your network architecture against NIS 2 obligations or preparing for a supervisory examination, we conduct gap analyses structured around Article 21 requirements for essential and important entities. Reach out to discuss your situation.