Post-Quantum Cryptography for OT and IIoT: CNSA 2.0 and NIST IR 8547 Deadlines

A PLC that ships in 2026 will still be running a production line in 2041, and possibly 2046. The public-key cryptography baked into its bootloader, its TLS stack and its device certificate was chosen for an internet that assumed RSA and elliptic curves last forever. Nobody has built a quantum computer that breaks either today, and this article does not claim otherwise. But the published migration deadlines now land inside the service life of hardware being commissioned this year.

Post-quantum cryptography OT planning is therefore not a data-centre problem that eventually trickles down. It is a design-freeze problem: what you fuse into silicon and sign into firmware now cannot be swapped later without a truck roll. This guide walks through what the NIST standards and the NSA’s CNSA 2.0 schedule imply for constrained industrial devices, with measured Cortex-M costs, a signing-versus-key-exchange triage, and a migration pattern built around crypto agility.

What this covers: the standards and dates as of September 2026, the two distinct quantum risks in OT, measured ML-KEM and ML-DSA costs on microcontrollers, protocol-by-protocol impact (TLS, DTLS, MQTT, OPC UA), firmware signing and secure boot, PKI and HSM changes, regulatory overlap (IEC 62443, EU CRA), failure modes, and a practical checklist.

Context and Background

Public-key cryptography in industrial systems does three jobs. It authenticates devices and servers (certificates), it establishes session keys (Diffie-Hellman variants), and it proves that firmware is authentic (signatures). Shor’s algorithm, run on a sufficiently large fault-tolerant quantum computer, would break the RSA, finite-field Diffie-Hellman and elliptic-curve schemes that do all three. Symmetric primitives such as AES-256 and SHA-2/SHA-3 are affected far less, and NIST’s transition draft says they need no replacement for quantum reasons.

The state of the machines matters for framing. Research from Google published in 2025 estimated that a 2048-bit RSA integer could be factored with fewer than a million noisy qubits in under a week, down from an earlier estimate of about 20 million (Gidney, arXiv:2505.15917). That is a resource estimate for a machine that does not exist yet. For a sober take on viral claims, see our fact-check of the “quantum broke RSA-2048” headlines, and for the elliptic-curve side, the quantum threat to elliptic curve cryptography.

NIST published the first three post-quantum standards on 13 August 2024: FIPS 203 (ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, a stateless hash-based signature derived from SPHINCS+). A fourth, FIPS 206 (FN-DSA, from Falcon), is still described by NIST as in development as of its August 2026 status page. HQC was selected in March 2025 as a backup key-encapsulation algorithm, also without a final standard yet.

The generic enterprise view of this migration, including inventory and crypto-agility governance, is covered in our post-quantum cryptography migration and crypto-agility guide. This article takes the narrower, harder OT slice: devices with kilobytes of RAM, decade-plus lifespans, offline update paths and safety obligations.

Two things make OT different. First, lifetime: an office laptop is replaced in four years; a drive controller or protection relay may not be. Second, mutability: many field devices cannot receive a new bootloader at all, because the first-stage boot code lives in mask ROM or one-time-programmable memory. The public keys and algorithms that ROM trusts are fixed on the day the chip is manufactured.

The dates that matter

NIST’s draft IR 8547, “Transition to Post-Quantum Cryptography Standards” (initial public draft, 12 November 2024, comments closed 10 January 2025), proposes that quantum-vulnerable public-key algorithms at 112-bit classical security (for example RSA-2048 and 224-bit ECC) be deprecated after 2030 and disallowed after 2035. Algorithms at 128 bits or higher would be disallowed after 2035. As of NIST’s project pages in September 2026 the document still carries draft status, so treat the dates as NIST’s stated intent rather than final policy.

The NSA’s CNSA 2.0 advisory is stricter and earlier for national security systems (NSS). It names ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, and LMS or XMSS (single-tree, per NIST SP 800-208) for firmware and software signing, together with AES-256 and SHA-384/512. Its category timeline, as reflected in the NSA’s published guidance and FAQ, reads as follows.

Category	Support and prefer	Exclusive use
Software and firmware signing	2025	2030
Web browsers, servers, cloud services	2025	2033
Traditional networking (VPN, routers)	2026	2030
Operating systems	2027	2033
Niche equipment	2030	2033
Custom applications and legacy equipment	update or replace	2033

A cross-cutting milestone matters for suppliers: from 1 January 2027, new NSS acquisitions are expected to be CNSA 2.0 compliant. If you sell industrial gear into defence, energy or critical-infrastructure programs that follow NSS rules, that date is a procurement gate, not a suggestion. Everyone else can treat CNSA 2.0 as a well-specified, early benchmark.

