Modbus TCP security post-quantum: is TLS still safe?

Modbus TCP security post-quantum means protecting Modbus/TCP Security and CIP Security traffic against future quantum computers. Both protocols rely on TLS with classical RSA or elliptic-curve cryptography. There are two ways to do this: upgrade the TLS stack in the field devices to hybrid ML-KEM key exchange, or carry the traffic inside a quantum-safe network tunnel.

Industrial protocol security was built in the 2010s to stop plaintext Modbus and EtherNet/IP traffic from being read and altered. It did that by borrowing TLS. Because of that choice, the quantum transition of TLS now applies directly to PLCs, RTUs and engineering workstations, which sit on lifecycles of fifteen years or more.

Is Modbus/TCP Security over TLS vulnerable to quantum computers?

Yes. The parts at risk are the key exchange and the certificates, not the bulk encryption. Any Modbus/TCP Security session negotiated with classical (EC)DHE or RSA can be recorded today and decrypted once a cryptanalytically relevant quantum computer exists.

The Modbus/TCP Security Protocol Specification from the Modbus Organization wraps the unchanged Modbus application data unit in TLS. TLS 1.2 or higher is mandated, ensuring protection against eavesdropping and MITM attacks. Additionally, X.509v3 certificates enable mutual authentication between clients and servers, while role-based access control (RBAC) allows granular security configurations. Modbus TCP Security uses IANA-registered port 802 for secure communication.

The quantum exposure comes from two places. First, the handshake that sets up the session keys uses finite-field or elliptic-curve Diffie-Hellman, or RSA key transport. Second, the role information used for authorization sits inside an X.509 certificate signed with RSA or ECDSA. NIST names all of these as quantum-vulnerable. The symmetric record protection is not the issue: primitives that provide at least 128 bits of classical security are believed to meet the requirements of at least Category 1 security in the NIST post-quantum categories.

For OT, the concern is less about stolen setpoints and more about what recorded traffic reveals over time: process recipes, network topology, the role structure in client certificates, and write patterns that show how a plant is operated. A public comment submitted to NIST put it directly: long-lived SCADA/ICS devices installed today may remain operational by the time quantum computers become viable. Deploying only classical public-key cryptography (such as RSA-2048 or ECDSA-256) on these systems could allow future quantum adversaries to decrypt data and commands retroactively.

Can CIP Security for EtherNet/IP use hybrid ML-KEM key exchange?

Not in standard form yet. The hybrid ML-KEM groups are defined for TLS 1.3, so CIP Security devices will only be able to use them once ODVA profiles and vendor firmware support TLS 1.3 and DTLS 1.3 with those groups.

ODVA CIP Security provides the ability to deploy TLS- and DTLS-based secure communications to supported products. CIP Security is an enhancement to the ODVA (Open DeviceNet Vendors Association) EtherNet/IP industrial communication standard. It also allows users to leverage and manage certificates and/or pre-shared keys. The pre-shared-key option matters here. A pure PSK handshake has no public-key step for a quantum computer to break, but it brings the familiar problems of key distribution and rotation across hundreds of devices.

On the IETF side, the hybrid design combines a classical and a post-quantum share into one TLS 1.3 key share. The IETF draft for hybrid ECDHE-MLKEM is written specifically for TLSv1.3, and its groups, such as X25519MLKEM768, have no equivalent in TLS 1.2. Since the Modbus Security specification allows “TLS 1.2 or higher”, and many CIP Security implementations in the field are built around the 1.2 generation, operators should check exactly which TLS versions and groups their installed firmware supports. A data sheet that says “TLS supported” does not answer that question.

What happens to Modbus and EtherNet/IP device certificates when RSA and ECDSA are deprecated?

Under NIST IR 8547, the RSA and ECDSA certificates that carry Modbus roles and CIP identities become deprecated after 2030 and disallowed after 2035. Many devices being commissioned today will still be running at that point.

The finalized report is explicit: NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. Deprecated does not mean forbidden. It means the algorithm and key length/strength may be used, but there is some security risk. The data owner must examine this risk potential and decide whether to continue to use a deprecated algorithm or key length. Dustin Moody of NIST summarized the report’s purpose: “We lay out how certain encryption algorithms people are using today will get phased out”.

For federal systems the dates are tighter. NIST notes that OMB Memorandum M-26-15 [OMB2615] requires high value assets, high impact systems, and other systems with highly sensitive data to transition to quantum-resistant key establishment by December 31, 2030. 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.

In practice there are three consequences for OT PKI:

