IoT Device PQC: Firmware Migration for Constrained Environments

Picture a Cortex-M4-based industrial sensor that monitors pressure readings on a gas pipeline. It has 256 KB flash, 64 KB SRAM, and receives firmware updates over LoRaWAN with a maximum payload of 51 bytes at spreading factor 10. It was provisioned in 2021 with ECDSA P-256 firmware authentication. NIST IR 8547 (November 2024) places ECDSA P-256 on the deprecation schedule with planned disallowed status by 2030 for new deployments in relevant security categories. The device will still be operating in 2031.

The question is not whether to migrate. The question is what to migrate to, given that a 70-byte ECDSA P-256 signature was chosen partly because it fit in the available bandwidth. ML-DSA-44, the smallest FIPS 204 parameter set, produces signatures of 2,420 bytes. SLH-DSA-SHA2-128s (FIPS 205) produces 7,856 bytes. The LoRaWAN channel fits roughly 51. That gap is not a rounding error. It drives every architectural decision this article covers.

Why Direct Algorithm Substitution Does Not Work Here

The instinct in PQC migration programmes is to identify every instance of ECDSA and replace it with ML-DSA. On enterprise servers and cloud infrastructure, that approach is broadly correct. On constrained IoT devices, it fails immediately on bandwidth, and often on memory as well.

ECDSA P-256 in DER encoding is 70 to 72 bytes. ML-DSA-44 is 2,420 bytes. ML-DSA-65 is 3,309 bytes. These signatures must be transported to the device alongside the firmware image being authenticated. For devices on LPWAN protocols, that transport is not feasible through the same channel that delivers the firmware. For devices with limited SRAM, even holding an ML-DSA signature in memory during verification may strain the stack. On a Cortex-M4 at 168 MHz, ML-KEM-768 operations consume approximately 5 KB of stack. On devices with 4 KB total SRAM, the arithmetic is terminal.

The migration path for constrained IoT is therefore not algorithm substitution. It is architectural adaptation: the right algorithm at the right tier, carried through a manifest architecture that separates signature transport from firmware delivery.

Algorithm Selection: Hash-Based Schemes for Firmware Authentication

NIST SP 800-208 (October 2020) approves two families of stateful hash-based signature schemes for firmware authentication: LMS (Leighton-Micali Hash-Based Signatures) and XMSS (eXtended Merkle Signature Scheme). Both rely on the second-preimage resistance of SHA-256 as their sole security assumption. No lattice assumptions, no algebraic structure, no discrete logarithm. SHA-256 retains approximately 128 bits of post-quantum security under Grover's algorithm, which provides only a quadratic speedup for hash inversion. For devices that already include SHA-256 hardware acceleration, as most Cortex-M4 designs with CryptoCell or equivalent do, the hash primitive itself requires no change.

The constraint these schemes impose is state. LMS maintains a Merkle tree of one-time signature leaves. Each signing operation advances a leaf index, and that index must be stored persistently and securely. Reusing a leaf, which happens if power is lost between signing and index increment, or if a VM snapshot restores an older state, is a catastrophic security failure. SP 800-208 is explicit: HSM-backed state management is recommended for high-assurance environments. For firmware signing that occurs at a controlled build server, this constraint is manageable. The signing operation is centralised, predictable, and HSM-backed. An LMS tree with 2^20 leaves handles approximately one million firmware signing events, which is sufficient for any realistic device fleet over a 15-year operational life.

LMS signature sizes depend on tree height and the Winternitz parameter. LMS-SHA256/M32/H10 supports 1,024 signatures and produces a signature of approximately 1,074 bytes. H20 supports approximately one million signatures and produces a larger signature but still well under 2 KB. For IoT firmware authentication, these sizes are workable in manifest architectures even on constrained channels. LMS and XMSS deployment guidance covers parameter selection and tree sizing in detail.