One clarification on scope: CNSA 2.0 legally binds national security systems, and NIST IR 8547 targets US federal use. Commercial OT is bound by neither directly. The reason both still matter is that customers, insurers, and regulators such as the EU use them as reference points, and because silicon vendors are building to them.

Post-Quantum Cryptography OT: Two Quantum Risks, Two Different Clocks

Post-quantum cryptography for OT means replacing RSA and elliptic-curve public-key operations in industrial devices with NIST-standardised ML-KEM for key exchange and ML-DSA, SLH-DSA or LMS for signatures. Firmware signing and boot roots come first because they cannot be updated after shipment; hybrid key exchange comes next to counter harvest-now-decrypt-later.

The single most useful thing an OT architect can do is stop treating “the quantum threat” as one thing. There are two, and they have different urgency, different mitigations and different constraints on constrained hardware.

Figure 1: The two quantum risks in OT map to different mechanisms. Key exchange needs action now because recorded traffic ages badly; signatures need action before devices ship because roots of trust cannot be replaced later.

Figure 1 splits the problem. The left branch is confidentiality: an adversary records encrypted traffic today and decrypts it once a quantum computer exists. The right branch is authenticity: an adversary with a quantum computer forges a signature and pushes malicious firmware or impersonates a device. The left risk is retroactive; the right risk is prospective. That asymmetry drives everything that follows.

Harvest now, decrypt later: real, but narrower in OT than in IT

Harvest-now-decrypt-later (HNDL) is the reason browsers and CDNs moved to hybrid key exchange first. For OT, its weight depends on what the traffic contains and how long the secrets stay valuable. A Modbus/TCP reading of tank level from last Tuesday has almost no value in 2035. Recipe parameters, proprietary process models, PLC logic uploads, and credentials sent over an encrypted channel are different: process know-how in a pharmaceutical or semiconductor plant can stay sensitive for a decade or more.

Two practical filters help. Ask how long the plaintext stays valuable (the confidentiality shelf life), and ask whether the traffic crosses a network segment an adversary can plausibly record, such as a WAN link, a cellular backhaul, or a cloud path. Traffic that never leaves a well-segmented zone is a lower HNDL target than a site-to-cloud MQTT stream. Where both the shelf life and the exposure are high, adopt hybrid key exchange first.

Note that HNDL only affects the key-establishment step. If the session key was derived with a quantum-safe method, recorded ciphertext protected by AES-256 stays safe. That is why the fix is targeted: replace or augment the key exchange, and leave the bulk cipher alone.

Signature forgery: no time machine, but a hard deadline

A forged signature cannot be applied retroactively; the attacker needs a working quantum computer at the moment of the attack. That sounds comfortable until you multiply by device lifetime. If a PLC’s boot ROM trusts an ECDSA P-256 root key and the device lives to 2045, then the signature scheme has to remain unforgeable for that whole period, because the device cannot be told to distrust it if the ROM never learned another algorithm.

This is why CNSA 2.0 puts firmware signing on the earliest track: support and prefer PQ signatures from 2025, exclusive use by 2030. Code-signing is a place where the attacker’s payoff is enormous (arbitrary code at the lowest privilege layer), where a single break is fleet-wide, and where the verifier is often immutable. It is the highest-consequence, longest-lived signature use in OT.

The two clocks also differ in who can act. Key exchange can be upgraded in software on any device whose TLS library can be updated. Signature verification anchored in ROM cannot. So the honest priority order for a device being designed now is: first, the boot-time signature verification path; second, the update-time algorithm-agility path; third, session key exchange.

What the Deadlines Mean for a 15 to 20 Year Device

Deadlines only become concrete when you lay them against a device timeline. Figure 2 does that.

Figure 2: A device shipped in 2026 with a 15 to 20 year life is in service until roughly 2041 to 2046, past both the CNSA 2.0 exclusive-use dates and NIST’s proposed 2035 disallowance.

Take a concrete example. A programmable controller enters production in 2026, is sold for seven years, and each unit is then supported for 15 years. The last units shipped in 2033 remain in the field until 2048. Under NIST’s draft, ECDSA and ECDH stop being permitted for federal use after 2035. Under CNSA 2.0, firmware signing must be exclusively quantum-resistant by 2030. Every unit built after about 2026 to 2027 therefore needs either a PQ-capable root of trust at manufacture or a proven path to add one in the field.

