Post-Quantum Cryptography for IoT and Connected Devices

Why is the quantum threat especially urgent for IoT?

IoT and connected devices face a sharper version of the quantum problem for two reasons: they have long operational lifespans and they are hard to update. A sensor, medical device, industrial controller, smart meter, or connected vehicle deployed today may still be running in 10 to 15 years, squarely inside the window when a cryptographically relevant quantum computer could exist. Unlike a server you can patch overnight, many devices are physically remote, resource-constrained, or effectively unpatchable once shipped.

That combination is what makes IoT distinctly dangerous. The cryptography you ship in a device today has to survive threats that don't fully exist yet, on hardware you may never touch again. A design decision made now can lock in quantum-vulnerable cryptography for the device's entire decade-plus life.

What makes post-quantum cryptography hard on devices?

Constrained hardware is the core challenge. Many IoT devices have limited processing power, memory, storage, and battery, while some post-quantum algorithms carry larger keys and signatures than the RSA and ECC they replace. The engineering task is fitting quantum-safe algorithms (particularly ML-KEM and ML-DSA) into those limits without exhausting the device's resources or its battery.

The encouraging news is that lattice-based algorithms were selected partly for efficiency, and optimized implementations increasingly run well on constrained hardware. Larger signature sizes can strain bandwidth-limited or storage-limited devices, but these are solvable engineering problems with careful design. The harder problem is often organizational rather than technical: knowing what cryptography is embedded across a device fleet you may not fully control or even fully inventory.

Where does cryptography live in a connected device?

Three functions matter most, and each carries a distinct quantum risk. Firmware signing protects the authenticity of updates; if it is broken, the result is forged updates or malware distributed at device scale. Device identity governs which device is trusted; if it is broken, the result is impersonation or rogue devices on the network. Data in transit covers telemetry and commands; if it is broken, the result is interception and tampering.

Firmware signing is the most critical, because it is the mechanism by which a device can be updated at all, including updated to become quantum-safe. If firmware signatures rely on quantum-vulnerable algorithms, the update channel itself becomes a future attack surface: a quantum-capable attacker could sign malicious firmware that devices accept as genuine. This is why post-quantum digital signatures are the first priority for device security, ahead of even data encryption.

Why is device identity a growing concern?

As machines increasingly act autonomously and communicate with each other, the question "is this device really what it claims to be?" becomes foundational. Each connected device needs a trustworthy identity, usually anchored in cryptographic keys and certificates. If those can be forged by a quantum computer, an attacker could impersonate legitimate devices at scale: injecting rogue sensors into an industrial network, spoofing medical devices, or masquerading as trusted nodes in critical infrastructure.

This ties IoT security directly to the broader challenge of machine identity: as the number of non-human identities explodes, quantum-safe device identity becomes part of the enterprise's overall trust fabric, not an isolated device concern.

How should manufacturers and operators prepare?

The two roles have different priorities. For manufacturers, the imperative is designing crypto-agility into new devices now: the ability to update algorithms in the field rather than baking a single algorithm permanently into silicon. A device that cannot change its cryptography is a device that cannot be made quantum-safe later. For operators, the task is inventorying the installed base: which devices use which cryptography, which can be updated over the air, and which cannot. This device-level view feeds into a broader cryptographic bill of materials.

Devices that can be neither updated nor made quantum-safe become known risks: assets to schedule for replacement on a planned timeline rather than discover as vulnerabilities after a breach. Naming those devices early is itself a risk-reduction step.

What's the first step for an IoT quantum-safe strategy?

Start with the longest-lived and highest-impact devices (critical infrastructure controllers, medical devices, connected vehicles, industrial systems) and ensure new designs support post-quantum firmware signing and crypto-agility from the outset. Then work through the installed base by lifespan and impact. Because so much IoT sits inside critical infrastructure, the stakes extend far beyond individual devices to the essential systems they operate, where a coordinated compromise could have physical consequences.