In nuclear power plant cybersecurity, post-quantum cryptography means protecting the data that connects a plant to the outside world (corporate WAN links, emergency facility feeds, cloud analytics and remote engineering access) with key exchange that is designed to resist future quantum computers. The regulated boundary around critical digital assets stays as it is.
Quantum risk works differently in nuclear than in most sectors. Plants run for 60 to 80 years, their engineering and security data stays sensitive for decades, and the regulator moves carefully. The questions below cover what the rules require, which links are exposed, and where encryption upgrades can go without touching safety systems.
Does 10 CFR 73.54 require encryption of communication from nuclear plant networks?
Not directly. 10 CFR 73.54 is a performance-based rule that requires protection of digital systems and networks but does not name any encryption algorithm. Whether encryption is used, and which kind, is decided through the licensee’s cyber security plan and the controls in NRC Regulatory Guide 5.71 or NEI 08-09.
The rule requires nuclear power plants to provide high assurance that digital computer and communication systems and networks are adequately protected against cyber attacks, up to and including the design basis threat. The NRC describes its own approach as issuing performance-based regulations (10 CFR 73.54) and then providing detailed guidance (Regulatory Guide [RG] 5.71) on an acceptable way to meet the intent of the regulation.
Industry has a parallel route. The Nuclear Energy Institute (NEI) developed NEI 08-09, “Cyber Security Plan for Nuclear Power Reactors,” Revision 6, and the NRC staff found it acceptable. RG 5.71 is similar to NEI 08-09 in that it contains a template for the cyber security plan and a catalog of security controls. The cyber security controls were tailored from the controls in NIST SP 800-53. That family of controls includes protecting data in transit and using cryptographic mechanisms, so encryption shows up as a control to evaluate, not as a prescribed algorithm.
The NRC states the stakes plainly: “The NRC has determined that the compromise of critical digital assets (CDAs) associated with critical plant functions (e.g., safety, security, and emergency preparedness) is not acceptable.” Its threat model also explicitly covers adversely impacting the confidentiality and integrity of data and/or software. That is where harvest now, decrypt later becomes relevant.
Which nuclear plant communication links are exposed to harvest now, decrypt later?
The exposed links are the routable, encrypted connections whose traffic crosses networks the operator does not fully control and whose content stays sensitive for years. Isolated safety networks carry little of this risk. Corporate, emergency response, cloud and remote-access paths carry most of it.
The threat is simple. Although large-scale quantum computers do not yet exist, adversaries can already record encrypted traffic today and decrypt it once quantum capabilities mature. In a nuclear setting, the useful question is not “is this link encrypted?” but “how long does the data on it need to stay confidential?”
| Link type | Typical content | Confidentiality lifetime | HNDL exposure |
|---|---|---|---|
| Plant to corporate data centre (site-to-site WAN) | Historian exports, work orders, engineering change packages, configuration baselines | Long: design and configuration data stays relevant for the life of the plant | High |
| Plant to emergency operations facility and fleet support centres | Plant parameter feeds, procedures, communications during drills and events | Medium to long | High where public carrier circuits or internet transport are used |
| Edge to cloud (analytics, predictive maintenance) | Equipment condition data, performance trends | Medium: reveals plant behaviour and asset weaknesses | Medium to high |
| Remote access for engineers and vendors | Session data, credentials, design documents | Long for credentials-adjacent and security-related information | High |
| Isolated safety and protection system networks | Control and protection signals | Short operational value | Low: generally not routable to external networks |
Security-related documents need extra attention: physical protection layouts, cyber security plan details, vulnerability assessments. Their sensitivity outlives most IT refresh cycles, and they often travel between plant, corporate security teams and contractors.
How do decades-long nuclear asset lifecycles affect post-quantum migration planning?
Long lifecycles turn post-quantum migration into a design-basis question instead of an IT refresh item. Data and equipment from today will still be in service, or still sensitive, after NIST plans to retire today’s public key algorithms.
The numbers make the point:
- US licence renewals: 85 (more than 90% of the fleet) have been granted a first licence renewal, allowing operating time frames from 40 to 60 years. More recently, ten reactors have filed for subsequent licence renewals (SLRs) from 60 to 80 years. (OECD NEA, 2021)
- Global fleet age: by the end of 2020, over 100 operating reactors were older than 40 years (OECD NEA, 2021).
- Algorithm retirement: NIST IR 8547 states that NIST will deprecate all quantum-vulnerable cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035 (NIST, 2026).
- Federal acceleration: Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. (NIST, 2026)
- Standards available: NIST published the first PQC standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), in August 2024.
National Security Memorandum 10, as cited by NIST’s Dustin Moody, sets the US goal as “mitigating as much of the quantum risk as is feasible by 2035.” These federal deadlines do not bind commercial licensees directly. Still, a plant licensed to operate into the 2050s or 2060s will spend most of its remaining life in a world where today’s key exchange is formally disallowed.
Planning implications
- Separate the cryptographic layer from the asset. I&C equipment is replaced rarely and requalified expensively. Putting post-quantum protection in network gateways at link endpoints means algorithms can change without modifying qualified equipment.
- Require crypto agility in procurement. Any network security component bought now will be in service when algorithm guidance changes again, so it has to be able to change algorithms.
- Coordinate with safety engineering. The OECD NEA Working Group on Digital I&C states that cyber security requirements and safety requirements should be developed in a co-ordinated manner for the system under development throughout its lifecycle.
Can quantum-safe encryption gateways be used outside the protected critical digital asset boundary?
Yes, and that is usually the right place to start. Gateways on corporate, emergency facility, cloud and remote-access links protect data in transit outside the CDA boundary and leave the plant’s defensive architecture and qualified equipment as they are.
Outside the boundary, a gateway is a network encryption device on enterprise links and falls under normal enterprise change control. Inside the defensive architecture, or anywhere it could affect CDAs, it should go through the site’s CDA identification and assessment process like any other digital asset. Licensees should decide this explicitly and document it.
Some architectural properties make boundary-adjacent placement easier to justify:
- Layer 3 operation without endpoint changes. For example, Quantum Network’s QPN gateway encrypts at Layer 3 and installs no software on the equipment behind it. That matters where endpoints are qualified or vendor-locked.
- Co-existence with existing perimeter controls. The gateway sits in front of a firewall that still has to inspect traffic, or behind it where inspection is not needed on that path. Routes are adapted, and the architecture is not replaced.
- Hybrid key agreement. A classical and a post-quantum part (ML-KEM, per FIPS 203) are combined into one session key. Payload is encrypted with ChaCha20-Poly1305, and every packet is authenticated.
- No fallback to plaintext. After a line failure, the connection retries automatically and never drops to unencrypted traffic.
- No telemetry or cloud dependency. This fits sites that restrict outbound connections, including air-gapped networks.
What does IAEA nuclear security guidance say about cryptography for computer systems in nuclear facilities?
IAEA guidance treats cryptography as one technical measure inside a graded, zone-based computer security programme, not as a stand-alone requirement. IAEA Nuclear Security Series No. 17-T sets out the techniques. The protection applied depends on the security level assigned to each system.
IAEA Nuclear Security Series No. 17-T (Rev. 1), Computer Security Techniques for Nuclear Facilities, replaces the 2011 guide. That earlier guide was cited as IAEA (2011), “Computer Security at Nuclear Facilities”, Nuclear Security Series No. 17, International Atomic Energy Agency, Vienna. The technical guidance assigns systems to security levels and zones based on their importance to safety and security, and applies stricter measures to more critical levels. Within that model:
- The most critical levels rely mainly on isolation and one-way data flow, where cryptography adds little.
- Communication between zones, and especially beyond the facility, is where confidentiality and integrity protection of data in transit matters. The NEA consensus position likewise lists protecting communication content among cyber security features.
- Cryptographic measures must not degrade the timing, reliability or performance of safety functions. This is why latency and failure behaviour matter when evaluating any encryption device.
IEC 62645, the IEC standard for cybersecurity requirements of nuclear I&C systems, uses a similar graded model with security degrees assigned to systems. It is the main reference for programmable I&C security outside the US. Neither IEC 62645 nor NSS 17-T names post-quantum algorithms. Both expect operators to keep protections current against evolving threats, and they leave algorithm choice to national guidance such as NIST’s.
How should a nuclear operator sequence a post-quantum migration?
Start with an inventory, rank links by how long their data must stay confidential, and migrate the external routable links first. Only consider the protected levels after that, and only through the formal CDA process.
- Build a cryptographic inventory of every egress path. Include carrier circuits, VPNs to the corporate and fleet centres, cloud connectors and remote-access paths. Record the key exchange algorithm in use on each.
- Assign a confidentiality lifetime to each data flow. Anything that must stay secret past 2035 is already inside the harvest now, decrypt later window.
- Migrate site-to-site and remote-access links to hybrid key exchange. Gateway-based approaches avoid changes to endpoints. For site-to-site, edge-to-cloud and remote access, Quantum Network supports deployment as hardware gateways, virtual gateways on Linux, and clients for Windows and macOS.
- Document placement against the defensive architecture. Record whether each device sits outside the CDA boundary and why, so inspectors and internal oversight can follow the reasoning.
- Plan for algorithm change. NIST guidance will keep moving. Plan how algorithms are updated, and how air-gapped sites receive updates, before deployment.
NIST’s own advice is direct: with final standards released, organizations should begin migrating their systems to quantum-resistant cryptography. For nuclear operators, the long lifecycles make starting early more important than in most sectors.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.

Skip to content