The arithmetic, which is illustrative, is Mosca-style. If the data or device must stay secure for X years, and migration will take Y years, and a cryptographically relevant quantum computer arrives in Z years, you are exposed when X plus Y exceeds Z. For a controller with X equal to 20 and a fleet migration Y of 5 to 8 years (typical for plants with change windows every 12 to 24 months), the sum is 25 to 28 years. Nobody can bound Z with confidence, which is exactly why the deadline authorities choose dates well before any credible arrival.

What “support and prefer” actually asks of an OEM

CNSA 2.0’s “support and prefer” phase for firmware signing does not mean your product must drop ECDSA in 2025. It means the verifier should be able to accept a CNSA 2.0 signature and the signer should prefer it where the counterparty supports it. The 2030 date is when classical signatures are no longer acceptable for NSS firmware.

The practical read for an OEM is a two-stage plan. Stage one, for products now in design: add a PQ-capable verification path (LMS or ML-DSA) in the first-stage boot code or in the secure element, even if production images are still dual-signed. Stage two, for products in the field: make sure the second-stage bootloader is updatable and can be taught new algorithms.

NIST IR 8547 versus CNSA 2.0: two different pressures

The two documents are easy to blur. IR 8547 is a deprecation and disallowance schedule for algorithms, with a horizon of 2030 to 2035 and draft status. CNSA 2.0 is an algorithm selection and adoption schedule for NSS, with category deadlines running from 2025 to 2033. IR 8547 is a “stop using” document; CNSA 2.0 is a “start using, and use exclusively by” document.

For OT suppliers the combination means you need both: a target algorithm list that lines up with CNSA 2.0 (ML-KEM-1024, ML-DSA-87, LMS/XMSS) if defence or critical-infrastructure customers are in play, and a retirement plan for classical algorithms that lines up with IR 8547. Commercial-only suppliers can often use the smaller parameter sets (ML-KEM-768, ML-DSA-65, or ML-DSA-44 where category 2 suffices) and still be inside NIST guidance, but that choice should be explicit rather than accidental.

Hybrid deserves a note. CNSA 2.0 does not require a hybrid of classical and PQ algorithms. NIST’s draft calls hybrid a hedge against implementation or cryptanalytic flaws and expects it to be a temporary measure. European agencies such as Germany’s BSI and France’s ANSSI have advocated hybrids more strongly. If you ship to both markets you may need to support both a PQ-only and a hybrid profile, which is a strong argument for a configurable cipher-suite policy rather than a hard-coded choice.

The EU angle

The EU’s coordinated PQC implementation roadmap, published on 23 June 2025 by Member States with the Commission, sets milestones by the end of 2026, 2030 and 2035. The pattern is: begin planning and inventory, migrate high-risk use cases by 2030, and complete as much as feasible by 2035. That mirrors the US timing closely enough that a single engineering programme can serve both.

The Standards Toolkit, Sized for a Microcontroller

Before deciding what fits, you need real sizes. Post-quantum objects are larger than their classical counterparts, and the difference shows up first in flash, RAM and packet size.

ML-KEM (FIPS 203) sizes and cost

ML-KEM comes in three parameter sets. The public (encapsulation) key is 800, 1,184 or 1,568 bytes for ML-KEM-512, -768 and -1024, and the ciphertext is 768, 1,088 or 1,568 bytes. Compare that with an X25519 share of 32 bytes. In TLS 1.3, the hybrid X25519MLKEM768 client key share is 1,216 bytes (1,184 for ML-KEM plus 32 for X25519) and the server share is 1,120 bytes, according to the IETF specification published as RFC 10024 in August 2026.

On the compute side, the community pqm4 project benchmarks post-quantum implementations on a Cortex-M4. For ML-KEM-768, the speed-optimised implementation measures roughly 642,000 cycles for key generation, 659,000 for encapsulation and 708,000 for decapsulation. A stack-optimised variant needs only about 2.8 KB of stack for each operation, at almost the same speed, with a code size around 13 KB. At a 100 MHz core clock those cycle counts translate to roughly 6 to 7 ms per operation. Those numbers are for a tuned M4 assembly implementation; a portable C build costs more (about 1.0 to 1.4 million cycles and 10 to 14 KB of stack in the same benchmark set).

An independent 2026 study on a much weaker Cortex-M0+ (RP2040 at 133 MHz, no hardware 64-bit multiply) measured ML-KEM-768 at about 16 ms key generation, 19 ms encapsulation and 22 ms decapsulation, and ML-KEM-1024 at 25, 28 and 32 ms (Cortex-M0+ benchmark, arXiv:2603.19340). Its conclusion that ML-KEM is practical on Class-1 IoT devices matches the M4 data. In that paper’s energy figures, an ML-KEM-512 handshake used far less energy than an ECDH P-256 baseline on the same core, which reflects how slow generic P-256 code is on cores without fast big-number multiplication rather than any magic in lattices.

