Post-Quantum Cryptography for IoT Devices: Solving the Constrained Hardware Challenge (2026)

T. Torosa 05/21/2026Updated: 05/21/2026

0 17 minutes read

Post-quantum cryptography iot devices — four-class migration pyramid showing ml-kem deployment path from class 0 hardware replacement to class 3 full tls hybrid. — IoT device class determines the available migration path — not all constrained devices can run software PQC, and the device classification step must precede any migration planning.

The Post-Quantum Cryptography IoT Devices (PQC) challenge is qualitatively different from enterprise TLS migration. Where a server administrator can deploy hybrid ML-KEM by updating an OpenSSL configuration, Post-Quantum Cryptography IoT Devices environments involve fleets of millions of deployed sensors, actuators, and field devices that present constraints far beyond simple software updates.

Table of Contents

These include processors with clock speeds measured in megahertz, RAM measured in kilobytes, firmware architectures that may not support in-field cryptographic updates, and device lifespans of 10 to 20 years that extend well into the CRQC threat window [1].

At the same time, the assumption that constrained Post-Quantum Cryptography IoT Devices cannot run post-quantum cryptography is increasingly incorrect. Peer-reviewed benchmark data published in March 2026 demonstrates that ML-KEM-512 completes a full key exchange in 35.7 ms on an ARM Cortex-M0+ processor — 17x faster and 94% less energy than ECDH P-256 on the same hardware. This evidence is reshaping how security teams evaluate the readiness of Post-Quantum Cryptography IoT Devices in constrained environments.

⚠ Technical Disclaimer:
This article is for educational and informational purposes only. It does not constitute professional cybersecurity, cryptographic, or legal advice. Organizations should engage qualified professionals before implementing cryptographic changes.

The Post-Quantum Cryptography IoT Devices challenge is not primarily a performance problem. It is a classification and lifecycle management problem. Some classes of constrained devices genuinely cannot run software PQC and require hardware replacement. Others can run ML-KEM-512 via firmware update today. The migration path for each device in a Post-Quantum Cryptography IoT Devices fleet depends on which class it belongs to — and that classification must be established during the cryptographic inventory phase of the migration program.

For the foundational quantum threat analysis, see the pillar guide: [Post-Quantum Cryptography 2026: Why Your Encryption Strategy Must Change Now].
For the HNDL threat model that makes IoT data collection a present-tense risk, see: [Harvest Now, Decrypt Later (HNDL) Attacks Explained].

The IoT Device Classification Framework — Four Migration Paths

The RFC 7228 device classification framework — which categorizes constrained devices into classes based on available RAM, flash, and processing capability — provides a practical basis for assigning migration paths across Post-Quantum Cryptography IoT Devices [4]. The four-class framework in Table 1 maps RFC 7228 device profiles to specific quantum-safe IoT devices migration strategies, grounded in 2026 benchmark data. The critical insight is that the correct approach for securing Post-Quantum Cryptography IoT Devices is determined first by hardware capability, not by function, vendor, or deployment date.

For devices where cryptography is burned into ASICs or FPGAs, algorithm updates require hardware recapitalization rather than software patches — a constraint that NIST CSWP 39 explicitly acknowledges [1]. Within IoT PQC environments, Class 0 devices fall into this category. Identifying these devices during the CBOM inventory phase is essential because they require capital allocation for hardware replacement rather than engineering effort for firmware modification.

Class 1 through Class 3 IoT PQC devices, by contrast, have documented and practical pathways to software-based PQC adoption. These pathways are executable in 2026 using available cryptographic libraries, optimized implementations, and firmware update mechanisms, making them the primary focus for near-term IoT cryptography migration programs.

Table 1: IoT device classification matrix — four classes with resource profiles, device examples, and PQC migration path for each class.