NIST FIPS 205 (SLH-DSA, August 2024) provides a stateless alternative. SLH-DSA-SHA2-128s produces a signature of 7,856 bytes and requires no state management. Where state management cannot be guaranteed across power cycles or where the signing environment involves multiple instances, SLH-DSA is the appropriate choice. The signature is larger, but that cost is borne by the manifest transport channel, not the application processor. The fast variant, SLH-DSA-SHA2-128f, produces 17,088 bytes and is faster to sign but slower to verify; for IoT firmware authentication where signing is off-device and verification is the constrained operation, the small variant (128s) is preferred.

The SUIT Manifest Architecture: Separating Signature from Payload

IETF RFC 9019 and RFC 9124 define the SUIT (Software Updates for Internet of Things) architecture and manifest format. SUIT is the correct framework for PQC firmware authentication on constrained devices because it separates signature transport from firmware payload transport entirely.

In the SUIT architecture, the firmware image and the SUIT manifest are separate objects. The manifest, encoded in CBOR, carries the algorithm identifier, the signature over the firmware hash, and a digest of the firmware payload. The device verifies the manifest signature first, then verifies the firmware digest. It never needs to hold the full firmware image in memory simultaneously during the verification phase. For a device with 64 KB SRAM receiving a 256 KB firmware image, this is not a minor optimisation. It is what makes verification possible at all.

For the LoRaWAN sensor with its 51-byte payload constraint: the SUIT manifest is delivered through a separate management channel, not through the LoRaWAN payload itself. This is already the standard architecture for LoRaWAN device management. Cellular management channels, a dedicated sideband channel, or pre-positioned manifests at commissioning time are all established patterns. The PQC migration changes the signature algorithm inside the manifest, not the transport architecture. A SUIT manifest with an LMS-SHA256/M32/H10 signature is approximately 1.9 KB in total, compatible with delivery over a cellular or IP channel to the gateway before forwarding the firmware to the device.

Tier-2 Segmentation for Key Exchange on Severely Constrained Devices

Firmware authentication (signing and verification) is one part of the IoT security picture. The channel over which firmware and operational data flow also requires protection. ML-KEM, the post-quantum key encapsulation mechanism under FIPS 203, is the migration target for key exchange.

On Cortex-M4 devices, ML-KEM-768 is feasible. Benchmarks from the pqm4 project (Kannwischer et al.) show approximately 1.3 to 1.5 million cycles for ML-KEM-768 key generation and encapsulation at 168 MHz, approximately 8 to 9 milliseconds. Stack usage is approximately 5 KB. This is within the capacity of mid-range Cortex-M4 devices. The hybrid X25519+ML-KEM-768 construction (RFC 9496) runs at the gateway tier where bandwidth and memory constraints are less severe, consistent with how TLS termination already works in most IoT architectures. For PQC migration at the application layer in gateway and cloud-side components, those patterns apply to the tier-2 tier here.

Cortex-M0 and M0+ cores require a different answer. The M0 lacks the DSP instructions (UMULL, UMLAL) that optimised lattice polynomial multiplication exploits. Generic C implementations of ML-KEM on M0 are approximately three to five times slower than on M4, and devices below 8 KB SRAM cannot hold an ML-KEM-512 stack without custom stack-splitting. [INFERRED: 3-5x slowdown estimate, consistent with documented absence of DSP acceleration on M0 and published comparisons in PQC literature.] For severely constrained M0 endpoints, the practical pattern is pre-provisioned session keys managed at the gateway tier, with ML-KEM running at the gateway-to-cloud interface rather than at the device itself.

Side-Channel Considerations

Three specific side-channel risks are worth addressing directly, because IoT firmware engineers are not always the same people who read PQC cryptography papers.

