Quantum safe encryption energy sector: what is required?

In the energy sector, quantum-safe encryption means protecting data in transit between control centers, substations, pipeline stations, cloud platforms and remote engineers. It uses key agreement that resists both classical and future quantum attacks, usually by pairing a classical algorithm with a post-quantum one such as ML-KEM. The aim is to keep OT traffic confidential and intact for as long as that data matters.

For operators of critical infrastructure the question is urgent even though large quantum computers do not exist yet. OT assets often run for decades, and grid topology, protection settings and pipeline operating data stay sensitive for years. This article explains what current rules require, how European guidance sets the direction on algorithms, and how to design quantum-safe protection for SCADA and inter-site links in practice.

How are utilities preparing for quantum computing threats?

Most utilities start by building a cryptographic inventory, deciding which links need protecting first, and choosing hybrid post-quantum key agreement for new deployments. European policy supplies the clearest deadlines.

The main driver is the “harvest now, decrypt later” risk. Someone can record encrypted traffic today and store it until a quantum computer can break the RSA or elliptic-curve key exchange that protected it. For long-lived OT data this makes the migration deadline effectively earlier than the arrival of a capable quantum computer.

The European Union has put dates on the transition. EU Member States, supported by the Commission, adopted the Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography in June 2025. Its milestones matter directly to energy operators:

• All Member States should start transitioning to PQC by the end of 2026.
• By the end of 2030, high-risk use cases should be migrated, covering critical infrastructure (eg water, energy, health care, finance and transportation) and high-risk domains.
• By 31 December 2035, all of the migrations should be completed for every risk level.

National agencies also agree on method. The cybersecurity agencies of eighteen European member states published a joint statement in November 2024 identifying transition steps for critical infrastructures, public administration and industries. They emphasise that the migration is a top priority and that hybrid solutions should be put in place for its effective execution.

Does NERC CIP require encryption between control centers?

NERC CIP-012 requires protection of real-time data sent between control centers, but it does not name encryption or specific algorithms. Encryption is the most common way to meet it, and nothing in the standard addresses quantum resistance.

CIP-012 (Cyber Security, Communications between Control Centers) requires Responsible Entities to put in place a documented plan that reduces the risk of unauthorized disclosure and modification of Real-time Assessment and Real-time monitoring data while it travels between Control Centers. The standard is deliberately technology-neutral. Entities may use logical protection such as encryption, physical protection of the link, or a mix of the two, and they must identify where protection is applied and who is responsible when the Control Centers belong to different entities.

Two practical points follow. First, most entities meet CIP-012 with encrypted tunnels using classical key exchange, which is exactly the traffic exposed to harvest-now-decrypt-later risk. Second, NERC’s revision work on CIP-012 has widened its scope to cover the availability of these communications, not only confidentiality and integrity. Check which version applies to your registration. Because the standard is outcome-based, an entity can move to hybrid post-quantum key agreement within its existing CIP-012 plan without a new compliance category, as long as the plan documentation and demarcation points are kept current.

What does IEC 62443 say about cryptography?

IEC 62443-3-3 contains explicit system requirements for cryptography, communication integrity and confidentiality. It defers to accepted industry practice for algorithm choice, which leaves room for post-quantum algorithms.

IEC 62443-3-3 provides detailed technical control system requirements (SRs) associated with the seven foundational requirements (FRs) described in IEC 62443-1-1, including requirements for control system capability security levels. These requirements are used along with the defined zones and conduits for the system under consideration.

Three requirements matter most for inter-site links:

• SR 3.1 Communication integrity: requires the protection of all communications in the network, and its first requirement enhancement specifies cryptographic integrity protection at security levels three or four.
• SR 4.1 Information confidentiality: protects information in transit and at rest where confidentiality is required, which at higher security levels in practice means encryption across untrusted conduits.
• SR 4.3 Use of cryptography: where cryptography is used, it must follow commonly accepted security industry practices and recommendations.

SR 4.3 carries the most weight for quantum readiness. The standard does not freeze an algorithm list. Instead, “accepted practice” points to national guidance, and that guidance now calls for hybrid post-quantum key establishment. An asset owner who sets a target security level for a WAN conduit can reasonably read SR 4.3 as a reason to follow current post-quantum recommendations rather than legacy key exchange. The zone-and-conduit model also gives a natural place to deploy encryption: at the conduit boundary, not inside every field device.

What are TSA pipeline security requirements for encryption?

TSA Security Directive Pipeline-2021-02 and its revisions require segmentation, access control, monitoring and a tested implementation plan. They are performance-based and do not prescribe particular encryption algorithms or quantum-resistant cryptography.

