IoT & Embedded Device PQC

A constrained device cannot borrow more memory for a bigger signature, often cannot be reached for an update, and may stay in service for 10–20 years. Devices shipped now will still be verifying firmware and opening sessions when a cryptographically relevant quantum computer may exist — so the choice of algorithm, protocol and hardware is made today and lived with for a decade.

Industrial control systems (SCADA, PLCs, zones and conduits) are covered in OT & Industrial Control Systems PQC; vehicle networks and V2X in Automotive PQC; boot chains in Secure Boot PQC.

Most devices verify far more than they sign: they check firmware and server certificates, while signing happens on a build server or HSM. The two operations have very different costs, so "does FN-DSA fit on a sensor?" has two answers.

• ML-KEM is small when built for stack: ML-KEM-768 decapsulation needs 2,844 B of stack in pqm4's m4fstack build versus 6,452 B in m4fspeed. Counting its keys and ciphertext, the stack build fits a Class 1 budget; the speed build does not (model, step 1).
• ML-DSA-44 verification needs 2,712 B (stack build) and signing 5,080 B; the speed build verifies in fewer cycles but needs 8,912 B.
• FN-DSA-512 verifies with 2,976 B — but signing needs 41,952 B of stack and the full scheme is 103,789 B of code. Verify on the device; sign elsewhere. FIPS 206 is not yet published; sizes here follow the Falcon v1.2 specification (666 B in its padded, fixed-length format).
• LMS verification is hashing only (1,044 B of stack in the reference implementation measured by Campos et al.), with a 60-byte public key.
• FrodoKEM-640 needs 72,408 B of stack to decapsulate and 9,616-byte keys — out of reach below Class 4.

Under the module's fit model (benchmark stack plus buffers, step 1), a Class 1 device using stack-optimised builds can verify with ECDSA P-256, LMS (H10/W4), FN-DSA-512 (Falcon-512), XMSS (SHA2_10_256), ML-DSA-44, ML-DSA-65, ML-DSA-87, and run key establishment with ML-KEM-512, ML-KEM-768, ML-KEM-1024 (tight). Class 0 devices fit none of them and need a gateway.

A forged firmware image is the worst outcome for a device fleet, and the update signature must stay unforgeable for the device's whole life. Three families are standardised for it:

Verification speed on a Cortex-M4 (fastest benchmarked build of each): FN-DSA-512 (Falcon-512) 0.40 M < ECDSA P-256 0.98 M < ML-DSA-44 1.42 M < ML-DSA-65 2.42 M < LMS (H10/W4) 2.66 M < ML-DSA-87 4.19 M < XMSS (SHA2_10_256) 13.07 M cycles. LMS is not the fastest verifier; its case is the tiny key and hash-only security assumption. The LMS-vs-XMSS gap (4.9× in that benchmark) comes from the reference code, as its authors note.

SUIT is three documents: RFC 9019 is the update architecture, RFC 9124 the manifest information model, and draft-ietf-suit-manifest the CBOR manifest format itself. The manifest carries the image digest and conditions and is signed with COSE: HSS-LMS is registered for COSE by RFC 8778 and ML-DSA by RFC 9964; SLH-DSA and FN-DSA are still drafts. Step 2 signs a manifest with ML-DSA or LMS for real and shows the COSE_Sign1 layout.

The boot-time side — verifying the image before it runs — is in Secure Boot PQC; LMS/XMSS state management in Stateful Hash Signatures.

• MQTT 5 runs over TCP and TLS; its maximum packet is 268,435,455 bytes, so PQC there is a bandwidth cost, not a size limit.
• Matter commissions with PASE (SPAKE2+ over P-256), checks a DAC → PAI → PAA attestation chain, then uses CASE (ECDH + ECDSA). A PQC Matter needs new CASE suites and PQC attestation certificates.
• Bluetooth Mesh provisioning exchanges P-256 keys in PB-ADV segments; Mesh Protocol 1.1 adds certificate-based provisioning. An ML-KEM-768 key would take 52 segments where a P-256 key takes 3.
• LoRaWAN 1.1 has no public-key exchange on the air (AES-128 root keys and session keys), so its radio link is not a Shor target. The exposure is the backend: join server and network server TLS, and how root keys were provisioned.

Each certificate holds its subject's public key and its issuer's signature (RFC 5280). In a TLS or DTLS handshake the server sends its leaf and intermediate and leaves the root out (RFC 8446 §4.4.2), so the chain on the wire carries two public keys and two signatures.

