PQC for IoT and Long-Lived Connected Devices

Quick answer: IoT devices combine the two hardest problems in post-quantum migration at once: constrained hardware that struggles with larger keys and signatures, and multi-decade field deployment that means a device shipping today may still be running in 2036 or later. Post-quantum X.509 certificates commonly run anywhere from roughly 1.5 to 10 times larger than classical certificates depending on algorithm and parameter set, which strains protocols and memory budgets that were sized for RSA or ECC. The devices that survive this transition well are the ones where crypto-agility, gateway termination for the most constrained hardware, and a firmware update path were designed in at manufacturing, not retrofitted after millions of units are already in the field.

Enterprise PQC migration is hard because of scale and inventory gaps. IoT migration is hard for a different reason: physical constraints that do not bend to a software patch, and deployment lifecycles long enough that a wrong decision made today is still a wrong decision a decade from now. This guide covers the specific constraints across the device lifecycle, from manufacturing to retirement.

Key Takeaways

• Post-quantum X.509 certificates are commonly cited as 1.5 to 10 times larger than classical certificates, depending on algorithm and parameter set, which strains constrained protocols and device memory.
• Devices shipping today with typical 10-year expected lifespans will still be operating in the mid-2030s, past NIST’s proposed 2030 deprecation date for quantum-vulnerable algorithms.
• Gateway termination, handling PQC negotiation at a gateway rather than on the constrained device itself, is a practical near-term strategy for hardware that cannot be upgraded to support larger keys directly.
• Manufacturing-stage PKI decisions, including the certificate authority relationship itself, are effectively decade-long commitments once tied to a device with a 10-year field lifespan.
• CISA’s guidance treats critical infrastructure and operational technology transition, much of which runs on long-lived embedded devices, as a distinct focus area within its broader PQC initiative.

Constrained Hardware: What Actually Breaks

The core tension is straightforward: post-quantum algorithms need more memory, more compute, and more bandwidth than the classical algorithms most IoT hardware was sized around. ML-KEM key generation and encapsulation run efficiently even on genuinely constrained microcontrollers, with published benchmarks on an ARM Cortex-M0+ running a full ML-KEM-512 key exchange in well under 40 milliseconds, faster than the equivalent classical ECDH operation on the same hardware. Signature operations are the harder case: ML-DSA signing on similarly constrained hardware can show highly variable timing due to its rejection-sampling design, and hash-based alternatives like SLH-DSA run one to two orders of magnitude slower still. Algorithm choice for the signing side specifically needs real benchmarking on the target hardware, not an assumption that if key exchange fits comfortably, signing will too.

Certificate Sizes and Protocol Fit

Post-quantum X.509 certificates are commonly cited as growing anywhere from roughly 1.5 to 10 times larger than classical RSA or ECC certificates, with the wide range reflecting different algorithm choices, parameter sets, and whether hybrid or pure post-quantum certificates are used. That size increase is not evenly absorbed across an IoT deployment. Protocols designed around small, fixed message sizes, and devices with limited flash storage for certificate chains, can hit hard limits that a general enterprise PKI migration simply does not encounter. Confirm the actual certificate and key sizes your specific chosen algorithm and parameter set will produce, and test them against your device’s real memory budget and the protocol constraints of whatever transport it uses, before committing a fleet-wide rollout to a specific algorithm choice.

Device Identity and Onboarding

Device identity certificates, typically provisioned via protocols like EST, SCEP, or BRSKI at manufacturing or first onboarding, bind a device’s cryptographic identity to manufacturer, model, and serial number attributes. Standards like Matter now mandate X.509 Device Attestation Certificates for connected device categories, making unique cryptographic identity a compliance requirement, not just a best practice, for products in scope. Post-quantum migration touches this identity layer directly: the algorithm chosen at manufacturing time for the device identity certificate is effectively locked in for that device’s operational life unless the provisioning and update infrastructure was specifically designed to support a later algorithm change.

Field Upgrades: The Real Bottleneck

Moving a fielded device to post-quantum cryptography typically requires several coordinated steps: updating the cryptographic library on the device itself, generating a new post-quantum key pair, requesting and receiving a new certificate, and, critically, updating the device’s trusted root certificate store to recognize the new post-quantum root CA. Each of these steps depends on a reliable over-the-air update mechanism reaching the device, which is the actual constraint for most fleets, not the cryptography itself. A device with unreliable connectivity, no OTA capability at all, or a manufacturer that has stopped supporting it, cannot receive any of these updates regardless of how well-designed the target post-quantum architecture is. Devices may also need to support both an existing classical certificate and a new post-quantum certificate simultaneously during the transition, adding another storage and protocol constraint on top of the larger individual certificate sizes.