The takeaway is that key exchange is not the blocker. Tens of milliseconds and a few kilobytes of stack are affordable on nearly any device that already runs TLS. The cost is in bytes on the wire, which we return to under DTLS and MQTT.

ML-DSA (FIPS 204) sizes and cost

ML-DSA is the general-purpose signature scheme, and it is heavier. The NIST parameter sets have public keys of 1,312, 1,952 and 2,592 bytes and signatures of 2,420, 3,309 and 4,627 bytes for ML-DSA-44, -65 and -87. An ECDSA P-256 signature is 64 bytes and its public key is 64 bytes, so you are looking at a 40 to 70 times growth in signature size.

The pqm4 numbers for ML-DSA-65 on a Cortex-M4 show the speed-optimised build at about 2.5 million cycles for key generation, 6.2 million for signing and 2.4 million for verification. The stack-optimised build drops memory to roughly 4.4 KB but signing rises to about 24 million cycles and verification to 5.7 million. On the RP2040 study, ML-DSA-65 verification took about 72 ms and signing averaged 277 ms with a 99th-percentile of nearly 866 ms.

That variance is a design constraint. ML-DSA signing uses rejection sampling, so its run time is not constant; the study reports coefficients of variation of 61 to 71 percent for signing. Verification is the deterministic, cheap side. For firmware signing, which is verify-heavy on the device and sign-heavy only on a build server or HSM, that asymmetry is favourable. For devices that must sign frequently in the field, such as a meter signing readings, it is not.

SLH-DSA (FIPS 205) and the stateful hash-based option

SLH-DSA is conservative: its security rests only on hash functions. The price is size and speed. The “small” parameter sets produce signatures of roughly 8 KB at 128-bit security (7,856 bytes for SLH-DSA-128s) and the “fast” sets roughly 17 KB, with tiny 32-byte public keys. Signing is slow, verification is comparatively fast. It suits a long-lived root or a rarely-signed artifact, and NIST’s April 2026 draft SP 800-230 proposes additional SLH-DSA parameter sets for limited-signature use cases, which is relevant when a key signs only a few thousand messages in its life.

LMS and XMSS (NIST SP 800-208, LMS specified in RFC 8554) are stateful hash-based signatures. They are compact and cheap to verify, which is why CNSA 2.0 names them for firmware signing. A typical LMS signature is on the order of 1.5 KB with a public key of tens of bytes (parameter dependent; check the RFC for exact figures). The catch is state: each one-time key must be used once. Reusing it breaks security, so signing must happen in an HSM with hardened state management, and NIST states that these schemes are not intended for general use.

That constraint makes stateful signatures a good fit for a single, well-controlled code-signing ceremony and a poor fit for anything distributed. It also means backup-and-restore of the signing HSM becomes a security-critical procedure, not an ops afterthought.

Protocol by Protocol: TLS, DTLS, MQTT and OPC UA

Most OT communication security terminates in one of four places: TLS 1.3, DTLS, MQTT over TLS, or the OPC UA secure channel. Figure 3 shows the hybrid handshake shape most of them will converge on.

Figure 3: A hybrid TLS 1.3 handshake in an IIoT path. The key exchange is upgraded first; the certificate chain can stay classical during transition while a PQ chain is prepared.

TLS 1.3 and hybrid key exchange

The IETF has finished the main piece. RFC 10024, published on 10 August 2026, defines three hybrid groups for TLS 1.3: X25519MLKEM768 (code point 0x11EC), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED). The shared secrets from the classical and ML-KEM components are concatenated, so the session stays secure if either component holds. The RFC notes FIPS implications: for the NIST-curve variants the ECDHE part must come from a validated module, while for X25519MLKEM768 the ML-KEM part must.

For OT, the payoff is that a gateway-to-cloud or site-to-site TLS link can be made HNDL-resistant by a library update, with no change to certificates. The costs are the larger ClientHello (about 1.2 KB more than a plain X25519 share) and a few tens of milliseconds of extra compute on a small MCU. On a fibre link both are invisible. On a 250 kbit/s narrow-band cellular link, an additional 2.3 KB across both directions is roughly 75 ms of airtime at the raw bit rate, before retransmissions, which is noticeable but tolerable for a session that then lasts hours.

Two operational traps recur. Middleboxes and older TLS stacks sometimes mishandle a ClientHello that spans more than one TCP segment or contains a large key share, causing handshake failures or retries. And a server that does not recognise the hybrid group will simply fall back to classical, which silently defeats the goal. Test with a client that offers only hybrid groups in a lab, and log the negotiated group in production.