Class	Device Profile	Typical Resources	Examples	PQC Migration Path
0	Micro-constrained (RFC 7228 Class 0)	< 10 KB RAM < 100 KB Flash ≤ 8 MHz clock	Low-power sensors, simple RFID tags, low-end 8-bit MCUs	Hardware replacement required — no path for software PQC. Classify in CBOM and budget replacement in device lifecycle planning. Mitigate via PQC-capable gateway
1	Constrained (RFC 7228 Class 1)	≤ 10 KB RAM ≤ 100 KB Flash 8–48 MHz clock	Smart meters, medical monitors, industrial field nodes (Cortex-M0+)	ML-KEM-512 feasible via reference C: 35.7 ms, 2.83 mJ on RP2040 (Cortex-M0+ 133 MHz) — 17x faster and 94% less energy than ECDH P-256. Firmware update deployment; DTLS 1.3 for key exchange
2	Lightly constrained (RFC 7228 Class 2)	≥ 50 KB RAM ≥ 250 KB Flash 48–200 MHz clock	Home automation, wearables, ESP32, Cortex-M4 devices	ML-KEM-768 feasible; 2–4 ms encapsulation on Cortex-M4. pqm4 optimized library available. DTLS 1.3 + ML-KEM over MQTT or CoAP. Hybrid key exchange practical
3	Capable embedded (Linux-capable)	≥ 256 KB RAM ≥ 1 MB storage 200 MHz–1 GHz	Industrial gateways, Raspberry Pi class, smart cameras	Full ML-KEM-768 or -1024 + ML-DSA deployment. TLS 1.3 with X25519MLKEM768. Treat as server-class deployment for PQC configuration. Prioritize immediately.

Quick Decision Rule:

Class 0 → Replace
Class 1 → ML-KEM-512 (firmware)
Class 2 → ML-KEM-768 (DTLS)
Class 3 → Full hybrid TLS

💡 For more information, explore the complete segments of our PQC https://theweekgeek.com/post-quantum-security-series/Series

ML-KEM on Constrained Hardware

What the 2026 Benchmarks Show

The first systematic benchmark of the finalized NIST PQC standards (FIPS 203 and FIPS 204) on the ARM Cortex-M0+ — the most constrained 32-bit processor class in widespread Post-Quantum Cryptography IoT Devices deployment — was published in March 2026 [1]. The study measured ML-KEM and ML-DSA performance on the RP2040 (Raspberry Pi Pico) at 133 MHz with 264 KB SRAM, using PQClean reference C implementations.

The headline finding was that ML-KEM-512 completes a full key exchange in 35.7 ms, consuming 2.83 mJ — 17 times faster and 94 percent less energy than ECDH P-256 on the same hardware [1]. This result demonstrates that lattice-based PQC is practical on sub-$5 processors powering Post-Quantum Cryptography IoT Devices, including sensors and embedded controllers deployed at scale.

For quantum-safe IoT devices, this benchmark fundamentally challenges the long-standing assumption that constrained hardware cannot support post-quantum algorithms. Instead, it confirms that key exchange — the most critical cryptographic primitive for secure communication — is already viable across a significant portion of IoT deployments without requiring hardware replacement.

ML-DSA signing presents a different challenge for quantum-safe IoT devices operating under strict latency and energy constraints. The rejection sampling mechanism in ML-DSA introduces high latency variance — the March 2026 benchmark found a coefficient of variation of 61–71 percent across signing operations, with 99th-percentile latencies reaching approximately 1,100 ms for ML-DSA-87 [1].

For real-time constrained applications, this variance is operationally significant. ML-DSA-44 (the lowest security parameter set) is more practical for Post-Quantum Cryptography IoT Devices than higher variants. For devices requiring deterministic signing latency, stateless hash-based SLH-DSA (FIPS 205) or hardware-accelerated ML-DSA implementations should be evaluated against application-specific latency budgets.

Table 2: ML-KEM and ML-DSA performance benchmark data for constrained IoT hardware — key exchange time, energy consumption, and comparison to classical ECDH.