Manufacturing PKI: A Decade-Long Commitment

The certificate authority relationship chosen at manufacturing time is not a short-term vendor decision once tied to devices with 10-year expected field lifespans; it is effectively a decade-long commitment, since that CA needs to keep issuing, renewing, and validating certificates for every device in that product line for its entire service life. A device manufactured in 2026 with a 10-year lifespan will still be in the field in 2036, well past NIST’s proposed 2030 deprecation date for quantum-vulnerable algorithms, which makes the manufacturing-stage PKI and algorithm decision one of the highest-leverage choices in the entire device lifecycle. Building provisioning infrastructure sized for the eventual fleet scale, not just the first production run, from day one avoids a costly retrofit once volume grows.

Retirement and Decommissioning

Device identity lifecycle does not end at deployment; certificate revocation, decommissioning, and end-of-life key destruction all need to be planned as explicitly as provisioning, and this matters more, not less, under post-quantum migration. A device retired without a clean decommissioning process leaves its identity certificate and key material in an indeterminate state, a gap that becomes a genuine liability if that certificate was ever compromised or if its algorithm becomes deprecated while the device is still technically capable of authenticating with it.

What We’d Actually Recommend

Benchmark your actual target hardware against real ML-DSA and ML-KEM operations before committing to an algorithm, rather than relying on published figures from different hardware. For genuinely constrained devices that cannot handle post-quantum operations directly, plan gateway-termination architecture now, where a more capable gateway or edge server handles PQC negotiation on the constrained device’s behalf. Treat the manufacturing-stage CA and algorithm decision as the highest-leverage choice in the lifecycle, and build OTA update capability, including root store updates, as a first-class requirement rather than an afterthought for any device with a multi-year expected field life.

How Encryption Consulting Can Help

The manufacturing-stage PKI decision this guide treats as highest-leverage is exactly what CertSecure Manager and PKI-as-a-Service are built to support: CA-agnostic device identity issuance at manufacturing scale, with policy-driven algorithm selection so a fleet is not locked into a single, hard-coded algorithm choice for its entire field life. Where firmware signing is part of the device lifecycle, CodeSign Secure brings HSM-backed post-quantum signing, including LMS and XMSS hash-based schemes, into the manufacturing and field-update pipeline.

Our PQC Advisory Services build the hardware benchmarking, gateway-termination architecture, and manufacturing PKI decisions covered in this guide into a device-lifecycle migration plan, from provisioning through retirement.

Designed In, Not Retrofitted

IoT post-quantum migration does not have a universal answer the way a TLS certificate rollout does, because hardware constraints and deployment lifecycles vary enormously across device categories. What holds across all of them is that the decisions with the most consequence, algorithm choice, CA relationship, OTA update capability, get made once, at manufacturing, and then live with the device for a decade or more. Getting those decisions right before the first production run ships, rather than trying to retrofit them into a fleet that is already in the field, is the difference between a manageable transition and a stranded fleet of devices that can never be made quantum-resistant.

Frequently Asked Questions

How much larger are post-quantum certificates for IoT devices?

Commonly cited figures range from roughly 1.5 to 10 times larger than classical certificates, depending on the specific algorithm, parameter set, and whether pure post-quantum or hybrid certificates are used. Confirm the actual size for your chosen algorithm against your device’s real memory and protocol constraints rather than relying on a general estimate.

What is gateway termination and when does it make sense for IoT?

Gateway termination means a more capable gateway or edge server handles post-quantum cryptographic negotiation on behalf of a constrained device that cannot perform those operations directly. It is a practical strategy for hardware too limited to support post-quantum algorithms natively, or where firmware cannot be updated to add that support.

Why is the manufacturing-stage certificate authority choice so significant?

A device with a 10-year expected field life needs that CA to keep issuing, renewing, and validating its certificates for the device’s entire service life. That makes the CA relationship, and the algorithm decision tied to it, effectively a decade-long commitment rather than a simple vendor choice.

Can a device’s trusted root certificate store be updated remotely for post-quantum migration?

Only if the device has a reliable over-the-air update mechanism designed to support it. Adding a new post-quantum root CA to a device’s trust store is one of several coordinated steps a field migration requires, and it depends entirely on OTA capability that many older or minimally connected devices were never built with.

Do all IoT devices need the same post-quantum algorithm?

No. Algorithm choice should be benchmarked against each device category’s actual hardware constraints. A capable gateway device might run full ML-DSA comfortably, while a highly constrained sensor might need a gateway-termination architecture instead of running post-quantum cryptography natively at all.