Device identity starts at manufacture. An IEEE 802.1AR initial device identifier (IDevID) is a certificate and key installed in the factory; NIST SP 1800-36B shows it anchoring trusted network-layer onboarding. FIDO Device Onboard 1.1 transfers ownership late, with an ownership voucher. EST-coaps (RFC 9148) enrols operational certificates over CoAP. Each of these is a long-lived signature key that PQC must replace — and an IDevID baked into silicon today cannot be swapped later.

Rotating keys on millions of devices is a scheduling problem. Devices sit in thousands of cells or collectors that work in parallel, but every key update passes through the same head-end HSM. In the step 5 default — 2,000,000 smart meters, ML-KEM-768, an illustrative 1,000 operations/s HSM — a cell finishes its radio exchange in about 16 minutes while the HSM needs about 1.1 hours: the HSM, not the radio, sets the pace (model estimate).

Smart-meter data is a harvest-now-decrypt-later target: interval readings reveal when a home is occupied, and meters stay installed 15 years or more. DLMS/COSEM Suite 1 and 2 meters agree keys with ECDH; Suite 0 meters use symmetric key wrap only and have no public-key exchange to break.

What a PQC signature really costs a firmware update: on a 150 KiB image an ML-DSA-87 signature is 2.9% of the bytes (ML-DSA-44: 1.6%). Pushing that update unicast to 1,000 NB-IoT devices takes about 23 hours of downlink — with ECDSA too — while multicast takes 1 minutes. Image size and delivery mode decide whether a cell can be updated (step 6).

• Secure elements with PQC on the chip now exist. Infineon reports Common Criteria EAL6 certification for an ML-KEM implementation on its TEGRION security controllers; Samsung's S3SSE2A was among the first products to receive an ANSSI PQC security certification (2025); STMicroelectronics has announced PQC for its ST54M secure element. Check each certificate's scope — it covers one target of evaluation, not "PQC" in general.
• Many deployed secure elements are ECC-only. Microchip's ATECC608B, for example, does ECDSA/ECDH on P-256, SHA-256 and AES-128 — it cannot offload ML-KEM or ML-DSA. A device built around it needs PQC in MCU firmware or a new part.
• TrustZone-M is isolation, not a secure element. The Armv8-M security extension separates secure and non-secure software on the same core; PQC code in the secure world uses the same RAM, flash and cycles. It protects keys from the application, it does not add capacity or acceleration.
• TPM 2.0. The TCG TPM 2.0 Library Specification version 1.85 adds ML-KEM and ML-DSA; shipping TPMs will follow the specification with a lag.
• Assurance schemes. PSA Certified (Level 2 builds on the SESIP methodology) and EN 17927 (SESIP as a European standard) are how many IoT chips document their security — useful evidence when a regulation asks for "state of the art" protection.

A hybrid key exchange such as X25519MLKEM768 combines a classical and a PQC shared secret; the result stays secret as long as either component is unbroken. On a device that already runs ML-KEM-768 the classical half costs little: X25519 adds 32 bytes to each direction, and its ECC routine (at most 2,048 B of stack in the benchmark) runs before or after ML-KEM rather than on top of its peak. Hybrid does not double the cost; the PQC half dominates it.

See Hybrid Cryptography for combiners and composite certificates.

None of these rules names a PQC algorithm. What they require — secure updates over a support period, state-of-the-art protection, vulnerability handling — is what makes a later PQC migration possible or impossible.

• EU Cyber Resilience Act (Regulation (EU) 2024/2847): vulnerability and incident reporting obligations apply from 11 September 2026; the essential requirements (secure by design, security updates for the support period) from 11 December 2027.
• ETSI EN 303 645: the consumer-IoT baseline — no universal default passwords, a vulnerability disclosure policy, software updates, secure storage of parameters and secure communication with best-practice cryptography.
• EU Radio Equipment Directive: Delegated Regulation (EU) 2022/30 makes cybersecurity essential requirements apply to internet-connected radio equipment from 1 August 2025; EN 18031-1/-2/-3 are the harmonised standards, cited (with restrictions) by Implementing Decision (EU) 2025/138.
• US Cyber Trust Mark (FCC 24-26): a voluntary label for consumer IoT products meeting NIST-derived criteria.
• UK PSTI (Regulations 2023, SI 2023/1007): bans universal default passwords and requires a vulnerability disclosure policy and a stated minimum security-update period.
• NIST IR 8259r1 / 8259A: foundational activities for manufacturers and the core device-capability baseline. NIST IR 8259r1 (April 2026) superseded NIST IR 8259 and names quantum-safe choices as an example of future-proofing, without a deadline; 8259A remains the capability baseline.