Constant-time requirement for ML-KEM (FIPS 203, Section 3.3). ML-KEM.Decaps must not leak timing information about the private key or the implicit rejection decision. GCC and Clang with optimisation flags (-O2 or -O3) can introduce conditional branches that remove constant-time guarantees from otherwise correct code. The mitigation is post-compilation timing verification on every new compiler version and optimisation level used in the build system. Tools such as dudect provide statistical timing analysis for embedded implementations. [ASSUMED: compiler optimisation risk documented in embedded PQC literature; dudect or similar constant-time analysis citation needed; verify before publication.]

LMS leaf index protection against power-loss fault. If a power failure occurs between the signing operation and the leaf index increment and write-back to persistent storage, the same leaf is used twice on restart. The mitigation is write-before-use: increment the index and flush to non-volatile storage before using the leaf. For devices with no hardware write-barrier (no erase-before-write guarantee on NOR flash), this is a critical design requirement that belongs in the hardware security architecture, not the application code.

Secure element readiness. Widely deployed secure elements in industrial IoT, including STMicroelectronics STSAFE-A, Microchip ATECC608B, and NXP SE050, had no PQC-capable firmware as of Q1 2026. Firmware roadmaps from major SE vendors indicated ML-KEM and SLH-DSA support planned for 2026 to 2027. [ASSUMED: PQC firmware roadmap 2026-2027 for major SE vendors; verify current product status against published vendor documentation before relying on these timelines for procurement.] A device that performs PQC operations on the host MCU because the SE cannot, changes the threat model for key exposure: private key material is exposed to the MCU application processor rather than confined within the SE boundary.

Procurement and Lifecycle Decisions

The Q-Day timeline, approximately 2033 to 2035 for a cryptographically relevant quantum computer, maps directly to procurement decisions being made in 2026. The relevant segmentation:

Devices with three to five year lifecycles procured in 2026 will typically complete their operational lives before Q-Day. ECDSA P-256 firmware authentication is operationally acceptable for their working life. The prudent requirement is OTA update capability with an algorithm-agnostic manifest architecture, so that if the threat timeline accelerates or regulatory requirements change, the migration path exists.

Devices with seven to twelve year lifecycles in industrial and infrastructure applications are a different calculation. Manufactured today with a 2036 or 2038 end-of-life, they may be operating when Q-Day arrives and will certainly be operating when NIST IR 8547's 2030 disallowed-status deadline for ECDSA in new deployments takes effect. Firmware authentication algorithm migration should be in the procurement specification, not treated as a future engineering problem. The UK PSTI Act 2022 (in force from April 2024) mandates authenticated software update mechanisms for consumer IoT products under ETSI EN 303 645 Provision 5.5. For consumer IoT, this creates a legal requirement for authenticated OTA updates that applies regardless of the algorithm migration discussion; the algorithm is the manufacturer's choice.

The most useful procurement question to put to any IoT device vendor offering OTA update capability in 2026: "What signature algorithm does the OTA update authentication currently use, and what is your migration path to SLH-DSA or LMS?" Vendors who cannot answer that question specifically are accepting a risk on behalf of their customers.

Implementation Checklist

• Identify the signing algorithm in the OTA update authentication chain for each device in scope.
• Map device hardware: Cortex-M4 with sufficient SRAM can run ML-KEM-768 for channel encryption. Cortex-M0 or sub-8 KB SRAM devices need gateway-tier segmentation.
• Adopt SUIT manifest architecture (RFC 9019/9124) for all new firmware update pipelines. Existing SUIT implementations require only a signature algorithm update for PQC migration.
• For signing infrastructure: evaluate LMS (bounded signature count, centralised HSM) versus SLH-DSA (stateless, higher signature size, manageable through manifest architecture).
• For devices with secure elements: verify the SE vendor's PQC firmware roadmap before committing to a migration architecture that depends on SE-resident PQC operations.
• Include post-compilation timing verification in the CI/CD pipeline for any ML-KEM implementation on embedded targets.
• For LMS deployments: implement write-before-use leaf index management with hardware write-barrier guarantees.