DTLS and constrained transports

DTLS runs over UDP, where fragmentation is the hazard. A typical path MTU of 1,280 to 1,500 bytes cannot carry a 1,216-byte key share plus the rest of a ClientHello in one datagram, so handshake messages must be fragmented and reassembled, and a lost fragment forces retransmission of the flight. On lossy industrial wireless links such as Wi-Fi in a metal-heavy plant or sub-GHz radio, handshake failure rates rise with the number of datagrams.

The mitigation is architectural rather than clever: keep sessions long (DTLS 1.3 connection IDs and session resumption), resume with pre-shared or previously derived keys instead of repeating full handshakes, and handle the hybrid exchange at an edge gateway rather than at every leaf sensor. Networks like LoRaWAN, Zigbee and IO-Link have frame limits of tens to a couple of hundred bytes and cannot carry these handshakes at all. In those systems, the realistic pattern is symmetric keys provisioned or rotated through a gateway that does the heavy public-key work, with PQ protection applied on the backhaul.

MQTT over TLS

MQTT itself has no cryptography; it depends on TLS underneath. That is helpful, because upgrading the TLS layer upgrades every publisher and subscriber without any change to topics or payloads. The exposure is at brokers, bridges and client libraries: each must support the hybrid group and each broker connection reuses sessions heavily, which amortises cost. Our guide to MQTT 5 features and the Sparkplug B reference architecture cover the structure this sits under.

The point that is easy to miss in MQTT is payload-level signing. Where message authenticity is asserted with per-message signatures (for example signed telemetry for audit or custody), those signatures use the same public-key algorithms and inherit the same size growth. A 3.3 KB ML-DSA-65 signature attached to a 40-byte sensor reading turns a 40-byte message into a 3.3 KB one, an 80-fold expansion. Prefer authenticating the session (TLS) and, if payload authenticity is required, sign batches or use MACs under a session key rather than signing every reading.

OPC UA

OPC UA’s security policies (for example Basic256Sha256 and the newer ECC-based policies) authenticate applications with X.509 certificates and derive channel keys with RSA or elliptic-curve operations. To my knowledge, no published OPC Foundation security policy standardises ML-KEM or ML-DSA as of September 2026; I could not find a released specification. What does exist is research and consortium activity: the PQCUA initiative, announced in November 2025 under Horizon Europe by Systerel, Fraunhofer IOSB, Thales, achelos and others, with the OPC Foundation, BSI, NXP and STMicroelectronics listed as supporters, aims to bring post-quantum cryptography into OPC UA. It was a proposal at announcement, so treat its outputs as forthcoming.

The practical implication: for OPC UA today, protect the transport with what you can control. Run the OPC UA server behind a TLS or IPsec/WireGuard-style tunnel that supports hybrid key exchange, or put a PQ-capable gateway at the zone boundary, until native policies exist. For PubSub over MQTT the TLS path applies directly. The protocol families involved are compared in our OPC UA vs MQTT Sparkplug B analysis and in the OPC UA protocol guide. Compact certificate handling matters too: an OPC UA application-instance certificate chain of two ML-DSA-65 certificates carries roughly 2 x (1,952 + 3,309) bytes, or about 10.5 KB, of key and signature data alone, so certificate stores and secure-channel message sizes need review.

Firmware Signing and Secure Boot: Where the Deadline Bites Hardest

If you do one thing, do this. Firmware signing is the earliest CNSA 2.0 category, the most consequential, and the one hardest to fix after shipment.

Figure 4: A PQ-ready firmware pipeline. The build server calls an HSM to sign, the device verifies against a key anchored in OTP fuses or a secure element, and failure rolls back to the last good image.

The chain of trust and where it is mutable

A typical secure boot has three layers. ROM code (immutable) verifies the first-stage bootloader with a key or key hash burned into fuses. The first stage verifies the second stage or application image. The application image may in turn verify OTA updates and configuration. Each verification uses a signature algorithm, and the only layer that cannot change its mind is the ROM.

The design questions are therefore concrete. Does the ROM (or secure element) already support LMS, XMSS or ML-DSA verification? If not, is the first-stage bootloader updatable in a way that is itself protected by the ROM-verified classical key? If the answer to both is no, the product’s boot chain is locked to classical signatures for life, and the only remediation is hardware replacement.