Algorithm	Platform	Full Key Exchange	Energy / Op	Comparison to Classical / Notes
ML-KEM-512 (FIPS 203)	ARM Cortex-M0+ RP2040, 133 MHz 264 KB SRAM	36.3 ms total (keygen + encaps + decaps)	2.83 mJ per full exchange	17x faster and 94% less energy than ECDH P-256 on the same hardware. Confirms ML-KEM-512 is practical on sub-$5 IoT processors. Source: Chhetri 2026 (arXiv:2603.19340) [1]
ML-KEM-768 (FIPS 203)	ARM Cortex-M4 pqm4 optimized	2–4 ms per encapsulation operation	Low — within standard IoT power envelope	3–5x faster than classical ECC on Cortex-M4. Recommended for Class 2–3 devices. pqm4 assembly-optimized library available for M4. Source: MDPI CRYSTALS-Kyber survey [2]
ML-DSA-44 (FIPS 204)	ARM Cortex-M0+ RP2040, 133 MHz	Variable signing (rejection sampling) 66–73% CV — 99th percentile: 489.9 ms	Higher latency variance than KEM (99th pctile: ~1100 ms)	High signing latency variance due to rejection sampling: ML-DSA-44 99th percentile 489.9 ms; ML-DSA-87 99th percentile 1,125 ms. ML-DSA-87 is impractical for real-time constrained applications; ML-DSA-44 is more suitable where signing latency tolerance exists. Source: Chhetri 2026 [1]
ECDH P-256 (classical, for comparison)	ARM Cortex-M0+ RP2040, 133 MHz	~617 ms total (classical reference)	~48 mJ per full exchange	Classical baseline — ML-KEM-512 outperforms ECDH P-256 on constrained hardware on both speed and energy. Source: Chhetri 2026 [1]
ML-KEM ASIC (hardware-accelerated)	TSMC 40 nm ASIC implementation	877,000 ops/sec (encapsulation)	2,272 kOPS/W power efficiency	RSA-3072 achieves < 200 OPS in equivalent hardware — ML-KEM ASIC is 4,000x more throughput-efficient. Demonstrates hardware-accelerated PQC feasibility for constrained devices at scale. Source: Springer 2025 [3]

ASIC acceleration insight: An ASIC implementation of ML-KEM (CRYSTALS-Kyber) in TSMC 40 nm technology achieved 877,000 encapsulation operations per second at a power efficiency of 2,272 kOPS/W — compared to fewer than 200 OPS for RSA-3072 in equivalent hardware. [3] Hardware-accelerated PQC in next-generation secure elements makes ML-KEM practical even for Class 0-adjacent devices in new product designs.

Post-quantum cryptography iot devices ml-kem-512 benchmark — 36. 3 ms and 2. 87 mj versus ecdh p-256 617 ms and 48 mj on arm cortex-m0+. — ***Benchmark data from March 2026 confirms that ML-KEM-512 outperforms ECDH P-256 on both speed and energy on the most constrained 32-bit IoT processor class in widespread deployment.***

The Regulatory Pressure on IoT PQC — EU CRA and Global Mandates

The Post-Quantum Cryptography IoT Devices migration is no longer a voluntary security improvement. A set of binding regulatory requirements — converging across the EU, the United States, Australia, and Canada — is creating legal obligations for manufacturers and operators of Post-Quantum Cryptography IoT Devices, extending directly to quantum-safe cryptography mandates [5].

The EU Cyber Resilience Act (CRA), expected to apply from December 2027, requires that internet-connected products include a quantum-safe upgrade path as a condition of CE marking. For Post-Quantum Cryptography IoT Devices, this means products released after December 2027 with hardcoded classical-only cryptography will not meet the “state-of-the-art” security requirements defined under the CRA [6].

The EU Coordinated PQC Roadmap (June 2025) requires Member States to complete the transition for high-risk use cases — including IoT PQC Devices deployed in critical infrastructure such as energy, healthcare, telecommunications, and transport — by the end of 2030 [7].

A proposed amendment to NIS2 (COM(2026) 13, January 2026) identifies HNDL (Harvest Now, Decrypt Later) attacks as “likely occurring already now” and explicitly requires Member States to adopt PQC transition policies [8]. This regulatory framing significantly increases compliance pressure on quantum-safe IoT device ecosystems, particularly those handling long-lived or sensitive data.

For manufacturers targeting EU markets, the implication is direct: quantum-safe IoT devices designed in 2026 must be architected with firmware-upgradeable cryptography. Without this capability, products face lifecycle and compliance constraints that are likely to materialize within three to five years of production, impacting both market access and long-term viability.

Table 3: Regulatory compliance matrix for IoT PQC — five major frameworks with IoT scope, deadlines, and practical implications for device manufacturers and operators.

