sota.io
2026-04-09·10 min read·sota.io team

EU NIS2 Directive 2024: Critical Infrastructure Security and Formal Verification Compliance

The EU Network and Information Security Directive 2 — Directive (EU) 2022/2555, known as NIS2 — entered into force on 16 January 2023, with a transposition deadline of 17 October 2024. It replaces NIS1 (Directive 2016/1148) and expands EU cybersecurity law from approximately 5,000 covered entities to more than 160,000. The scale change is deliberate: every significant energy operator, rail network, hospital system, water utility, and digital infrastructure provider in the EU is now subject to binding security obligations backed by GDPR-style penalties.

For developers building software for Deutsche Bahn, Siemens Energy, TenneT, Charité Berlin, E.ON, RWE, or any of the hundreds of critical infrastructure operators across Germany, France, and the Netherlands, NIS2 creates an infrastructure compliance layer that intersects directly with where your code runs and on whose infrastructure.

The intersection of NIS2's supply chain security requirements (Art. 21) with the CLOUD Act exposure of US-domiciled infrastructure providers creates a structural compliance gap — one that EU-native infrastructure and formally verified software directly addresses.

NIS2 Scope: The 160,000-Entity Expansion

NIS2 divides covered entities into two categories based on sector and size:

Essential Entities (Annex I): Energy (electricity, oil, gas, district heating, hydrogen), transport (air, rail, water, road), banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (IXPs, DNS, TLD registries, cloud providers, data centres, CDNs, TSPs), ICT service management (MSPs), space. Must have ≥250 employees or >€50M turnover, or be classified regardless of size (DNS, TLD, IXPs, critical national infrastructure).

Important Entities (Annex II): Postal and courier services, waste management, manufacture of chemicals, food production, manufacturing (medical devices, computers, machinery, motor vehicles, transport equipment), digital providers (online marketplaces, search engines, social networks), research organisations.

In Germany, the implementing legislation is the NIS2UmsuCG (NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz). Germany missed the October 2024 transposition deadline — the largest EU member state to do so — due to the collapse of the Scholz coalition in late 2024. The competent national authority is the BSI (Bundesamt für Sicherheit in der Informationstechnik). German operators face a two-stage compliance window: formal NIS2 obligations apply directly from EU level even before full national transposition.