Silicon vendors are responding. NXP has said it will integrate PQC into nearly all new product releases, naming ML-DSA (FIPS 204) and LMS (SP 800-208) with hardware SHA-3 acceleration, i.MX 94 and 95 industrial processors, higher-end MCX microcontrollers, and next-generation industrial secure elements, and it aligns them with CNSA 2.0 and the EU roadmap (NXP PQC strategy). Microchip announced post-quantum-ready root-of-trust controllers in April 2026. Availability and certification status vary by part, so check the exact datasheet for which algorithms the immutable boot ROM verifies, not only what a later software library can do.

LMS versus ML-DSA for firmware

LMS (with HSS for multiple levels) and ML-DSA are both named by CNSA 2.0 for firmware signing, and they trade differently.

LMS has small signatures, tiny public keys and very small verifier code, since it needs only a hash function. It is a natural fit for ROM verification, because the code is small and simple to audit. Its cost is state management at signing time: a lost or duplicated state counter compromises the key. For a single vendor signing releases from an HSM in a controlled facility, that is manageable. It is a bad match for signing across many build agents.

ML-DSA is stateless, so it is operationally easier, and it fits general PKI tooling (RFC 9881 defines its X.509 encoding). It costs a larger signature and a larger verifier: the M4 numbers above put ML-DSA-65 verification at roughly 2.4 million cycles, or about 24 ms at 100 MHz, negligible next to the time to read and hash a multi-megabyte image. The bigger implication is flash: an app image that carries a 3.3 KB signature and a 2 KB public key is trivial, but a boot manifest for a 32 KB bootloader region may not have room.

A practical pattern is to use LMS for the long-lived root and immutable stage, and ML-DSA (or a hybrid) for higher layers where flexibility matters. Whichever you choose, dual-sign during transition so that devices with only classical verification still accept updates, and devices with PQ verification can require the PQ signature.

Update-time crypto agility

A verifier that can only check one algorithm is not agile. The minimum viable agility for OT firmware is an algorithm identifier in the manifest, a bootloader that can accept more than one signature scheme and ignore unknown ones safely, and a signed procedure to add a new trust anchor. Our IoT OTA firmware update architecture guide covers manifests, rollback protection and staged rollouts, all of which assume the signature layer beneath them holds.

Agility is not free. Each additional accepted algorithm is more code in the trusted path and a downgrade opportunity. The safe design pins a minimum acceptable algorithm level in a monotonic counter or fuse, so once a device has accepted a PQ signature it will never fall back to a classical-only image.

PKI, CAs and HSMs in an Industrial Estate

Device identity in OT usually means an X.509 certificate issued by a private CA at manufacture or commissioning, IEEE 802.1AR IDevID and LDevID style. Post-quantum changes three things about that estate: the certificates, the CA, and the HSMs.

Certificates and chain size

The IETF LAMPS working group has published the X.509 encodings: RFC 9881 (October 2025) for ML-DSA and RFC 9935 (March 2026) for ML-KEM. An ML-DSA-65 end-entity certificate is about 5.3 KB or more versus roughly 0.5 to 0.8 KB for an ECDSA one, and a three-level chain can approach 15 KB. That is fine over Ethernet and painful over constrained links or in devices with small certificate stores and 4 KB TLS record buffers.

Options to contain this include shorter chains (a single-tier private CA for a plant), certificate compression, caching intermediate CAs on the device, and raw public keys where the deployment allows them. Use ML-KEM certificates only where the protocol needs a static KEM key, as in some authentication modes; in TLS 1.3 ephemeral key exchange, the KEM key is not in the certificate.

CA hierarchy and the root problem

A CA root has the longest lifetime in the system, often 20 years or more, which puts it in the same category as boot ROM keys. If your OT root CA is RSA-4096 or P-384 with a 25-year validity, it will outlive NIST’s proposed disallowance date. The remedy is not to reissue everything today but to plan cross-signing: stand up a PQ or hybrid root, cross-certify, and give each device a way to receive the new trust anchor through an authenticated update. Devices that cannot receive trust-store updates need to be identified now.

HSMs and secure elements

HSMs are the choke point for signing. Check which of your HSMs support FIPS 203, 204 and 205 and LMS/XMSS, whether that is in the certified module boundary or only in a software update, and what their throughput is. Stateful schemes need HSMs that manage state internally and support secure backup. For field devices, secure elements with hardware acceleration for lattice arithmetic and SHA-3 are arriving, but many current parts only accelerate RSA and ECC and would fall back to software for PQC, at the speeds measured above.

A useful discipline is a cryptographic bill of materials (CBOM) per product: which algorithm each certificate, key and signature uses, where the verifier lives (ROM, secure element, bootloader, application) and whether that layer is updatable. The NIST NCCoE migration project publishes practical guidance on discovery and inventory (NIST NCCoE Migration to Post-Quantum Cryptography).

