Sovereign Infrastructure Energy Blackout Continuity: EU Compliance Guide

Sovereign infrastructure energy blackout continuity refers to the designed ability of an organisation’s own compute, storage, and communications environment to sustain essential digital services when grid power and public internet connectivity fail simultaneously. For European public-sector bodies, financial institutions, healthcare providers, and legal organisations, this is no longer an abstract risk scenario: it is an explicit compliance obligation under multiple converging regulatory frameworks.

What the EU Preparedness Union Strategy Demands from Critical Sectors

The EU Preparedness Union Strategy (COM(2025) 148), published in March 2025, treats digital continuity as inseparable from physical civil resilience. It obliges member states and critical-sector operators to plan explicitly for cascading failures, where an energy outage disables not just industrial plant but also the digital infrastructure those sectors depend on for coordination, authentication, and data access.

COM(2025) 148 frames preparedness as a cross-sector responsibility linking civil protection, critical-infrastructure resilience, and digital services. The strategy calls explicitly on operators to ensure that essential functions can continue in degraded-connectivity conditions, and mandates coordination with national authorities through the EU Civil Protection Mechanism. For a hospital, a payment processor, or a regional government, this means the continuity plan must address the scenario where Microsoft Azure, Google Cloud, or any other public cloud endpoint is simply unreachable because fibre uplinks, BGP routing, or the cloud provider’s own data centres are affected.

NIS-2 and DORA: The Specific Continuity Testing Obligations

NIS-2 Article 21(1)(c) requires essential and important entities to implement business continuity management covering backup procedures, disaster recovery, and crisis management. The practical implication is that backup and recovery must be tested against realistic failure scenarios, not only partial service degradation.

DORA Article 11 (ICT business continuity policy) tightens this further for financial entities. It requires a documented ICT business continuity policy, regular testing of continuity and recovery plans, and explicit coverage of scenarios involving the unavailability of critical ICT third-party service providers, which includes public cloud operators. Under DORA, a financial institution whose disaster-recovery plan assumes internet connectivity to its cloud-hosted identity provider cannot demonstrate compliant resilience.

The inherent advantage of sovereign infrastructure in these tests is architectural. An on-premises Nextcloud workspace, a self-hosted identity service (such as Keycloak or FreeIPA), and a locally operated certificate authority can all function without any internet dependency. Cloud-dependent organisations, by contrast, fail a blackout simulation at the authentication layer before a single file is even requested.

Architectural Design for Blackout-Resilient Sovereign Infrastructure

A sovereign data centre or on-premises deployment must be designed so that each critical service layer has a local fallback that activates automatically when external dependencies vanish.

Authentication and Directory Services

Directory services must be replicated across at least two physically separate nodes within the facility, or across two geographically dispersed on-premises locations connected by a private link. When the internet is unavailable, staff must still be able to authenticate against a local LDAP or Active Directory instance. Multi-factor authentication tokens that rely on cloud-based validation (such as SMS gateways or cloud TOTP validators) must be replaced with hardware security keys or locally validated TOTP applications.

Encrypted Communications and File Access

Internal encrypted communications, whether a Matrix-based chat platform, an encrypted email relay, or a Nextcloud Talk deployment, must route through on-premises servers. TLS certificates issued by a locally operated certificate authority prevent the scenario where a Let’s Encrypt or DigiCert OCSP check fails because the internet is down, causing browsers to refuse encrypted connections. File access through the sovereign workspace must be served from local storage with local search indexing; there must be no dependency on external CDN nodes or cloud-based metadata services.

Logging and Security Monitoring

Security information and event management (SIEM) log collection must not depend on forwarding events to a cloud-hosted SIEM. A locally operated log aggregator (such as an on-premises Wazuh or Graylog instance) ensures that audit trails continue during outages, which is directly relevant to the evidence requirements of NIS-2 supervisory authorities.

Backup Power, Out-of-Band Management, and Air-Gapped Communication

ENISA’s Good Practices for Security of Smart Grids states that “organisations should ensure that ICT systems can operate in degraded mode and that critical functions remain available during incidents, including through offline or out-of-band measures.” This guidance, while developed in the energy sector context, is cited by NIS-2 implementing guidance as applicable to all critical-infrastructure operators.

The technical stack for power resilience combines three layers: an uninterruptible power supply (UPS) system sized for at least 30 minutes of full-load operation to bridge generator start-up; one or more diesel or natural-gas generators with fuel reserves sized to the organisation’s recovery time objective (RTO); and, for sites where extended autonomy is required, photovoltaic or other local generation with battery storage. Generators must be tested under actual load, not just idle-run, at intervals of no more than 90 days.