In France, ANSSI (Agence nationale de la sécurité des systèmes d'information) implements NIS2 through transposition completed in 2025. In the Netherlands, the NCSC (Nationaal Cyber Security Centrum) manages compliance for critical infrastructure operators including TenneT, ProRail, and Vitens.

Article 21: The Security Obligation Framework

Article 21 of NIS2 establishes the core cybersecurity measures that essential and important entities must implement. Unlike NIS1's vague "appropriate and proportionate measures," NIS2 Art. 21(2) enumerates ten specific measure categories:

(a) Risk analysis and information system security policies (b) Incident handling (prevention, detection, response) (c) Business continuity and crisis management, including backup management, disaster recovery, and crisis management (d) Supply chain security, including security aspects concerning the relationships between each entity and its direct suppliers or service providers (e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures (g) Basic cyber hygiene practices and cybersecurity training (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption (i) Human resources security, access control policies and asset management (j) The use of multi-factor authentication or continuous authentication solutions, secure voice, video and text communications and secured emergency communication systems, where appropriate

Art. 21(2)(d) — supply chain security — is the provision that makes infrastructure choices an auditable compliance matter. Every critical infrastructure operator must assess the security of their ICT supply chain, including their cloud providers, MSPs, and software vendors.

The Supply Chain Security Requirement

NIS2 Art. 21(2)(d) requires covered entities to assess the security practices of their direct suppliers and service providers. This is not a voluntary exercise: the European Union Agency for Cybersecurity (ENISA) published supply chain security guidelines in 2023 that specify what this assessment must cover.

For a German hospital using Microsoft Azure for clinical data systems, the supply chain assessment must address:

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2523) — enacted by the US Congress in 2018 — is the operative legal mechanism here. It authorises US law enforcement to compel US-domiciled companies (Microsoft, Amazon, Google, Oracle) to produce data held anywhere in the world, including in EU data centres, through a direct executive agreement mechanism that bypasses EU legal process.

The CLOUD Act Intersection with NIS2 Art. 21

ENISA's NIS2 supply chain security framework requires covered entities to document:

  1. Legal jurisdiction of each critical ICT provider
  2. Data residency guarantees in contractual form
  3. Third-country access risk assessment for each critical system
  4. Mitigation measures for identified jurisdictional risks

For AWS eu-central-1 (Frankfurt), Azure westeurope (Netherlands), and Google europe-west3 (Frankfurt), the legal jurisdiction analysis produces the same result: the parent company (Amazon.com Inc., Microsoft Corporation, Alphabet Inc.) is incorporated in the United States and subject to CLOUD Act obligations regardless of where the data centre is located.

The CLOUD Act Executive Agreement mechanism — currently active between the US and UK, with negotiations ongoing for US-EU framework — allows US authorities to issue production orders directly to US cloud providers without going through MLAT (Mutual Legal Assistance Treaty) processes. For NIS2-covered critical infrastructure operators, this creates an auditable supply chain risk that Art. 21(2)(d) requires them to address.

Practical implication for German energy operators: E.ON, RWE, EnBW, and the regional grid operators (NetConnect Germany, Bayernwerk Netz) running SCADA systems, energy management software, or operational technology on AWS or Azure infrastructure must document this CLOUD Act exposure in their NIS2 Art. 21 supply chain security assessment. BSI's technical guidelines (BSI-Technische Richtlinien, specifically TR-03116) provide the framework for this assessment.

Practical implication for rail operators: Deutsche Bahn's IT infrastructure — including ETCS (European Train Control System) adjacent software, passenger information systems, and operational management platforms — runs on hybrid cloud infrastructure. NIS2 makes the supply chain risk of US cloud dependencies an auditable compliance item for DB Netz AG (the infrastructure subsidiary).

Incident Reporting: The 24/72 Hour Obligation

NIS2 Art. 23 establishes incident reporting obligations that are stricter than any prior EU regulation:

A "significant incident" under NIS2 is defined as one that causes or could cause severe operational disruption, financial loss to the affected entity, or material damage to other natural or legal persons.

The 24-hour initial notification requirement is faster than GDPR's 72-hour data breach notification. For healthcare operators (Charité, Universitätsklinikum Heidelberg, AP-HP), this creates a dual notification obligation: GDPR breach → 72h, NIS2 incident → 24h. The NIS2 obligation triggers first.

Formal Verification for NIS2 Critical Infrastructure: The EU-Native Stack

NIS2 Art. 21(2)(e) requires entities to address "security in network and information systems acquisition, development and maintenance, including vulnerability handling." For critical infrastructure operators, this means the software that controls energy grids, manages rail signalling, processes clinical records, or operates water treatment plants must meet security standards that go beyond conventional testing.

Formal verification — mathematically proving that software satisfies its security and safety specifications — provides the strongest available evidence of compliance with NIS2's risk management requirements. The EU has a significant domestic formal verification ecosystem that operates entirely outside US cloud and legal infrastructure.

SPARK Ada — Critical Infrastructure Control Software (AdaCore, Paris)

AdaCore (founded 1994, Paris, France) develops SPARK Ada: a formally verifiable subset of the Ada programming language with integrated contract-based verification. SPARK has been deployed in:

AdaCore's toolchain — GNATprove (SPARK verification), CodePeer (static analysis), GNAT Pro — is fully EU-native. No US parent company, no CLOUD Act exposure in the verification toolchain itself.

Frama-C — C Code Analysis for Industrial Control Systems (CEA/INRIA, France)

Frama-C (Framework for Modular Analysis of C programs) is developed by CEA (Commissariat à l'énergie atomique) and INRIA (Institut national de recherche en informatique et en automatique) in France. Both are French public research institutions outside any US jurisdiction.

Frama-C's plugins cover:

German energy operators running SCADA systems in C (Siemens SIMATIC WinCC, Schneider Electric EcoStruxure) can use Frama-C to formally verify the control logic — generating machine-checkable proofs that NIS2 Art. 21(2)(e) security requirements are met at the code level rather than through documentation alone.

ProVerif — Protocol Security Verification (INRIA Paris)

ProVerif is an automatic cryptographic protocol verifier developed by Bruno Blanchet at INRIA Paris. It verifies properties of security protocols — authentication, confidentiality, non-repudiation — through automated reasoning over the applied pi calculus.

NIS2 Art. 21(2)(h) mandates policies on cryptography and encryption. ProVerif allows covered entities to formally verify that their protocol implementations are correct before deployment:

ProVerif is entirely INRIA-developed and maintained — no US IP, no CLOUD Act risk in the verification toolchain.

UPPAAL — Real-Time System Verification (Uppsala/Aalborg Universities)

UPPAAL is a model checker for real-time systems developed jointly by Uppsala University (Sweden) and Aalborg University (Denmark). It verifies timed automata models — particularly relevant for critical infrastructure with strict timing constraints.

NIS2-covered transport and energy operators use UPPAAL for:

Uppsala University and Aalborg University are Nordic public universities — no US corporate parent, fully EU academic infrastructure.

TLA+ — Distributed System Specification (Leslie Lamport, EU Academic Applications)

TLA+ (Temporal Logic of Actions) was developed by Leslie Lamport at DEC SRC and is now maintained by Microsoft Research. While the toolchain has US origins, TLA+ specifications and proofs are academic artifacts used extensively by EU universities for critical infrastructure research.

The TLA+ Proof System (TLAPS) is co-developed by INRIA (French Research Team at Microsoft Research) and Microsoft. European energy operators and rail operators use TLA+ for distributed consensus verification — verifying that SCADA supervisory control systems, energy management systems, and rail traffic management systems maintain consistency under network partitions and node failures.

Note on toolchain sovereignty: For NIS2 compliance, the verification toolchain must itself be assessed under Art. 21(2)(d) supply chain security. Fully EU-native options (SPARK Ada, Frama-C, ProVerif, UPPAAL) avoid CLOUD Act exposure in the verification toolchain itself. TLA+ is a hybrid — the spec language is usable independently of US cloud infrastructure.

NIS2 + CLOUD Act: The Specific Infrastructure Gap

NIS2 Art. 21(2)(d) supply chain security assessment creates a specific documentation requirement that EU-native infrastructure directly satisfies.

When a German hospital (essential entity under NIS2 healthcare sector) runs its clinical data platform on AWS eu-central-1, its Art. 21 compliance documentation must include:

  1. Supply chain risk assessment for AWS as an ICT provider
  2. Jurisdiction analysis: Amazon.com Inc. = US-incorporated, CLOUD Act-subject
  3. Data location: eu-central-1 (Frankfurt) — physically EU, legally US-accessible
  4. Mitigation measure: Either contractual US law enforcement response protocol with AWS, or migration to EU-native infrastructure

The NIS2 compliance documentation does not prohibit using US cloud providers. It requires the risk to be assessed, documented, and mitigated. The mitigation options range from contractual addenda (difficult to enforce against CLOUD Act production orders) to encryption (key custody must remain EU-controlled to be effective) to EU-native infrastructure (removes CLOUD Act risk from the assessment).

EU-native PaaS under NIS2 Art. 21 assessment:

ProviderIncorporationCLOUD Act SubjectNIS2 Art. 21(2)(d) Risk
AWS eu-central-1Amazon.com Inc. (Delaware, US)YesMust document + mitigate
Azure westeuropeMicrosoft Corporation (Washington, US)YesMust document + mitigate
Google europe-west3Alphabet Inc. (Delaware, US)YesMust document + mitigate
OVHcloud (FR)OVH SAS (Roubaix, France)NoResidual risk only
Clever Cloud (FR)Clever Cloud SAS (Nantes, France)NoResidual risk only
sota.ioEU-incorporatedNoNo US jurisdictional risk
Scalingo (FR)Scalingo SAS (Strasbourg, France)NoResidual risk only

For the 160,000 NIS2-covered entities performing their Art. 21(2)(d) supply chain assessment, this table represents a direct infrastructure selection criterion — not a preference, but a documented compliance requirement.

Germany-Specific NIS2 Implementation: BSI and NIS2UmsuCG

Germany's NIS2 implementation status as of April 2026:

The NIS2UmsuCG (NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) passed the German Bundestag in March 2025 after extended delays caused by the coalition collapse. It entered into force in Q2 2025. The BSI is the competent authority for most sectors; sector-specific authorities (Bundesnetzagentur for energy and telecom, Eisenbahn-Bundesamt for rail, BfArM for healthcare devices) have co-competence for their domains.

Key German-specific NIS2 provisions:

KRITIS-Dachgesetz: Germany implemented an additional KRITIS umbrella law alongside NIS2UmsuCG, covering physical security of critical infrastructure alongside cyber security. Critical infrastructure operators must now address both physical and cyber resilience in a unified framework.

BSI Critical Infrastructure Thresholds: The BSI maintains sector-specific thresholds (Schwellenwerte) above which operators become KRITIS-regulated. Under NIS2UmsuCG, thresholds are being revised upward to align with EU definitions — broadening the regulated scope.

Registration obligation: German NIS2 entities must self-register with BSI within 3 months of meeting the threshold criteria. The registration must include ICT service provider information — directly feeding into the Art. 28(3)-equivalent register requirement.

BSI Technical Guidelines (BSI-TR): BSI-TR-02102 (cryptographic standards), BSI-TR-03116 (cloud security), and BSI-TR-03153 (technical guidelines for energy sector) provide the technical compliance baseline. Formal verification evidence — SPARK proofs, Frama-C verification reports, ProVerif protocol analysis — maps directly to BSI-TR-03116 cloud security and BSI-TR-03153 control system security requirements.

Healthcare Sector: Charité, AP-HP, and Clinical Systems Under NIS2

Healthcare is an essential sector under NIS2 Annex I. German university hospitals (Charité Berlin, Universitätsklinikum München, Universitätsklinikum Heidelberg), French AP-HP (Assistance Publique-Hôpitaux de Paris), and Dutch AMC (Amsterdam UMC) are essential entities subject to NIS2's full obligations.

For hospital IT departments building or deploying clinical software:

NIS2 Art. 21(2)(e) vulnerability management requires systematic vulnerability scanning, patching timelines, and disclosure procedures. Formally verified components — patient data management modules written in SPARK Ada, clinical protocol implementations verified with ProVerif — provide the strongest available compliance evidence.

NIS2 Art. 21(2)(h) cryptography requires policies on encryption and key management. Clinical data at rest and in transit must be encrypted under validated algorithms. For GDPR-NIS2 intersection, the key custody question is critical: encryption does not mitigate CLOUD Act risk if the cloud provider holds the encryption keys (as with default AWS KMS or Azure Key Vault managed keys).

EU-native approach: Clinical data platforms running on EU-native infrastructure (sota.io, OVHcloud, Clever Cloud) with customer-managed encryption keys remove the CLOUD Act key custody problem. Combined with formally verified application code (Frama-C for C-based clinical middleware, SPARK Ada for safety-critical medical device software under MDR), hospitals can demonstrate NIS2 Art. 21 compliance through a complete EU-native evidence chain.

NIS2 Reporting Obligations and Formal Verification Evidence

NIS2 Art. 23's incident reporting structure creates a documentation requirement that formal verification supports in a specific way.

When a covered entity experiences a significant incident — ransomware attack on a water treatment control system, DDoS on a rail signalling network, data breach in a hospital management system — the competent authority (BSI, ANSSI, NCSC) will request:

For entities that have formal verification reports in their compliance documentation — SPARK Ada GNATprove output showing absence of buffer overflows, Frama-C WP verification showing contract satisfaction, ProVerif analysis showing protocol authentication guarantees — the answer to the third question is often yes. Formally verified code eliminates entire classes of vulnerabilities at the proof level rather than through post-hoc testing.

This creates a compliance incentive structure: entities that invest in formal verification now have a stronger Art. 21 compliance posture and a stronger incident response documentation baseline under Art. 23.

NIS2 vs DORA: The Overlapping Compliance Landscape

For financial infrastructure operators — banks (NIS2 essential + DORA-covered), payment institutions (NIS2 important + DORA-covered), CCPs (NIS2 essential + DORA-covered) — both frameworks apply simultaneously.

The NIS2/DORA overlap creates both a compliance burden and an opportunity:

Burden: Dual reporting obligations (NIS2: 24h → 72h → 1 month; DORA: 4h → 72h → 1 month). Different competent authorities (BSI/ANSSI/NCSC for NIS2; BaFin/AMF/DNB for DORA). Separate registers (NIS2 ICT provider register + DORA ICT third-party register).

Opportunity: A single EU-native infrastructure and formal verification posture satisfies supply chain security requirements for both frameworks simultaneously. CLOUD Act analysis done once for DORA Art. 28/30 compliance applies directly to NIS2 Art. 21(2)(d) supply chain assessment. Formal verification artifacts (SPARK, Frama-C, ProVerif) satisfy both NIS2 Art. 21(2)(e) and DORA Art. 9 (ICT risk management framework) security evidence requirements.

For DACH financial infrastructure operators managing dual NIS2/DORA compliance, an EU-native infrastructure stack eliminates the CLOUD Act analysis from both compliance chains simultaneously.

Practical NIS2 Compliance Checklist for EU Developers

For development teams at NIS2-covered entities:

Assess your infrastructure: Identify every cloud provider, SaaS tool, and MSP in your ICT supply chain. Classify by NIS2 Art. 21(2)(d) supply chain risk (US-incorporated → CLOUD Act risk → document).

Implement formal verification where critical: SPARK Ada for new safety-critical control system code. Frama-C for existing C-based control system code. ProVerif for new or modified authentication protocol implementations. UPPAAL for real-time system verification.

Document the evidence chain: NIS2 compliance is not a one-time audit — competent authorities can request documentation at any time. Maintain GNATprove output, Frama-C verification reports, ProVerif session transcripts as compliance artifacts alongside your Art. 21 risk management documentation.

Select EU-native infrastructure for critical systems: For systems processing data that triggers Art. 21(2)(d) documentation requirements (critical operational data, incident-related data, supply chain management data), EU-native infrastructure removes the CLOUD Act risk from the documentation entirely rather than requiring ongoing risk monitoring and mitigation.

Prepare for BSI registration: German entities meeting NIS2UmsuCG thresholds must register with BSI within 3 months. The registration includes ICT provider information — your supply chain assessment should be complete before the registration deadline, not after.

NIS2's transition from 5,000 to 160,000 covered entities is not gradual. Every significant energy operator, rail system, hospital, and water utility in the EU is now within scope. The compliance gap between US cloud infrastructure's CLOUD Act exposure and NIS2 Art. 21's supply chain security obligations is not a future risk — it is a present documentation requirement that every competent authority in Europe will begin enforcing through 2025 and 2026.

The formal verification tools that close the NIS2 technical compliance gap — SPARK Ada (AdaCore Paris), Frama-C (CEA/INRIA France), ProVerif (INRIA Paris), UPPAAL (Uppsala/Aalborg) — are entirely EU-native. The infrastructure that closes the supply chain security documentation gap is equally available. The compliance clock started in October 2024.

See also: