Post-Quantum IoT Embedded Devices in Sovereign Infrastructure

Post-quantum IoT embedded devices in sovereign infrastructure represent the intersection of two compounding risks: the long operational lifetimes of constrained hardware and the accelerating timeline by which classical asymmetric cryptography will become computationally breakable. A sovereign infrastructure operator, whether running a government data centre, a regulated hospital network, or a national financial clearing system, cannot treat these devices as peripheral. They authenticate physical access, relay medical telemetry, carry building-management commands, and underpin the operational continuity that NIS-2 Article 21 and DORA now mandate be demonstrably secured.

Why Standard PQC Algorithms Struggle on Constrained Hardware

FIPS 203 ML-KEM and FIPS 204 ML-DSA, standardised by NIST in 2024, are designed for general-purpose computing environments, and their resource profiles expose a hard mismatch with constrained IoT silicon.

ML-KEM-512, the smallest ML-KEM variant, produces public keys of 800 bytes and ciphertexts of 768 bytes. Key-generation and decapsulation together require several kilobytes of stack space and significant arithmetic over polynomial rings. For a Cortex-M0 microcontroller with 32 KB of RAM and no floating-point unit, these operations are marginal at best. ML-DSA-44, the smallest signature scheme in FIPS 204, produces signatures exceeding 2,400 bytes. On an NB-IoT radio link governed by 3GPP’s narrowband physical layer, where maximum transport block sizes are typically under 1,000 bytes, a single ML-DSA signature cannot be transmitted in one frame without fragmentation, which in turn demands reassembly buffers that many constrained devices cannot provision.

Viable alternatives for the most constrained tiers include SPHINCS+ (now standardised as FIPS 205 SLH-DSA), which is stateless and hash-based with a small code footprint, though its signature sizes are large. XMSS (RFC 8391) offers compact signatures but requires stateful key management, creating operational complexity for unattended devices. For key exchange on BLE and MQTT-over-TLS stacks, ML-KEM-512 is achievable on Cortex-M4-class devices using the pqm4 optimised assembly library, which fits within 64 KB RAM. Below that threshold, a quantum-safe gateway architecture, where the constrained device speaks classical TLS to a sovereign gateway that terminates PQC sessions toward the back end, becomes the only operationally realistic option in the near term.

Inventorying and Prioritising the IoT Estate for PQC Migration

Risk-based migration sequencing begins with a structured inventory that classifies every embedded device by two axes: the sensitivity of the data it handles or authenticates, and its technical capacity to receive a PQC firmware update.

The inventory must record hardware platform, firmware version, cryptographic library in use, and whether the device has a documented firmware update mechanism. Devices running OpenSSL or mbedTLS for TLS should be assessed against the library’s current PQC roadmap. Devices using proprietary stacks with no published algorithm agility are candidates for immediate risk-register escalation.

Sovereign Key Management and Certificate Provisioning at Scale

A sovereign operator cannot outsource its IoT PKI to foreign-controlled platforms without introducing CLOUD Act and FISA 702 exposure at the root of its authentication chain. The architecture must be built on an air-gapped offline root CA, hosted on hardware security modules certified to FIPS 140-3 Level 3 or equivalent, located in a jurisdiction with no US corporate nexus. Switzerland, under the revised Federal Act on Data Protection (revFADP), and Germany, under BSI oversight, are the most mature options for European sovereign operators.

Certificate issuance to constrained devices should use EST (RFC 7030) where the device has sufficient stack space, or a lightweight SCEP variant for older hardware. Both protocols are being extended in IETF working groups to carry hybrid classical-PQC certificates during the transition period, pairing an ECDSA or RSA chain alongside an ML-DSA chain in the same X.509 structure. This hybrid approach ensures backward compatibility while providing quantum-safe authentication where the verifying party supports it.

Revocation at scale is the hardest operational problem. OCSP stapling reduces fleet-wide revocation traffic, but constrained devices often cannot perform OCSP themselves. A sovereign operator should provision devices with short-lived certificates, renewed automatically via EST, rather than relying on long-lived certificates backed by CRL distribution points that devices may never consult. Certificate lifetimes of 24 to 72 hours are achievable for devices with reliable connectivity; for intermittently connected NB-IoT devices, a longer lifetime with a sovereign-operated OCSP responder accessible via the same low-bandwidth channel is the workable compromise.

NIS-2, the Cyber Resilience Act, and Supply-Chain Obligations

NIS-2 Article 21 places explicit supply-chain security obligations on essential and important entities. For a sovereign operator deploying embedded devices, this means the cryptographic properties of every firmware component are in scope. The operator cannot claim compliance while deploying smart card readers whose firmware is signed with RSA-2048 keys and whose vendor has no published PQC migration roadmap.

The Cyber Resilience Act, adopted in 2024 and applicable across the EU, adds a parallel obligation for device manufacturers: they must provide a software bill of materials covering top-level dependencies, report actively exploited vulnerabilities to ENISA within 24 hours, and maintain security updates for the expected product lifetime. As ENISA has stated in its NIS-2 implementation guidance: “Supply chain security is not optional under NIS-2. Operators of essential services are directly accountable for the security properties of every component in their technology stack, including firmware in embedded devices.”

A sovereign procurement policy should contractually require CRA-compliant SBOMs in machine-readable SPDX or CycloneDX format, a written firmware maintenance commitment aligned with the device’s expected operational lifetime, and a vendor-published algorithm agility statement confirming which cryptographic primitives can be replaced via firmware update and under what timeline.