Regulation / Framework	IoT Scope	PQC Deadline for IoT	Practical Implication
EU Cyber Resilience Act (CRA, expected Dec 2027)	Essential entities, including operators of IoT-dependent critical infrastructure	Products released after Dec 2027 must include a quantum-safe upgrade path; high-risk use cases must be quantum-secure by 2030	Devices manufactured in 2025–2026 must be designed for firmware-upgradeable PQC. Hardcoded classical crypto blocks CE marking for new products
EU Coordinated PQC Roadmap (June 2025)	Critical infrastructure, including IoT in energy, healthcare, telecoms, transport	Pilots for high-risk IoT by the end of 2026; high-risk transition complete by the end of 2030; full migration by 2035	Industrial IoT in critical sectors must begin PQC pilot programs in 2026. Operators must establish national roadmaps for IoT device migration
NIS2 Directive (amended COM(2026) 13)	Essential entities, including operators of IoT-dependent critical infrastructure	PQC transition policies are required in national cybersecurity strategies; HNDL attacks are named as a present-tense threat	NIS2 entities operating IoT infrastructure must include quantum risk in cybersecurity governance and risk assessments as of 2026
NIST IR 8547 (U.S. deprecation timeline)	Federal systems and contractors; de facto global standard	RSA and ECC deprecated for federal IoT systems by 2030; fully disallowed by 2035	IoT devices in U.S. government supply chains must support ML-KEM and ML-DSA by 2030. Defense and healthcare IoT subject to earlier CNSA 2.0 timelines
CNSA 2.0 (NSA, U.S. NSS)	National Security Systems and the defense supply chain IoT	New IoT acquisitions: ML-KEM + ML-DSA required by Jan 2027; firmware signing by 2025	Defense IoT must already use PQC firmware signing. New sensor, gateway, and field device acquisitions from 2027 onward must be fully CNSA 2.0 compliant

Gateway-Based PQC — Protecting Class 0 and Legacy Devices Without Hardware Replacement

Class 0 and legacy Post-Quantum Cryptography IoT Devices that cannot run software PQC are not without a migration path — but the transition does not occur on the device itself. In IoT PQC architectures, gateway-based PQC introduces a PQC-capable intermediate node between the constrained device and the network, handling quantum-safe key exchange on behalf of devices that cannot execute it.

The constrained device continues to use classical cryptography for local communication to the gateway, while the gateway secures the external communication path using ML-KEM hybrid TLS or DTLS 1.3 with post-quantum key exchange. This model enables partial protection for Post-Quantum Cryptography IoT Device deployments without requiring immediate hardware replacement.

This architecture does not provide full end-to-end quantum-safe security — the device-to-gateway link remains classically protected — but it significantly reduces HNDL (Harvest Now, Decrypt Later) exposure for quantum-safe IoT devices on the internet-facing segment, where large-scale traffic collection is most likely.

For IoT protocols, DTLS 1.3 (Datagram TLS for UDP-based protocols) with X25519MLKEM768 hybrid key exchange represents the primary mechanism for securing Post-Quantum Cryptography IoT Devices communication. This applies to MQTT over TLS and the Constrained Application Protocol (CoAP) [2].

From an implementation perspective, the PQM4 library provides assembly-optimized ML-KEM implementations for ARM Cortex-M4 processors, while the PQCA mlkem-native and mldsa-native packages (Linux Foundation, 2026) offer production-ready support for Class 1–2 IoT PQC Devices [1].

For engineers asking specifically about pqm4 library ML-KEM Cortex-M4 deployment: the pqm4 framework provides assembly-optimized implementations achieving 2–4 ms encapsulation on STM32F4 — download from github.com/mupq/pqm4 and verify the target device matches the M4 optimization profile before benchmarking in your specific hardware environment.

For Class 3 gateway systems within PQC IoT Devices environments, the full TLS 1.3 hybrid deployment model described in PQC for TLS and VPN: The Practical Deployment Guide for Network Security Teams in 2026 applies directly without modification.

Gateway-based pqc protecting class 0 & legacy iot devices — PQC positions a PQC-capable intermediate node between the constrained device and the network, handling the quantum-safe key exchange on behalf of devices that cannot execute it

💡 For more information, explore the complete segments of our PQC Series

Counter-Arguments: Four Honest Challenges to IoT PQC Deployment

Objection: The IoT device lifecycle is too long — devices deployed today will be replaced before any CRQC arrives, making PQC migration unnecessary for existing fleets.

Discussion: This reasoning inverts the HNDL timeline. IoT devices with 10–20 year lifespans deployed in 2026 will still be operational in 2036–2046 — well past the 2030–2040 CRQC arrival window estimated by expert consensus.[1] Data transmitted from those devices today is being captured by adversaries who will apply quantum decryption once a CRQC is available.

The confidentiality of that data is at risk from the day of transmission, not from the day the device is retired. Healthcare IoT generating patient records, industrial IoT logging process data, and energy infrastructure sensors transmitting operational data all produce information with confidentiality requirements extending well into the threat window.

Timeline illustration showing iot devices transmitting sensitive data in 2026 that is harvested by adversaries and held for quantum decryption in the 2036–2046 crqc window, while the device itself is retired in 2034 — demonstrating that data confidentiality risk outlasts the device lifecycle. — The HNDL threat targets data at the moment of transmission, not at device retirement. IoT devices generating sensitive data in 2026 require PQC protection today — regardless of when the hardware is replaced.

Solution: Classify IoT devices by the confidentiality lifetime of the data they generate, not by the device’s own expected operational lifespan. Devices generating long-lived sensitive data require PQC protection for that data, regardless of when the device itself will be replaced.

Objection: ML-DSA signing on constrained hardware is too slow for real-time IoT applications — high signing latency variance makes post-quantum signatures impractical.

Discussion: The March 2026 benchmark correctly identified high signing latency variance as a real constraint for ML-DSA on the Cortex-M0+ — 99th-percentile signing latencies of approximately 1,100 ms for ML-DSA-87 are genuinely impractical for many real-time IoT applications [1].

However, the benchmark data also shows that ML-KEM key exchange on the same hardware is fast and energy-efficient. For constrained devices, the correct approach is to prioritize ML-KEM key exchange deployment (which is immediately practical) and evaluate signature requirements separately — using hardware-accelerated ML-DSA in secure elements, SLH-DSA for infrequent signing operations, or network-layer authentication in place of per-packet signatures.

Iot microcontroller cross-section showing ml-kem key exchange as a fast viable pathway and ml-dsa software signing flagged with high latency, branching into three practical alternatives: hardware-accelerated secure elements, slh-dsa for infrequent use, and network-layer gateway authentication. — ML-KEM key exchange is immediately practical on constrained IoT hardware and delivers the primary HNDL risk reduction. ML-DSA signature migration requires separate evaluation — hardware secure elements or gateway authentication resolve the latency constraint.

Solution: Decouple the key exchange and signature migration decisions. Deploy ML-KEM first on all Class 1+ devices — this provides the primary HNDL risk reduction. Evaluate ML-DSA alternatives (SLH-DSA, hardware-accelerated secure elements) for signature use cases where Cortex-M0+ software signing is too slow.

Objection: Billions of legacy IoT devices cannot be updated — the installed base is simply too large and too fragmented to migrate.

Discussion: The scale of the unmigratable installed base is a genuine operational reality — Class 0 devices with hardcoded cryptography cannot be software-updated for PQC, and there are billions of them in the field. The appropriate organizational response is not to defer migration planning but to establish a clear-eyed categorization of what can and cannot be migrated by software.

Devices that cannot run PQC should be identified in the CBOM, their data classified by sensitivity, and a hardware replacement schedule established as part of the device lifecycle plan. The 2030 EU CRA requirement for PQC upgrade paths in new products means the installed base problem will not compound into new deployments if manufacturers comply.

Infrastructure illustration showing billions of class 0 legacy iot devices protected by a pqc gateway compensating control at the perimeter, a cbom registry tracking replacement schedules, and new pqc-upgradeable devices entering production. — Class 0 devices require hardware replacement — accept that reality and plan accordingly. Gateway-based PQC compensating controls protect the legacy installed base while CBOM-driven replacement schedules and mandatory PQC procurement criteria prevent the problem from compounding.

Solution: Accept that Class 0 devices require hardware replacement and plan accordingly. Apply gateway-based PQC as a compensating control for legacy devices pending replacement. Require PQC firmware upgradeability as a mandatory procurement criterion for all new IoT device acquisitions beginning in 2026.

Objection: The EU Cyber Resilience Act and other regulations are future obligations — there is no legal requirement to act on quantum-safe IoT devices in 2026.

Discussion: This framing misreads both the timeline and the nature of the compliance obligation. The CRA’s December 2027 application date means that devices designed and manufactured in 2026 — with a development cycle of 12–18 months — are the devices that will face CRA scrutiny at product launch. Designing for CRA compliance in 2026 is not early; it is the correct product development timeline. NIS2, as amended by COM(2026) 13, requires PQC transition policies in national cybersecurity strategies that apply to regulated entities now, not at a future compliance date.

The EU Coordinated PQC Roadmap requires pilots for high-risk IoT by the end of 2026. Organizations in energy, healthcare, telecoms, and critical infrastructure already have legal exposure for failing to plan.[5]

