An IETF LAKE working-group draft updated September 19, 2026 proposes quantum-resistant cipher suites for the Lightweight Authenticated Key Exchange protocol, previously known as EDHOC. The draft specifies combinations using ML-KEM for key exchange and ML-DSA for signatures. It is a work in progress, not a published standard, and it may change or expire. Its most useful contribution today is the set of deployment questions it exposes for constrained devices.
LAKE is designed for environments where message size, memory, energy, and processing can be scarce. Those are exactly the environments where a routine “replace the algorithm” plan is least credible. The draft says ML-KEM and ML-DSA have significantly higher overhead than elliptic-curve algorithms and warns that the proposed suites may not be usable for some classes of constrained device because of larger signatures or KEM keys.
Standardized primitives do not settle device feasibility
The proposal maps NIST-standardized algorithms into a concrete protocol flow. In its KEM exchange, the initiator creates a new encapsulation and decapsulation key pair for each session, sends the encapsulation key, and receives a KEM ciphertext from the responder. The draft lists ML-KEM ciphertext sizes from 768 bytes for ML-KEM-512 to 1,568 bytes for ML-KEM-1024. Those values are only part of the complete protocol message, but they illustrate why packet budgets and fragmentation behavior matter.
A gateway with abundant memory and reliable power may handle the overhead easily. A battery-powered sensor, low-power radio, or legacy controller may not. Larger messages can create additional frames, retransmissions, latency, energy use, buffer pressure, and failure modes across lossy networks. Verification cost and temporary memory may matter as much as the stored key. Firmware size and the availability of a maintained cryptographic library add further constraints.
Organizations should therefore evaluate capability at the deployed hardware and protocol profile, not at the product-family level. Two devices sold under the same name may use different microcontrollers, firmware branches, radio stacks, or secure elements. A supplier’s roadmap for a new generation does not establish that the installed base can be upgraded.
The draft states an important assurance limit
The document is unusually direct about the distinction between secure primitives and a secure composed protocol. It notes that ML-KEM and ML-DSA have received analysis in the quantum random-oracle model, but says integrating them into the proposed cipher suites is not sufficient to claim overall post-quantum security for the relevant LAKE methods. Analysis of the full construction remains future work.
That caveat should shape product claims. “Uses ML-KEM” is evidence about one component. It is not proof of endpoint security, correct randomness, side-channel resistance, authentication continuity, downgrade prevention, implementation quality, or an end-to-end post-quantum property. The draft also discusses hybridization as a response to the possibility of a future classical attack on a PQC algorithm, which adds still more size and coordination considerations.
Build a device-level migration matrix
For each critical device class, teams should capture enough evidence to answer:
- What is deployed? Record hardware revision, processor, secure element, memory, firmware, bootloader, protocol stack, and cryptographic library.
- What can change? Identify signed-update support, update bandwidth, maintenance windows, vendor commitments, rollback, and end-of-support dates.
- What does PQC cost? Measure message sizes, fragmentation, RAM, flash, CPU time, energy, latency, failure rates, and key-generation behavior in realistic networks.
- What security property is claimed? Separate confidential key establishment, authentication, hybrid protection, and full protocol assurance.
- What is the fallback plan? Mark devices that need a gateway, compensating control, replacement, or retirement rather than an in-place algorithm update.
This matrix turns an abstract standards development into an actionable portfolio. It also prevents a pilot on capable lab hardware from being generalized to a heterogeneous field estate. For operational technology and long-lived IoT, the replacement path may require procurement and outage planning years before the cryptographic deadline.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record. Its loop of discovery, canonical inventory, evaluation, action, and proof can help teams relate algorithms and protocol observations to device models, firmware, owners, dependencies, test evidence, and migration decisions. Vista Core is source-available and includes discovery, inventory, compliance/PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista tracks and governs post-quantum migration; it does not rewrite device firmware, generate PQC keys, or perform every device migration. Selected-asset Active Scan is not indiscriminate network scanning and should be used only on approved assets. Vista is not a vulnerability scanner, and discovery gaps do not prove that cryptography or a device is absent. Learn more about Vista’s PQC operating model.
What to watch next
The draft has working-group status but no completed IETF publication or final interoperability profile. Algorithm identifiers, registry changes, security analysis, and implementation experience may evolve. Operators can use its current sizes and caveats to design tests, but should verify the exact version and resulting RFC status before building procurement requirements around it.
Sources
- Quantum-Resistant Cipher Suites for LAKE, IETF LAKE Working Group, September 19, 2026 (work in progress).
- RFC 9528: Ephemeral Diffie-Hellman Over COSE (EDHOC), IETF, March 2024.