Out-of-band management networks, using a dedicated management LAN connected to a cellular or satellite modem separate from the primary uplink, allow administrators to access server consoles, IPMI/iDRAC interfaces, and network equipment even when the primary internet link is severed. This is critical for incident response when the attack or outage has specifically targeted the primary connectivity path.

IBM’s Cost of a Data Breach Report 2023 found that the average cost of a critical-infrastructure data breach reached USD 4.82 million, the highest of any sector tracked. Extended downtime during a power or connectivity outage multiplies that cost by adding operational disruption losses on top of breach costs.

Sophos reported in its State of Ransomware 2023 report that 77% of ransomware incidents included data exfiltration before encryption. This means offline, air-gapped backups that are physically disconnected from any network during normal operations are the last reliable recovery mechanism when both ransomware and a connectivity outage occur simultaneously.

Designing Runbooks for Cloud-Dependency Failure Scenarios

Incident-response and disaster-recovery runbooks must explicitly account for the scenario where cloud-based management tooling, public DNS resolvers, and external certificate authorities are unreachable. This is not a theoretical risk: geopolitical service suspension, as demonstrated when US cloud providers suspended services to certain jurisdictions following sanctions decisions, can render cloud-dependent workflows inoperable with no advance warning.

Runbooks should define explicit fallback procedures for each dependency: internal DNS resolvers that serve cached records for all internal services; a locally operated certificate authority whose root certificate is pre-distributed to all managed endpoints; an offline copy of configuration management tooling (such as Ansible playbooks stored on an air-gapped management workstation); and pre-staged recovery media for all critical systems that does not require downloading packages from external repositories.

The runbooks must also define out-of-band communication channels for the incident-response team. Options include encrypted satellite communications under the EU’s GOVSATCOM capacity, private TETRA or LTE networks operated independently of public infrastructure, and pre-distributed encrypted messaging on air-gapped devices held at geographically separate locations.

Evidence and Documentation for NIS-2 Supervisory Authorities

Demonstrating compliance to NIS-2 supervisory authorities requires more than a written plan. Regulators expect dated test reports that specify the objectives and scope of each exercise, the failure modes that were simulated (including simultaneous grid and internet loss), the actual recovery time achieved against the stated RTO, identified gaps, and the remediation actions taken and their completion dates.

The documentation chain should link directly to the organisation’s ISO/IEC 22301-aligned business continuity management system, which provides the overarching framework within which NIS-2 and DORA obligations sit. DORA Article 11 additionally requires that ICT business continuity test results be reported to the management body, creating a governance trail that auditors can follow from board level down to individual test records.

Organisations that operate sovereign infrastructure hold a documentation advantage because their continuity controls are fully within their own audit perimeter. A cloud-dependent organisation must rely on the cloud provider’s SOC 2 reports to evidence the provider’s side of the continuity chain, but those reports do not cover the scenario where the provider’s service is simply unreachable from the customer’s location.

FAQ: Sovereign Infrastructure and Blackout Continuity Compliance

Does NIS-2 explicitly require organisations to test continuity under blackout and connectivity-loss conditions?
NIS-2 Article 21(1)(c) requires business continuity management including backup management, disaster recovery, and crisis management. ENISA guidance and the implementing acts make clear that testing must cover scenarios where primary systems and external connectivity are simultaneously unavailable, not only partial failures.

What does the EU Preparedness Union Strategy (COM(2025) 148) add beyond NIS-2 for critical-sector organisations?
COM(2025) 148 frames preparedness as a cross-sector obligation linking civil protection, critical-infrastructure resilience, and digital continuity. It calls on member states and critical-sector operators to plan for cascading failures including prolonged energy outages affecting digital infrastructure, and to coordinate through the EU Civil Protection Mechanism.

Why does sovereign on-premises infrastructure outperform cloud in a simultaneous power and connectivity outage?
Cloud services depend on internet connectivity that disappears in a grid outage or targeted infrastructure attack. Sovereign on-premises infrastructure can be powered by local UPS and generator systems, run authentication and file services without any internet dependency, and use out-of-band management networks that bypass the public internet entirely.

What evidence must a compliance officer produce to show NIS-2 supervisory authorities that blackout scenarios have been tested?
Regulators expect dated test reports showing objectives, scope, simulated failure modes (including simultaneous grid and internet loss), actual recovery time versus the stated RTO, identified gaps, and remediation actions. Evidence should link to the organisation’s ISO/IEC 22301-aligned business continuity plan and be retained for at least the audit cycle required by the applicable national NIS-2 transposition law.

Which communication technologies allow incident-response teams to coordinate when both internet and mobile networks are degraded?
Resilient options include encrypted satellite communications under the EU’s GOVSATCOM capacity, radio-based out-of-band management links, private LTE or TETRA networks operated independently of public infrastructure, and pre-distributed encrypted offline messaging systems on air-gapped devices held at geographically distributed locations.