• Device identity certificates provisioned at the factory or during commissioning will need to be reissued with ML-DSA or hybrid signatures. That only works if the device firmware can parse and verify them.
• Modbus role extensions live inside the certificate. Any change of signature algorithm also touches the authorization model, not just encryption.
• Issuing CAs in plant PKIs often have long validity periods. A root signed with RSA today could still anchor trust after 2035 unless it is planned out.

IEC 62443-4-2 component requirements expect devices to use cryptography in line with recognized practice. As NIST’s deprecation status takes effect, asset owners should treat “supports post-quantum certificates” as a procurement requirement rather than a later firmware wish.

Do PLCs that support Modbus Security or CIP Security have enough resources for post-quantum TLS?

Some newer controllers and communication modules may have the headroom. Many installed PLCs and adapters probably do not. The bigger obstacle is usually firmware and certification cycles rather than raw CPU.

The main cost is message size. In FIPS 203 (ML-KEM), an ML-KEM-768 encapsulation key and ciphertext are 1184 and 1088 bytes. In the hybrid TLS 1.3 group, the size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519), and the size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519). A ClientHello carrying such a share no longer fits comfortably in one Ethernet frame. That is relevant for embedded TCP/IP stacks with small receive buffers, and for DTLS over UDP, which CIP Security uses for implicit I/O connections.

Key exchange is only part of the load. Moving device certificates to ML-DSA increases the size of certificate chains and signature verification work during every full handshake. A controller that holds many concurrent secure connections, or that rebuilds connections after a network disturbance, takes that cost all at once. The factors to check per device type are:

• Free RAM for the TLS stack while the control task keeps its guaranteed cycle time
• Whether the crypto library is field-updatable, or fixed in a certified firmware image
• Maximum concurrent TLS or DTLS sessions, and how long a handshake takes under load
• Vendor roadmap for TLS 1.3, hybrid groups and ML-DSA certificates

How long can OT protocol TLS sessions stay open before rekeying becomes a harvest now, decrypt later risk?

No session length is safe if the handshake was classical. Everything sent in that session can be decrypted retroactively, however short it was. What rekeying controls is how much data depends on any single key exchange, and that only helps when each rekey performs a fresh, quantum-resistant exchange.

OT connections are unusually long-lived. A SCADA master may hold a Modbus/TCP Security session to an RTU for weeks, and CIP Security connections typically stay open as long as the controller runs. If the handshake was purely classical, the whole period sits under one breakable secret.

A practical policy is therefore built from three questions. Is the key exchange hybrid? How often does a fresh full handshake happen? How long does the data stay sensitive? Telemetry that loses value within hours carries a different risk from engineering downloads or safety-system configuration. Marcos Curty, a quantum cryptography researcher, framed the goal as being sure “that messages can continue to be sent securely without someone being able to access that information, either now or in the near future”.

Should OT protocol TLS be upgraded in the device or protected with a quantum-safe tunnel instead?

For most operators the realistic answer is both, on different timelines. Device-level upgrades are the long-term goal for end-to-end authentication. Quantum-safe tunnels protect the exposed paths between sites, clouds and remote users now, without touching certified PLC firmware.

A tunnel does not replace device authentication inside the plant. It removes the wide-area segments, where interception is easiest, from the harvest now, decrypt later exposure. As one example of this approach, Quantum Network’s QPN gateway encrypts at Layer 3 between an organisation’s own locations, using a hybrid key agreement in which a classical part and ML-KEM (FIPS 203) are combined into one session key, with both handshakes renewed every two minutes. QPN protects data in transit only. It does not protect the devices behind the gateway and does not replace the central firewall, so segmentation and device hardening remain separate tasks.

How should an OT team plan the post-quantum migration for Modbus and CIP traffic?

Start from the traffic, not the algorithms. Map which protocol sessions cross untrusted networks and how long their content stays sensitive, then decide per path whether to upgrade devices or tunnel.

1. Inventory secure OT sessions: list port 802 Modbus/TCP Security and CIP Security endpoints, their TLS versions, key exchange groups and certificate algorithms.
2. Classify paths: separate intra-cell traffic from site-to-site, edge-to-cloud and remote-access links, where interception is most realistic.
3. Protect exposed paths first: put hybrid key exchange on wide-area links with frequent fresh handshakes, independent of PLC firmware.
4. Plan the PKI: map CA validity periods and device certificate lifetimes against the 2030 and 2035 milestones in NIST IR 8547.
5. Change procurement: require TLS 1.3, hybrid ML-KEM groups and a firmware path to post-quantum certificates for new controllers and adapters.

NIST’s general guidance fits OT closely: cybersecurity products, services, and protocols will need updates, and organizations must identify where vulnerable algorithms are used and plan to replace or update them. In industrial networks, that inventory includes traffic on port 802 and every EtherNet/IP connection that has been protected with TLS since CIP Security was introduced.