Product development gantt chart showing that devices designed in 2026 launch into the eu cra's december 2027 application window, alongside nis2 and eu pqc roadmap obligations already active for regulated sectors in 2026. — The EU CRA’s December 2027 application date means devices being designed in 2026 face CRA scrutiny at launch. For regulated sectors under NIS2 and the EU PQC Roadmap, 2026 pilot obligations are active now — compliance planning cannot wait for a future deadline.

Solution: Begin IoT PQC planning in 2026 to meet the CRA’s product launch window. Regulated sectors (NIS2, DORA) should treat the 2026 EU roadmap milestone as an operational deadline, not a planning horizon. Require firmware-upgradeable PQC in all new device RFPs and procurement specifications immediately.

Knowledge Assessment: Is Your IoT Fleet Quantum-Ready?

⚠ Disclaimer: This quiz is for self-awareness only and does not constitute a professional assessment.

Q1: Benchmark data from March 2026 shows that ML-KEM-512 on an ARM Cortex-M0+ processor (RP2040, 133 MHz) completes a full key exchange in 35.7 ms, consuming 2.83 mJ. How does this compare to ECDH P-256 on the same hardware?

A) ML-KEM-512 is slower and uses more energy than ECDH P-256 — the classical algorithm remains the practical choice for constrained devices
B) ML-KEM-512 is 17x faster and uses 94% less energy than ECDH P-256 on the same hardware
C) ML-KEM-512 and ECDH P-256 perform equivalently on constrained hardware — the choice is determined by key size requirements only
D) ML-KEM-512 is faster than ECDH P-256 but consumes significantly more energy, making it unsuitable for battery-powered devices

Q2: An organization manufactures IoT sensors sold in the EU. Under which regulation must products released after December 2027 include a quantum-safe firmware upgrade path?

A) NIST IR 8547 — which applies to all IoT devices sold globally after August 2024
B) EU Cyber Resilience Act — which requires internet-connected products to include quantum-safe upgrade capability for CE marking
C) CNSA 2.0 — which mandates ML-KEM and ML-DSA for all commercial IoT devices from January 2027
D) NIS2 Directive — which directly mandates quantum-safe firmware for all consumer IoT products sold in the EU

Q3: An RFC 7228 Class 0 IoT device has fewer than 10 KB of RAM and cannot run any software PQC implementation. What is the correct migration strategy?

A) Deploy SLH-DSA instead of ML-KEM — hash-based signatures have much smaller memory requirements
B) Use a classical pre-shared key as a temporary measure — PSKs provide full quantum resistance for constrained devices
C) Classify as Level 0 in the CBOM, plan hardware replacement in the device lifecycle budget, and mitigate via a PQC-capable gateway that handles key exchange on the device’s behalf
D) Deploy ML-KEM-512 with compression — the algorithm can be made to fit within 10 KB of RAM with appropriate optimization

Score Interpretation:

All correct (B, B, C): Strong IoT PQC knowledge. Apply the device classification matrix in Table 1 to audit your fleet and assign migration paths by device class.
Mostly correct: Review the benchmark data in Table 2 and the Class 0 migration strategy — the distinction between Class 0 (hardware replacement) and Class 1–2 (software PQC feasible) is the most critical operational decision.
Incorrect: Return to the device classification section and the benchmark data before planning any IoT PQC deployment program.

FAQ

Q1: Can low-cost ARM Cortex-M0+ IoT devices actually run post-quantum cryptography?

A: Yes. Peer-reviewed benchmark data published in March 2026 demonstrates that ML-KEM-512 completes a full key exchange in 35.7 ms, consuming 2.83 mJ on an ARM Cortex-M0+ at 133 MHz with 264 KB SRAM — 17 times faster and 94 percent less energy than ECDH P-256 on the same hardware. These results use PQClean reference C implementations without assembly optimization, meaning production deployments with optimized libraries will perform even better. The conclusion is that ML-KEM-512 is practical on sub-$5 IoT processors today.

Q2: What is DTLS 1.3, and why is it important for IoT post-quantum deployment?

A: DTLS 1.3 (Datagram Transport Layer Security version 1.3) is the UDP-based equivalent of TLS 1.3, designed for IoT protocols that operate over UDP, such as MQTT-SN and CoAP. TLS 1.3 requires a reliable transport layer and is not suitable for lossy or delay-tolerant IoT network environments. DTLS 1.3 provides the same security properties as TLS 1.3 — including support for X25519MLKEM768 hybrid key exchange — over UDP, making it the correct protocol for post-quantum key exchange in constrained IoT networking environments.

