NERC CIP-012 post-quantum encryption: what’s required?

NERC CIP-012 post-quantum encryption means protecting the real-time data that flows between electric utility Control Centers with key exchange that quantum computers cannot break. In practice, that usually means hybrid ML-KEM from FIPS 203, recorded in the plan that CIP-012 already requires, so the protection still holds after NIST retires RSA and elliptic-curve cryptography.

This article covers what the standard actually says and where NIST IR 8547 changes the risk picture. It also explains how CIP-005 remote access fits in, and what auditors can reasonably expect to see from a utility that says it is quantum-ready.

What does NERC CIP-012 require for encrypting data between control centres?

CIP-012 requires a documented plan that protects Real-time Assessment and Real-time monitoring data from unauthorized disclosure and modification while it travels between Control Centers. The standard does not prescribe encryption, algorithms or key lengths.

The plan has three parts:

• the security protection used
• where that protection is applied
• who is responsible for what, when the Control Centers on either end are owned by different entities

It applies to Balancing Authorities, Generator Operators, Generator Owners, Reliability Coordinators, Transmission Operators and Transmission Owners that run applicable Control Centers. FERC approved CIP-012-1 in Order No. 866. In that order it also directed NERC to look at the availability of these links, not only their confidentiality and integrity.

Two parts of the wording matter for post-quantum planning. First, “where protection is applied” leads naturally to a network-layer design: the protection sits at the boundary of each Control Center, not inside every ICCP server or EMS application. Second, the standard leaves the choice of protection to the entity. That freedom is useful, but it also means the entity has to justify its choice. NERC enforces compliance under authority delegated by FERC.

Will RSA- and ECC-based encryption still satisfy NERC CIP after NIST deprecates it in 2030?

The CIP requirement text does not mention algorithms, so RSA or ECC is not automatically a violation after 2030. But “deprecated” and later “disallowed” under NIST guidance make it steadily harder to argue that a classical-only design still reduces the risk CIP-012 is about.

NIST’s final schedule is summarised below:

NIST’s list of quantum-vulnerable algorithms includes RSA, (EC) Diffie-Hellman, MQV, ECDSA and EdDSA. Between them, these cover most of the key exchanges in today’s IPsec and TLS tunnels between Control Centers.

The harvest-now, decrypt-later question for real-time data

A fair counter-argument is that Real-time Assessment data loses its value within minutes. That is partly true. But the same tunnels also carry data with a much longer life: network topology, protection settings, operator credentials and configuration pushes. OT equipment installed in 2026 will often still be running well after 2035. And because the classical key exchange is the weak point for every session it protects, traffic recorded today can be decrypted later once the key exchange can be broken. NIST’s direction on this is clear: “With the release of the first three final PQC standards, organizations should begin migrating their systems to quantum-resistant cryptography” (NIST CSRC).

How does CIP-005 interactive remote access relate to quantum-safe VPNs?

CIP-005 Requirement R2 requires Interactive Remote Access to go through an Intermediate System, use encryption that terminates at that Intermediate System, and use multi-factor authentication. Like CIP-012, it does not say which algorithms to use, so a quantum-safe VPN can sit underneath these controls but does not replace them.

Remote access sessions are a good place to start with post-quantum protection. They carry usernames, engineering commands and vendor diagnostics, and they cross untrusted networks. CISA’s guidance for ICS remote access says: “256-bit AES encryption should be implemented from client to corporate DMZ to control system DMZ” (CISA). The symmetric layer in that guidance holds up well against quantum attacks. The exposed part is the public-key exchange that sets up the symmetric keys.

Where the tunnel ends matters

For CIP-005, the encryption that counts must terminate at the Intermediate System. A post-quantum tunnel that ends at a perimeter gateway in front of the Intermediate System adds protection on the path, but the Intermediate System’s own encrypted session still has to meet Part 2.2. Two designs are common:

