OPC UA post-quantum security: is OPC UA quantum-safe?

OPC UA post-quantum security is about whether OPC UA (IEC 62541) can protect industrial communication against attackers who have, or will one day have, a cryptographically relevant quantum computer. The OPC UA secure channel sets up its session keys with RSA or elliptic curve cryptography, and a large quantum computer could break both. That puts recorded OPC UA traffic at long-term risk.

This article explains which OPC UA security policies are exposed, why recorded process data matters today, where standardisation stands, and how organisations running OT and critical infrastructure can protect OPC UA traffic between sites, to the cloud and for remote users while native post-quantum policies are not yet available.

Are OPC UA security policies vulnerable to quantum computers?

Yes, partly. The asymmetric cryptography that authenticates OPC UA applications and sets up session keys is vulnerable to Shor’s algorithm. The symmetric encryption that protects the data afterwards is much less affected.

The IEC 62541-2 security model (OPC UA Part 2) describes how OPC UA delivers authentication, confidentiality and integrity. Each server endpoint advertises a Security Mode (None, Sign or SignAndEncrypt) and a Security Policy. The Security Policy defines the cryptographic primitives in use. Importantly, OPC UA does not force anyone to use security: endpoints with SecurityMode None are still allowed and still found in the field.

When a client opens a secure channel, client and server exchange application instance certificates and nonces. Both sides then derive symmetric keys for signing and encrypting messages. This is where quantum exposure sits. NIST IR 8547 lists RSA, (EC) Diffie-Hellman, ECDSA and EdDSA as quantum-vulnerable. Every OPC UA policy published today uses one or more of these for key establishment or for certificate signatures.

The bulk encryption (AES with HMAC-SHA256 or similar) is a different case. NIST notes that symmetric algorithms such as AES and SHA are affected by Grover’s algorithm, but less dramatically. The weak link is the handshake, not the payload cipher.

CISA’s 2024 paper on post-quantum considerations for OT names certificate-based encryption in OPC UA explicitly. In the agency’s words, “implementing post-quantum cryptography for OT systems will be a significant and enduring challenge” for owners and operators of critical infrastructure.

Which OPC UA security policies use RSA or elliptic curve cryptography?

All of them. The RSA-based policies send key material encrypted under the peer’s RSA public key. The ECC-based policies use ephemeral elliptic curve Diffie-Hellman with ECDSA or EdDSA signatures.

The move from RSA to ECC policies is a real improvement on classical hardware. ECC has smaller keys, faster handshakes on constrained controllers, and ephemeral key agreement that gives forward secrecy against classical attackers. It does not change the quantum picture: Shor’s algorithm breaks elliptic curve discrete logarithms just as it breaks RSA factoring.

How does a harvest now, decrypt later attack affect OPC UA process data?

An adversary who records OPC UA handshakes and sessions today could later recover the session keys from the handshake and decrypt the entire session. For process data that stays sensitive for years, the exposure therefore starts now, not on the day a quantum computer arrives.

Why the handshake is the weak point

With the RSA policies, the nonces that feed key derivation are encrypted under the peer’s RSA public key during OpenSecureChannel. Anyone who can later factor that key recovers the nonces and can derive every symmetric key for the channel. With the ECC policies, the ephemeral public keys travel in the handshake, and a quantum computer could compute the shared secret from them. Either way, a complete recording of handshake plus traffic is all an adversary needs to keep.

Authentication is a different case. Forging an RSA or ECDSA signature needs a quantum computer at the moment of the attack, so it is not retroactive. It does become a live risk once such machines exist, because certificate-based trust in OPC UA would then no longer hold.

Which OPC UA data has a long shelf life

Not all process data is equally sensitive over time. A practical way to triage:

The OPC UA traffic most likely to be captured is the traffic that leaves the plant: links between sites over the public internet, connections to cloud analytics and historians, and remote engineering sessions. Inside a segmented cell network, an adversary would first need a foothold to record anything at all.

Is the OPC Foundation planning post-quantum OPC UA security policies?

The OPC Foundation maintains the specification and adds new SecurityPolicies through its normal standards process, as it did with the ECC policies. In the sources reviewed for this article, we could not confirm a published post-quantum SecurityPolicy in IEC 62541. Asset owners should therefore plan for a multi-year gap.

A native post-quantum OPC UA policy will most likely combine an ML-KEM key establishment step, based on NIST FIPS 203, with post-quantum or hybrid signatures for application authentication. The building blocks now exist:

• FIPS 203 (ML-KEM) was published on 13 August 2024 and specifies three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024 (NIST, 2024-08-13). NIST states that “ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.”
• A second KEM: NIST announced on 11 March 2025 that it selected HQC, a code-based KEM, for standardisation to complement ML-KEM (NIST, 2025-03-11).