Protocol-Level Changes for PQC on MQTT, CoAP, and DTLS

MQTT 5.0 runs over TCP and inherits whatever TLS version the underlying stack negotiates. TLS 1.3 is the correct baseline, as it eliminates several classical handshake weaknesses. Adding ML-KEM-512 for key encapsulation to a TLS 1.3 handshake increases the ClientHello by roughly 800 bytes and the ServerHello by a similar amount, which is manageable on MQTT over TCP but requires careful MTU planning on networks with restrictive packet sizes.

CoAP over DTLS is the more constrained case. DTLS 1.3 handshakes already fragment across multiple UDP datagrams; adding ML-KEM-512 key shares pushes the handshake to six or more round-trip fragments on a 127-byte IEEE 802.15.4 link. The IETF LAKE working group and the CoAP over DTLS 1.3 drafts are actively addressing this, but production-ready implementations for the most constrained 802.15.4 devices are not yet widely available as of 2024.

For open-source library support, the liboqs library from the Open Quantum Safe project provides a production-ready C implementation of ML-KEM and ML-DSA, with bindings for OpenSSL and BoringSSL. wolfSSL, which targets embedded systems and achieves a footprint under 100 KB for its core TLS stack, has added experimental ML-KEM support and is actively integrating FIPS 203 compliance. Both libraries should be evaluated against the specific MCU platform and available RAM before commitment; benchmarks on Cortex-M4 from the pqm4 project provide the most directly usable reference figures for sovereign operators evaluating hardware choices.

Harvest-Now-Decrypt-Later and Cryptographic End-of-Life

The harvest-now-decrypt-later threat is particularly acute for IoT devices because the data they generate, physical access logs, patient telemetry, infrastructure commands, carries long-term intelligence value. As NIST’s Dustin Moody has stated: “The threat of harvest-now-decrypt-later is not theoretical. Adversaries are collecting encrypted traffic today with the explicit intent of decrypting it once cryptographically relevant quantum computers become available.”

A global IoT device count projected to exceed 29 billion by 2030 (Ericsson Mobility Report, 2023) means the attack surface for harvested ciphertext is enormous. For a sovereign operator, devices that cannot receive a PQC firmware update must be treated as cryptographically end-of-life assets today, not when quantum computers arrive. The practical response has three components: network isolation (dedicated VLANs with quantum-safe encrypted overlays terminating at a sovereign gateway), data classification (data from non-upgradeable devices classified at a level consistent with eventual exposure), and hard decommission dates documented in the risk register and tied to capital planning cycles.

Procurement policy is the durable fix. Every device specification issued after 2024 should require documented algorithm agility, a vendor commitment to provide PQC firmware within 24 months of relevant NIST finalisation, and a contractual right to audit the SBOM. The average total cost of a data breach reached USD 4.45 million in 2023 (IBM and Ponemon Institute Cost of a Data Breach Report, 2023), a figure that anchors the business case for the additional procurement due diligence described here.

FAQ

Can ML-KEM (FIPS 203) run directly on a microcontroller with 64 KB of RAM?

Not in its standard reference form. ML-KEM-512, the smallest variant, requires several kilobytes of working stack for key generation and decapsulation. Devices with 32 KB RAM can run optimised implementations from the pqm4 project on Cortex-M4 silicon. Below that threshold, a sovereign gateway that terminates PQC sessions and proxies traffic to constrained devices using classical TLS on the device-side segment is the operationally realistic interim approach.

What does NIST IR 8547 mean in practice for an existing IoT fleet?

NIST IR 8547 sets hard deprecation dates: RSA and elliptic-curve algorithms should not be used in new systems after 2030 and must be discontinued by 2035. For IoT devices with 10-to-15-year operational lifespans, any device procured without a PQC firmware upgrade path is already at risk of being non-compliant within its working life. The document is actionable as a procurement and migration planning anchor today.

Does the Cyber Resilience Act require IoT device manufacturers to supply a software bill of materials?

Yes. The CRA requires manufacturers of products with digital elements placed on the EU market to provide an SBOM covering at minimum top-level dependencies, to report actively exploited vulnerabilities to ENISA within 24 hours, and to supply security updates for the expected product lifetime. Sovereign operators should contractually require CRA-compliant SBOMs in SPDX or CycloneDX format and a documented firmware maintenance commitment before any embedded device is deployed.

How can a sovereign operator avoid dependence on US-controlled PKI when provisioning PQC certificates for IoT devices?

The operator must run its own offline root CA and intermediate issuing CAs on FIPS 140-3 Level 3 certified HSMs, hosted in a jurisdiction with no US corporate nexus. Certificate provisioning for constrained devices should use EST (RFC 7030) or SCEP adapted to hybrid PQC certificate profiles. Foreign-controlled cloud device management platforms introduce CLOUD Act and FISA 702 exposure at the root of the trust chain and must be excluded from the certificate authority hierarchy.

What should a sovereign operator do today about IoT devices that cannot be firmware-updated to PQC?

Classify them as cryptographically end-of-life assets immediately. Isolate them on dedicated network segments with quantum-safe encrypted overlay tunnels terminating at a sovereign gateway. Remove them from any role in authenticating sensitive transactions. Document them in the risk register with a hard decommission date tied to capital planning. Ensure that data they transmit is classified at a sensitivity level consistent with the assumption that their classical encryption will eventually be broken. Update procurement policy to prevent the same gap from recurring in future purchases.