• Layered: a post-quantum tunnel protects the path from the remote user to the corporate DMZ, and the Intermediate System keeps its existing encrypted session and MFA. This is easy to audit because the existing evidence does not change.
• Consolidated: the Intermediate System itself supports hybrid key exchange. There are fewer layers, but it depends on the jump-host platform supporting ML-KEM.

Device classification is the detail auditors look at most closely. A gateway that performs access control or terminates remote access encryption may count as an Electronic Access Control or Monitoring System. That brings in CIP-007 patching and CIP-010 configuration baselines. Record this decision before deployment, not after.

Can a hybrid ML-KEM tunnel be used to show CIP-012 compliance?

Yes, as long as the CIP-012 plan describes it accurately: the protection used, where it is applied and who is responsible for it. The hybrid tunnel is the control. Compliance depends on the plan and the evidence that the control works as described.

A hybrid key exchange combines a classical key agreement and ML-KEM into one session key. The session stays protected as long as either part holds. That matters because ML-KEM is new in production, while elliptic-curve exchanges have been tested in the field for decades. For CIP-012, the hybrid approach lets an entity say it has not dropped a proven control in favour of an unproven one.

Rekey frequency is worth stating explicitly. For comparison, IPsec endpoints using perfect forward secrecy typically change session keys about once an hour (NIST SP 800-77r1, 2020). Shorter intervals reduce how much traffic depends on any single key. As an example of a network-layer design, Quantum Network’s Quantum Gateway encrypts at Layer 3 at each end of a connection, combines a classical and an ML-KEM exchange into one session key, and renews both handshakes every two minutes. Whatever the tunnel, whether its configuration meets a given CIP-012 plan is for the entity and its auditors to decide.

Questions a CIP-012 plan should answer about a hybrid tunnel

• Which classical and post-quantum algorithms make up the key exchange, and at which ML-KEM parameter set?
• Which symmetric cipher and integrity check protect the payload?
• Does the tunnel fail closed? The plan should say whether traffic can ever pass unencrypted after a link failure.
• Where does each endpoint sit in relation to the Control Center boundary and existing firewalls?
• For links between entities, who manages keys and algorithm changes at each end?

Latency also belongs in the record. NIST notes that ICS are time-critical, and that acceptable delay and jitter are set by each installation. Record measured overhead on ICCP links before and after deployment.

How should utilities document post-quantum readiness for NERC CIP audits?

Treat post-quantum readiness as a cryptographic change to existing CIP evidence, not as a separate programme. Auditors respond best to the same artefacts they already review, updated with algorithm detail and a dated roadmap.

A practical evidence package

1. Cryptographic inventory: every CIP-012 link and every CIP-005 remote access path, with the current key exchange, signature scheme, symmetric cipher and the owner of each endpoint.
2. Revised CIP-012 plan: algorithm names, where protection is applied and how responsibilities are split between entities, with version history.
3. Configuration evidence: exported gateway configurations showing hybrid key exchange enabled, the rekey interval and fail-closed behaviour, included in CIP-010 baselines where the device is in scope.
4. Test records: link-failure tests showing no plaintext fallback, plus latency measurements on operational links.
5. Crypto-agility procedure: how the algorithm would be swapped if NIST updates its guidance, including change approval and supply chain review under CIP-013.
6. Roadmap tied to NIST IR 8547: target dates for each remaining classical-only path before the post-2030 deprecation and the post-2035 disallowance.

Prioritise using the same logic NIST applies to federal systems: the paths that carry the longest-lived sensitive data and that cross the most exposed networks go first. For most utilities, that means inter-entity ICCP links over carrier networks and vendor remote access, ahead of short internal links between a primary and a backup Control Center on private fibre.

NIST frames the 2030 to 2035 window as room for lower-risk systems with legacy constraints. It is not a reason for high-consequence infrastructure to wait. An entity that can show auditors an inventory, a plan update and test evidence today is in a much stronger position than one that will only start after the deprecation date has passed.