IoT and IETF PQ-EDHOC, from where I sit.

Why EDHOC at all, why not just PQ-TLS

TLS 1.3 hybrid PQC is the right answer for browsers, cloud, enterprise. For a constrained IoT device with single-digit kilobytes of RAM, no flash to spare, and battery budgets in the milliwatts, TLS is too heavy. The handshake itself does not fit, the cert chains do not fit, the cipher suites do not fit.

EDHOC was IETF's answer for that audience. Three messages. CBOR-encoded. Produces an OSCORE security context for end-to-end CoAP protection. Fits within the 1280-byte IPv6 minimum MTU. PQ-EDHOC carries that property over to the post-quantum world.

The 1280-byte constraint

Three messages. Total budget around 3 to 4 KB realistic. Kyber-512 public key is 800 bytes, Kyber-768 is 1184. Dilithium-2 signatures are 2420 bytes. The arithmetic is uncomfortable but workable. The design tradeoff is between aggressive parameter selection (Kyber-512 + Dilithium-2) and conservative (Kyber-768 + Dilithium-3), with hybrid-classical fallbacks for transition.

What our Arduino-class implementation achieved

The first peer-reviewed FIPS 203/204 implementation on ATmega328P (2 KB SRAM, the kind of chip in field metering and basic embedded sensors). Concrete numbers from the work:

• 136 ms ML-DSA signing latency on the constrained target
• 1850 TPS throughput on the gateway side of a permissioned blockchain anchoring workflow
• End-to-end <300 ms sense-to-ledger latency including PQC handshake
• Per-node deployable hardware cost <$50 on commodity Arduino + ESP8266 + sensor

This addresses the NSA CNSA 2.0 mandate for PQC adoption in critical infrastructure embedded systems. See the research deep-dive for full methodology.

Where oneM2M, CoAP, and MQTT fit

EDHOC sits below the application layer. Above it:

• OSCORE protects CoAP messages end-to-end using the EDHOC-derived key context. This is what you actually deploy.
• CoAP is the lightweight RESTful protocol for constrained devices. UDP-based.
• MQTT is the publish-subscribe alternative. Wider adoption in industrial broker-based topologies but heavier than CoAP.
• oneM2M is the global M2M / IoT interoperability standard. My IEEE DSIT 2024 paper shipped the first sub-64-MB native C implementation of oneM2M v5.1, a 17x reduction over Java/Python reference stacks. See the research deep-dive.

The full quantum-resilient IoT stack is therefore PQ-EDHOC at the key-exchange layer, OSCORE at the message-protection layer, CoAP or MQTT at the transport layer, and oneM2M (or vendor-specific) at the application layer. Each layer migrates on its own schedule.

The IETF LAKE Working Group

I contribute to the PQ-EDHOC Design Team alongside researchers from Ericsson, MIT Lincoln Laboratory, INRIA, ISI Athens, University of Murcia, IIT Delhi, and University of Limoges. The group meets at IETF. Drafts are public on the LAKE working group page.

Migration sequencing for IoT operators

1. Inventory, every device, every cert, every long-lived key, every firmware image. The thing you cannot migrate is the thing you do not know about.
2. Identify the long-lived secrets, anything with a 10+ year confidentiality requirement is at risk under harvest-now-decrypt-later. Treat as already harvested.
3. Plan HSM replacement, RSA-sized HSMs do not fit Dilithium. New procurement cycle.
4. Pilot hybrid first, classical + Kyber on the highest-value links. Survives the failure mode where either primitive is broken.
5. Specify in next RFP, vendor-side firmware updates are slow. Get PQC into procurement language now so 2030 deliveries arrive PQ-ready.