The harder part for OPC UA is everything around the algorithm: larger certificates and handshake messages, the GDS certificate management infrastructure, conformance testing, and then firmware for an installed base of controllers and gateways that are often expected to run for 15 years or more. That is the gap CISA warns about.

The regulatory clock from NIST IR 8547

NIST IR 8547 sets out the expected end of life for the algorithms OPC UA relies on today:

• Deprecated after 2030, disallowed after 2035: quantum-vulnerable public-key algorithms at 112-bit security strength (NIST IR 8547 initial public draft, 2024-11-12).
• Earlier plan replaced: NIST’s SP 800-57 guidance had projected disallowing 112-bit public-key schemes on 1 January 2031. IR 8547 replaces that plan with a timeline driven by the quantum migration (NIST IR 8547 initial public draft, 2024-11-12).

IR 8547 also states that hybrid approaches, which combine a classical and a post-quantum algorithm, may be used in the initial transition. For OT networks, where the endpoints cannot be upgraded quickly, that hybrid principle can be applied at the network layer first.

Should OPC UA traffic from the edge to the cloud go through a quantum-safe tunnel?

For OPC UA sessions that cross networks you do not control, especially edge-to-cloud and site-to-site links, a quantum-safe tunnel with hybrid key agreement is a sensible interim control. It protects the transport layer now, while OPC UA’s own security keeps handling application authentication.

Layering, not replacement

A tunnel and OPC UA security do different jobs. A tunnel protects the path between two gateways against recording and tampering. OPC UA’s own security authenticates specific applications and users and signs messages end to end, including on the local network segments the tunnel never sees. Keep endpoints on Sign or SignAndEncrypt, keep certificate trust lists maintained, and disable SecurityMode None where products allow it. The tunnel is an extra outer layer: if one of the two layers fails, the other still protects the data.

What to look for in an OT-ready quantum-safe tunnel

• Hybrid key agreement: a classical exchange plus ML-KEM combined into one session key, so the tunnel is at least as strong as today’s classical protection even if one component is later weakened.
• Network-layer operation: encrypting at Layer 3 means OPC UA binary over TCP, OPC UA PubSub and any other protocols on the same path are covered without touching PLCs, HMIs or OPC UA servers.
• Fail-closed behaviour: no silent fallback to unencrypted traffic after a line failure. OT links often run unattended, so automatic recovery matters.
• Crypto agility: the ability to swap the post-quantum algorithm, for example if NIST guidance changes or HQC becomes preferred for diversity.
• Fit with existing firewalls: deployment in front of or behind the OT firewall, depending on whether that firewall must keep inspecting OPC UA traffic on the path.

Quantum Network’s QPN is one example of this approach. It is a gateway, in hardware or software, placed at each end of a connection. Its key agreement combines a classical part with ML-KEM (FIPS 203), and both handshakes renew every two minutes. Payloads are encrypted with ChaCha20-Poly1305. For edge to cloud, a virtual Quantum Gateway runs in the organisation’s own data centre or cloud on a supported Linux platform. Remote users connect through a software client for current Windows and macOS. As QPN’s own documentation makes clear, a gateway like this protects data in transit only: it does not protect the devices behind it and does not replace a central firewall.

How should OT teams sequence OPC UA post-quantum migration?

Start with an inventory and the exposed paths, then harden native OPC UA security, then add quantum-safe transport where data leaves the site. Native post-quantum policies come last, as they become available.

1. Inventory endpoints and policies. For every OPC UA server, record its Security Modes, Security Policies, certificate key types and expiry dates. Flag Basic128Rsa15, Basic256 and any endpoint offering None.
2. Map where OPC UA crosses trust boundaries. Edge gateways to cloud, site-to-site historian replication, vendor remote access and aggregation servers in a DMZ are the paths most worth protecting first.
3. Classify data by shelf life. Use the table above. Recipes, batch records and asset maps justify early action. Short-lived telemetry can wait.
4. Harden classical OPC UA now. Move to Basic256Sha256, Aes256_Sha256_RsaPss or an ECC policy, rotate application certificates, and remove anonymous and plaintext-password user tokens.
5. Add hybrid post-quantum transport on exposed paths. This covers harvest now, decrypt later without waiting for every controller to get new firmware.
6. Write post-quantum requirements into procurement. Ask OPC UA vendors how they will support future post-quantum SecurityPolicies, how large certificates affect their devices, and whether their firmware can be updated in the field.

CISA’s Post-Quantum Cryptography Initiative works with Sector Risk Management Agencies to help critical infrastructure owners plan their migration. That guidance is a useful reference for structuring the inventory and prioritisation steps above.