Regulation and Standards: IEC 62443 and the EU Cyber Resilience Act

Neither IEC 62443 nor the EU Cyber Resilience Act mandates specific post-quantum algorithms as of this writing. Both create obligations that post-quantum readiness helps satisfy, which is the useful framing.

IEC 62443 covers security for industrial automation and control systems. Its component requirements (62443-4-2) and system requirements (62443-3-3) call for strong, standards-based cryptography and secure update mechanisms, and its zone-and-conduit model determines which links need protection. Applying PQ key exchange at conduits that cross zone boundaries is a natural extension; see our IEC 62443 zones and conduits guide. I did not find published normative text in IEC 62443 that names ML-KEM or ML-DSA; the standard’s cryptographic language is technology-neutral, so “state of the art” is interpreted against current guidance such as NIST and ENISA.

The EU Cyber Resilience Act (Regulation 2024/2847) entered into force on 10 December 2024. Its vulnerability and incident reporting obligations, including a 24-hour early warning for actively exploited vulnerabilities, applied from 11 September 2026, and the main product obligations apply from 11 December 2027 (European Commission CRA summary). Annex I requires products to be secure by design, to receive security updates, and to protect data with state-of-the-art measures, over a declared support period. A product with a multi-year support period and a signing scheme that regulators expect to be disallowed in the period is the kind of tension a conformity assessor may ask about. Our CRA 24-hour reporting guide for IIoT covers the reporting mechanics.

Trade-offs, Gotchas, and What Goes Wrong

Larger everything. Signatures grow 40 to 70 times, key shares 30 to 40 times, and certificate chains by an order of magnitude. Devices with fixed-size buffers, small MTUs, or protocol frame limits fail in ways that only appear in the field, and often only under packet loss.

Signing variance. ML-DSA signing time is variable because of rejection sampling. If a device must sign inside a hard real-time deadline, use pre-computation, run signing in a non-critical task, or move signing to a gateway. Verification is stable.

Side channels. Implementations on small MCUs face timing and power side-channel attacks. Masked ML-KEM and ML-DSA implementations exist in research, at a considerable performance and code-size cost. If a device is physically accessible and holds a long-term private key, use a secure element rather than software crypto.

State mismanagement. LMS and XMSS fail catastrophically if a one-time key is reused, for instance after restoring an HSM from an old backup. Treat state counters as safety-critical data.

Hybrid complexity. Hybrids double the failure surface. A bug in either component or the combiner can compromise interoperability or security, and NIST’s draft expects them to be temporary. Do not bake a hybrid combiner into ROM; keep it in updatable software.

Downgrade and fallback. A TLS peer that silently falls back to classical negotiation defeats the exercise. Log negotiated groups, alert on classical-only sessions on links classified as HNDL-sensitive, and pin minimum levels where the fleet allows.

Standards still moving. FIPS 206 (FN-DSA) and the HQC standard are unfinished, NIST IR 8547 is still a draft, and new SLH-DSA parameter sets are in draft (SP 800-230). Committing to Falcon-specific hardware today is a bet; ML-KEM, ML-DSA and LMS are final and safer bases.

False sense of urgency, and its opposite. Over-rotating leads to expensive, half-tested code in safety-critical paths. Under-rotating leads to devices whose boot ROM cannot ever verify a PQ signature. The remedy for both is the triage in the next section.

Decision Matrix: What to Do First, by Device Class

Device class	Key exchange	Signature and boot	Main constraint	First action
Edge gateway or industrial PC (Linux, MB of RAM)	Hybrid X25519MLKEM768 via updated TLS library	ML-DSA-65 or hybrid for OTA; dual-sign	Library and CA support	Enable hybrid groups, log negotiated group
PLC or RTU (Cortex-M4/M7, 256 KB to 2 MB RAM)	Hybrid at gateway or on-device ML-KEM-768	LMS or ML-DSA verifier in bootloader, algorithm ID in manifest	Flash for bootloader, stack for ML-DSA	Confirm ROM and bootloader updatability
Leaf sensor (Cortex-M0+, tens of KB RAM)	Symmetric keys via gateway; no direct handshake	LMS verify in ROM if silicon allows	Frame size, RAM, battery	Provision symmetric keys and plan ROM choice
Long-life safety device (10 to 20 years, no updates)	Terminate at a PQ-capable zone boundary	PQ verifier in immutable boot or a secure element	Immutable ROM, certification cost	Design the PQ verifier into the next silicon spin
Enterprise and cloud edge (broker, CA, HSM)	Hybrid TLS everywhere	HSM with FIPS 203/204/205 and LMS support	HSM roadmap, PKI tooling	Inventory algorithms, plan PQ or hybrid root and cross-signing