Q3: What does the EU Cyber Resilience Act require for IoT devices in terms of post-quantum cryptography?

A: The EU Cyber Resilience Act, expected to apply from December 2027, requires that internet-connected products include a quantum-safe upgrade path as a condition of receiving CE marking. Products with hardcoded classical-only cryptography that cannot be firmware-updated to support post-quantum algorithms will not meet the state-of-the-art security requirements specified in the CRA. IoT manufacturers designing products in 2026 must architect for firmware-upgradeable PQC to ensure CRA compliance at product launch, given typical 12–18 month development cycles.

Q4: What is the gateway-based PQC approach, and when should it be used?

A: Gateway-based PQC places a PQC-capable intermediate node between constrained devices and the internet-facing network, handling quantum-safe key exchange on behalf of devices that cannot execute PQC themselves. The gateway uses ML-KEM hybrid TLS or DTLS 1.3 for all outbound connections while accepting classical cryptography from local constrained devices. This approach is primarily for Class 0 devices that cannot run software PQC and for legacy fleets awaiting hardware replacement. It provides HNDL protection for internet-facing traffic segments without requiring device-level PQC support.

Q5: Which PQC library should engineers use for Cortex-M4 IoT deployment?

A: The pqm4 framework provides assembly-optimized ML-KEM and ML-DSA implementations for the ARM Cortex-M4, achieving 2–4 ms encapsulation latency — suitable for most Class 2 IoT applications. The Linux Foundation’s PQCA mlkem-native and mldsa-native packages (released 2026) provide production-ready reference implementations that are algorithmically identical to PQClean but maintained for long-term production use as PQClean transitions to read-only status in mid-2026. wolfSSL also provides a PQC-enabled build with ML-KEM support suitable for DTLS 1.3 in embedded environments.

Q6: How should organizations classify their IoT fleet for PQC migration planning?

A: Organizations should classify their IoT fleet using the four-class framework derived from RFC 7228: Class 0 (below 10 KB RAM — hardware replacement required), Class 1 (up to 10 KB RAM — ML-KEM-512 via firmware update feasible), Class 2 (50+ KB RAM — ML-KEM-768 with DTLS 1.3 practical), and Class 3 (Linux-capable gateway class — full hybrid TLS deployment applicable). The classification should occur during Phase 1 of the migration roadmap (Cryptographic Inventory / CBOM creation), and the results should drive separate budget planning for each category — engineering budget for Class 1–3 firmware work and capital budget for Class 0 device replacement schedules.

PQC Series Overview

This article is part of the Post-Quantum Security Series — a technical collection of guides exploring cryptographic vulnerabilities exposed by quantum computing, migration strategies for organizations, and the steps required to protect sensitive data before quantum decryption becomes operationally viable.

→ View all Post-Quantum Security series articles here

References

[1] Chhetri, R. Benchmarking NIST-Standardised ML-KEM and ML-DSA on ARM Cortex-M0+: Performance, Memory, and Energy on the RP2040. arXiv:2603.19340. March 2026. https://arxiv.org/abs/2603.19340
[2] MDPI. Resilience of Post-Quantum Cryptography in Lightweight IoT Protocols: A Systematic Review. December 2025.
https://www.mdpi.com/2673-4117/6/12/346
[3] Springer Nature. Implementation and Performance of Post-Quantum Cryptography for Resource-Constrained Consumer Electronics. November 2025. https://link.springer.com/article/10.1007/s43926-025-00238-x
[4] IETF RFC 7228. Terminology for Constrained-Node Networks (Class 0, 1, 2 device profiles). https://datatracker.ietf.org/doc/html/rfc7228
[5] PQShield. The Cyber Resilience Act and Post-Quantum Cryptography. January 2026. https://pqshield.com/the-cyber-resilience-act-and-post-quantum-cryptography/
[6] EU Cyber Resilience Act. European Parliament and Council. Expected application: December 2027. https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
[7] European Commission. Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. June 2025. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
[8] European Commission. COM(2026) 13 — Proposed amendment to NIS2 Directive. January 2026. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2026:13:FIN
[9] NIST. IR 8547 — Transition to Post-Quantum Cryptography Standards. 2024. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf