PQC for IoT: Quantum-Safe Identities for Billions of Devices

Executive summary — The devices being deployed today — sensors, meters, controllers, vehicles — will still be in the field when quantum computers threaten the cryptography protecting them. Many cannot be patched easily, if at all. This article confronts the hard constraints of securing IoT with post-quantum cryptography: limited compute, memory and power, the algorithm choices that fit, and how to provision quantum-safe identities across enormous fleets.

An industrial sensor installed this year may operate for fifteen or twenty years. A connected car stays on the road for a decade or more. Smart meters are expected to run for their entire billing life. Each of these devices relies on cryptography to prove its identity and protect its communications, and each will very likely still be in service when a cryptographically relevant quantum computer arrives. Unlike a server that can be re-keyed overnight, many of these devices are physically inaccessible, rarely updated, or simply too constrained to change their cryptography after deployment. The time to make them quantum-safe is before they ship.

The Device Fleet Time-Bomb

The scale of the problem is what makes it distinctive. There are billions of connected devices, and the number keeps climbing. Every one is a non-human identity that must be provisioned, authenticated and eventually retired, which places IoT squarely within the wider discipline of machine identity management. The quantum dimension adds urgency: long device lifetimes mean the migration window is already open, and devices deployed with only classical cryptography today may become the weakest link in a network years from now.

Working Within Hard Constraints

What makes IoT genuinely difficult is that post-quantum algorithms are, in general, heavier than the classical ones they replace — larger keys, larger signatures, more computation. On a powerful server that is a manageable cost. On a battery-powered sensor with kilobytes of memory and a modest processor, it can be prohibitive. Any credible IoT PQC strategy has to begin with the device's real constraints rather than with an idealised algorithm choice.

Compute, memory and power. Three limits dominate. Compute determines how quickly, and how often, a device can perform cryptographic operations without stalling its primary function. Memory constrains how large a key or signature the device can store and manipulate. Power — especially for battery or energy-harvesting devices — caps the total cryptographic work a device can afford over its life. A PQC choice that ignores any of these will either fail to deploy or drain the device prematurely.

Choosing the right algorithms. The NIST-standardised algorithms offer different trade-offs that map onto these constraints. ML-DSA (FIPS 204) provides strong lattice-based signatures with moderate sizes suitable for many devices. SLH-DSA (FIPS 205), a hash-based scheme, offers conservative security with larger signatures, useful where long-term assurance outweighs size. For firmware and boot signing specifically, stateful hash-based schemes such as LMS and XMSS are well suited because a device verifies rather than generates those signatures. Matching the algorithm to the device's role and limits is the core engineering decision, and the NIST PQC standards reference sets out the options in detail.

Need to provision quantum-safe device identities at fleet scale? eMudhra provisions quantum-safe device identities at fleet scale.

Provisioning Identities at Scale

Even with the right algorithm chosen, getting a unique, trusted identity onto billions of devices is its own challenge. The most robust approach injects a device identity during manufacturing, so each unit leaves the factory with a certificate and a protected private key, ideally anchored in secure hardware. This avoids the fragile alternative of trying to provision identity over the network after deployment, and it means a device is trustworthy from first boot.

Because fleets are enormous and long-lived, the provisioning system itself must be built for scale and for change: able to issue millions of certificates through automated pipelines, to support hybrid classical-plus-post-quantum credentials during the transition, and to manage renewal and retirement across the fleet's entire life. Where devices can be updated, crypto-agility — the ability to change algorithms later — is invaluable insurance against a standard evolving mid-lifecycle.

A Pragmatic Path Forward

For most organisations the sensible sequence is to inventory the cryptography in current and planned devices, prioritise long-lived and hard-to-update devices for early attention, adopt hybrid credentials where devices can support them, and build device identity into the manufacturing process for new designs. Selecting infrastructure that can issue and manage quantum-safe certificates at this scale is central to the plan. The organisations that begin this inventory now will retrofit far fewer devices later, and will avoid the far harder problem of securing a fleet that has already been deployed beyond reach.

SECURE YOUR DEVICE FLEET BEFORE IT SHIPS

eMudhra provisions quantum-safe device identities at fleet scale, with hybrid credentials and crypto-agility built in. Explore eMudhra post-quantum cryptography or talk to an eMudhra expert.