TSA’s directives followed the 2021 pipeline incidents. The first directive required critical pipeline owners and operators to report confirmed and potential cybersecurity incidents to CISA and to designate a Cybersecurity Coordinator, available 24 hours a day, seven days a week. Security Directive Pipeline-2021-02 went further. In its revised, lettered versions it requires covered operators to keep an approved Cybersecurity Implementation Plan. That plan covers network segmentation between IT and OT, access control measures, continuous monitoring and detection, and timely patching, and it is backed by a Cybersecurity Assessment Program and an incident response plan.

Encryption comes in through these outcomes rather than as a line item. Protecting OT traffic that crosses segment boundaries or third-party networks is one way to show that segmentation and access control hold between sites. The scale is considerable: pipeline systems consist of more than 2.5 million miles of pipelines carrying nearly all of the nation’s natural gas and about 65 percent of hazardous liquids. Much of the telemetry from remote compressor and pump stations travels over leased or cellular links, so these are the connections to assess first for long-term confidentiality.

How do ENISA and BSI TR-02102 guide the choice of algorithms?

ENISA and the EU roadmap set timing and direction, and BSI TR-02102 gives concrete algorithm recommendations. Both point to hybrid key establishment that combines classical and post-quantum methods.

The European Commission’s 2024 Recommendation envisages deployment across the Union of Post-Quantum Cryptography technologies into existing public administration systems and critical infrastructures via hybrid schemes that may combine Post-Quantum Cryptography with existing cryptographic approaches or with Quantum Key Distribution. In the Commission’s words, “This threat can be countered by a timely, comprehensive and coordinated transition to Post-Quantum Cryptography.”

Germany’s Federal Office for Information Security (BSI) states the hybrid principle most directly. As quoted in IETF work on composite key encapsulation, BSI advises that “quantum computer-resistant methods should not be used alone - at least in a transitional period - but only in hybrid mode, i.e. in combination with a classical method.” BSI TR-02102, its technical guideline on cryptographic mechanisms, is updated regularly and is widely used outside Germany as a benchmark for what “accepted practice” means under IEC 62443 SR 4.3. Newer editions include ML-KEM, standardised by NIST in FIPS 203, as a recommended post-quantum key encapsulation mechanism for use in hybrid mode.

The reasoning holds up for OT. As an IETF draft on ML-KEM in IKEv2 puts it, the hybrid approach allows for negotiating keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. If the newer algorithm has a flaw, the classical part still protects the session, and the reverse is also true.

How to secure SCADA communications against quantum attacks?

Protect SCADA traffic at the boundaries of each OT conduit with hybrid post-quantum key agreement, frequent rekeying and fail-closed behaviour. Field devices and industrial protocols stay unchanged.

Separate the protocol layer from the transport layer

DNP3, IEC 60870-5-104 and Modbus/TCP were designed without native encryption. Where application-level security exists, it often relies on symmetric primitives, and those are not the main quantum concern. For example, the 2020 revision of IEC 62351-6 adopted symmetric-key mechanisms, specifically HMAC-SHA256 and AES-GMAC, as the recommended primitives for protecting SV and GOOSE messages over a preshared group key. The weak point is how keys are distributed and how WAN tunnels agree on session keys. So the priority is the transport across untrusted networks, not rewriting every protocol stack.

Map conduits by data lifetime

Rank each inter-site path by how long its contents stay sensitive and how exposed the path is. Typical high-priority conduits are inter-control-center links, substation uplinks over carrier networks, compressor and pump station telemetry over cellular or public internet, historian replication to a cloud tenant, and vendor or engineer remote access. Air-gapped segments still need attention when data crosses them through dedicated links.

Apply OT-specific design criteria

• No agents on field equipment: RTUs, PLCs and IEDs rarely accept new software, so encryption belongs in gateways at each end of the conduit.
• Fail closed: a tunnel must never fall back to cleartext after a line failure, and it should recover without an operator stepping in.
• Short key lifetimes: frequent rekeying limits how much traffic any one session key exposes.
• Predictable latency: control loops and protection signalling tolerate little added delay, so measure overhead under realistic load.
• Crypto agility: the post-quantum component must be replaceable if guidance changes, without redesigning the network.
• Keep firewall inspection: place encryption so that existing firewalls can still inspect traffic where policy requires it.

As one example of this gateway pattern, Quantum Network’s QPN encrypts at Layer 3 between an organisation’s own sites, with a gateway at each end of the connection and no software on the equipment behind it. It combines a classical and an ML-KEM key agreement into one session key that renews every two minutes, and it never falls back to unencrypted traffic. It sends no telemetry and has no cloud dependency, which matters for air-gapped OT networks. It does not replace a central firewall and protects data in transit, not the devices behind the gateway.

Extend the same model to cloud and remote users

OT data moving to cloud analytics and engineers connecting from laptops go through the same untrusted networks as site-to-site links. Treat them as conduits too: a virtual gateway in the organisation’s own cloud tenant or data center, and a client on engineering workstations that needs no inbound firewall ports. The result is one consistent key-agreement policy across substations, cloud and remote access, instead of separate cryptographic setups with different migration timelines.