Sizes and timings referenced above come from the cited benchmarks; the device classes and actions are this author’s analysis, not a standard.

Practical Recommendations

Start with inventory, not algorithms. A CBOM that lists every key, certificate, signature verifier and TLS endpoint, with the layer that owns it and whether it can be updated, is the artefact that turns this from a slogan into a plan. Most plants discover that a small number of immutable verifiers and long-lived roots account for nearly all of the irreversible risk.

Then sequence by irreversibility. Anything in ROM or fuses gets first attention, followed by roots and long-lived CAs, then bootloaders and update paths, then session key exchange, then payload-level signatures. Purchase specifications should ask suppliers which algorithms their boot ROM verifies, whether the second-stage bootloader is updatable, and what the roadmap is for FIPS 203 and 204 support, with CNSA 2.0 alignment if relevant.

Finally, build agility as a tested capability. Rehearse a trust-anchor rotation and a signature-algorithm switch on a test fleet before you need one. Agility that has never been exercised is a hypothesis.

A short checklist:

Build a cryptographic bill of materials per product line and per plant.
Classify data by confidentiality shelf life and traffic by exposure; enable hybrid key exchange first where both are high.
Ask every silicon and module vendor which signature algorithms the immutable boot code verifies.
Add an algorithm identifier and a minimum-level counter to firmware manifests.
Dual-sign firmware during transition; never let a device fall back to classical-only once it has seen a PQ signature.
Verify HSM support for FIPS 203, 204, 205 and LMS/XMSS, including state backup for stateful schemes.
Shorten certificate chains and test handshakes under packet loss and small MTUs.
Track NIST IR 8547 finalisation and FIPS 206 rather than designing hardware around drafts.
Do not claim quantum machines break RSA or ECC today; present the risk as deadline-driven planning.

This article is technical analysis, not legal or compliance advice; confirm obligations with your assessor.

Frequently Asked Questions

Can quantum computers break RSA or ECC today?

No. No quantum computer today can break RSA-2048 or elliptic-curve cryptography. Published estimates, such as a 2025 Google result of under a million noisy qubits for RSA-2048, describe machines that do not yet exist. The reason to migrate now is timing: standards deadlines, long device lifetimes and harvest-now-decrypt-later collection mean the work takes years, and hardware roots of trust cannot be changed after shipment.

What are the CNSA 2.0 deadlines for industrial firmware?

For national security systems, CNSA 2.0 sets software and firmware signing to “support and prefer” quantum-resistant algorithms from 2025 and use them exclusively by 2030. Networking equipment follows the same 2030 end date, while operating systems, browsers and legacy equipment run to 2033. New NSS acquisitions are expected to be compliant from 1 January 2027. LMS, XMSS and ML-DSA-87 are the named signature choices for firmware.

Does NIST IR 8547 make RSA and ECC illegal in 2030?

Not as written. The draft, published in November 2024, proposes deprecating 112-bit-strength RSA and ECC after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. It targets federal use and remained a draft on NIST’s site in September 2026. Deprecated means use is discouraged and carries risk; disallowed means it is no longer approved. Commercial OT is not directly bound, but customers and auditors often use these dates as reference points.

Do ML-KEM and ML-DSA fit on a Cortex-M microcontroller?

Yes, with caveats. Benchmarks on a Cortex-M4 show ML-KEM-768 taking roughly 0.65 to 0.7 million cycles per operation and 3 to 6 KB of stack with optimised code. ML-DSA-65 verification takes about 2.4 million cycles and signing about 6 million, with variable time. Flash use is roughly 13 to 16 KB for ML-KEM. The larger issue is data size: signatures near 3.3 KB and hybrid key shares near 1.2 KB.

Should OT teams use hybrid or pure post-quantum key exchange?

For TLS links, hybrid (X25519MLKEM768 in RFC 10024) is the safe default today: it stays secure if either the classical or ML-KEM component holds, and it is broadly deployable. CNSA 2.0 does not require hybrid, and NIST expects hybrids to be temporary, so make it a policy setting. Keep combiner logic in updatable software, not immutable ROM, and prefer pure PQ only where a regulation demands it.

What is crypto-agility for an industrial device?

It is the ability to change algorithms, keys and trust anchors without replacing hardware. Practically, that means algorithm identifiers in firmware manifests, a bootloader that accepts several signature schemes, an authenticated way to update trust anchors, and a minimum-level counter that blocks downgrade. It also means testing rotations before you need them. Devices whose boot ROM verifies only one algorithm are not agile, whatever their software layers can do.