Your Wi-Fi WPA3 network has a quantum problem. Here's the fix coming in IEEE 802.11bt.

Quantum computing rarely comes up in Wi-Fi architecture conversations. That’s a problem — the threat has a name, a mechanism, and a timeline. The IEEE is rapidly drafting 802.11bt to bring Post-Quantum Cryptography to Wi-Fi. The problem? The silicon vendors are completely silent.

The actual threat: not breaking your network, breaking your history

Current Wi-Fi security — WPA3 included — relies on public-key cryptography for key establishment. WPA3’s SAE handshake is built on Elliptic Curve Diffie-Hellman (ECDH). Its security rests on the hardness of the discrete logarithm problem on elliptic curves. Shor’s algorithm, running on a sufficiently capable quantum computer, solves this in polynomial time. That breaks the handshake retroactively.

The more immediate concern isn’t a quantum computer appearing tomorrow. It’s the “Harvest Now, Decrypt Later” (HNDL) attack: an adversary records encrypted Wi-Fi handshakes and traffic today, stores them cheaply, and waits for quantum hardware to mature. When that day comes — current risk-model estimates range from 2028 to 2035 — they decrypt everything they’ve already captured. Years of corporate Wi-Fi traffic, VPN credentials, authentication sessions.

A natural question: Can’t you just rotate your WPA3 password regularly?

No — and it’s worth understanding exactly why. Changing the password changes future handshakes, but it doesn’t un-expose the handshakes already recorded. More importantly, HNDL isn’t targeting the password itself. It’s targeting the ECDH key exchange material captured at connection time. The elliptic curve public keys exchanged during the SAE commit phase are what Shor’s algorithm attacks. Rotating the password generates new ECDH key exchanges — which are also being recorded and stored by the same adversary. You’re not ahead of the threat, you’re feeding it fresh material.

The NSA’s CNSA 2.0 roadmap (September 2022) sets concrete milestones for network equipment: support and prefer PQC algorithms by 2026, and exclusively use them by 2030. New NSS equipment acquisitions must be CNSA 2.0-compliant by default from January 2027. These aren’t aspirational; they are procurement mandates already affecting government contracts.

One observation worth noting in passing: WPA2-PSK, because it uses a pre-shared key directly in symmetric AES derivation and doesn’t perform public-key exchange over the air, isn’t vulnerable to Shor’s algorithm in the way WPA3’s SAE is. Not because WPA2 is better — it isn’t, and it lacks forward secrecy entirely — but because it skips the step that’s quantum-vulnerable. That said, WPA2-PSK with AES-128 (CCMP) is still weakened by Grover’s algorithm, which provides a quadratic speedup against symmetric ciphers and effectively halves key strength, reducing 128-bit AES to roughly 64 bits of post-quantum security — below any acceptable threshold. This is precisely why 802.11bt mandates GCMP-256 across all PQC profiles: even after Grover’s quadratic attack, 256-bit AES retains a full 128 bits of post-quantum symmetric security. The quantum threat touches both sides of the cryptographic stack; 802.11bt addresses both.

Why MLWE is quantum-resistant: the math that matters

This is the core concept, and it’s worth going a level deeper than most posts do.

ML-KEM (Module-Lattice Key Encapsulation Mechanism, NIST FIPS 203, formerly CRYSTALS-Kyber) is built on the Module Learning With Errors (MLWE) problem. To build a basic intuition for why this is quantum-safe, imagine a classic high school linear algebra problem. If you are given a clean system of equations, finding the hidden variables is easy using basic row reduction.

But what happens if you slightly alter every single answer in the system by adding a tiny, random piece of static or “noise”?

For a classical or quantum computer, that tiny bit of noise changes everything. Without it, the problem is simple algebra. With it, the clean mathematical structure is shattered, turning the calculation into an exponential nightmare.

This is the foundation of the Module Learning With Errors (MLWE) problem — same public matrix A on both sides of the exchange, but the noise term changes everything.

The LWE problem in plain terms: Take a secret vector s (this becomes your private key). Choose a random public matrix A. Compute b = A·s + e, where e is a small random noise vector drawn from a narrow Gaussian distribution. Now publish A and b. The problem: given only A and b, recover s.

If there were no noise term e, this would be ordinary linear algebra — solvable in O(n³) time by Gaussian elimination. A quantum computer offers no meaningful advantage over classical here; the speedup from Shor’s algorithm applies to problems with specific periodic algebraic structure, which a clean linear system has. But the noise destroys that structure completely.

With the noise, the best known classical algorithms use lattice reduction techniques — primarily the BKZ (Block Korkine-Zolotarev) algorithm and its variants. The complexity scales as 2^O(n), exponential in the dimension. Critically, the best known quantum algorithms for this problem — including quantum lattice sieving — improve only the constant factor inside that exponent, not the exponential scaling itself. The complexity remains 2^O(n) on both classical and quantum hardware. That’s the key insight: Shor’s algorithm doesn’t apply here because MLWE has no periodic structure to exploit. Grover’s algorithm gives a quadratic speedup on symmetric problems but still leaves MLWE exponential.

TL;DR: ECC hides secrets in the clean, repeating loops of a geometric curve (which Shor’s algorithm can untangle), while LWE buries secrets in a messy system of noisy polynomials that forces quantum computers into an endless geometric search.

Engineering efficiency: the “Module” in MLWE

Standard LWE is highly secure, but it is a bandwidth nightmare. The public matrix A would be so massive that sending a public key would choke a standard Wi-Fi handshake.

The “Module” in MLWE introduces algebraic structure over polynomial rings (specifically working modulo a cyclotomic polynomial). Instead of filling a massive matrix with individual random integers, MLWE uses a much smaller matrix filled with compact polynomials.

Multiplying these polynomials acts as a highly efficient cryptographic mixer. This allows for dramatically smaller key sizes while preserving the underlying lattice hardness argument. It is pure efficiency engineering: it shrinks an ML-KEM-1024 public key down to exactly 1568 bytes of serialized polynomial elements and a public seed, making the protocol practical for real-world wireless hardware.

The reality check

While ML-KEM’s lattice foundations are mathematically robust and have survived an intensive 8-year NIST global cryptanalysis competition, intellectual honesty requires an important caveat: MLWE has been studied heavily since roughly 2005, but it lacks the decades of adversarial scrutiny accumulated by RSA and ECC.

The cryptographic community tracks this vulnerability gap carefully. In 2022, a completely different NIST PQC candidate algorithm called SIKE was entirely broken by a classical computer using a novel mathematical attack. While ML-KEM has stood firm and behaves exactly as intended, it remains a newer mathematical assumption than the infrastructure it replaces.

Crucially, however, there is nothing “quantum” about running the code. ML-KEM keys are generated, transmitted, and processed entirely on classical silicon. The term post-quantum does not mean quantum-powered — it means quantum-resistant. It ensures that an adversary armed with a fault-tolerant, cryptographically-relevant quantum computer tomorrow still cannot break your handshakes efficiently today.

IEEE P802.11bt: the Wi-Fi response

802.11bt is a draft amendment adding PQC support to the Wi-Fi MAC layer. It is MAC-only by design — the threat is cryptographic, not radio-frequency. Draft D0.2 landed in March 2026; D0.3 is expected from the May 2026 session. An initial working group ballot is anticipated in 2026/2027.

The PAR was driven by Cisco, HPE, Huawei, Samsung, ZTE, and Commscope/Ruckus — a meaningful cross-section of the ecosystem. What’s conspicuously absent from active standards contribution: Qualcomm, Broadcom, MediaTek, and Intel — the silicon vendors whose chipsets will ultimately have to implement this. ML-KEM operations are more compute-intensive than ECC, and on power-constrained clients, software-only ML-KEM may be too slow or too power-hungry for seamless handshakes. The standard can be written without the silicon vendors. It cannot be deployed at scale without them. Their silence is the most important signal in the room.

What 802.11bt actually defines

Two new AKMs: One for PQC 802.1X (non-FT) and one for PQC 802.1X with Fast BSS Transition. Both mandate GCMP-256 and require IEEE 802.1X Authentication Utilizing Authentication Frame Support in RSNXE. This last requirement is not incidental — it is specifically necessary to accommodate the large ML-KEM public key payloads (up to 1568 bytes) in the authentication exchange without hitting traditional EAPOL-Key frame size limits, which were never designed for post-quantum key material.

Three PQC profiles pairing ML-KEM variants with hash algorithms and optional classical ECC:

• Profile 0: ML-KEM-1024 + SHA-512, no ECC (pure PQC)
• Profile 1: ML-KEM-768 + SHA-384 + NIST P-384 (Group 20, hybrid)
• Profile 2: ML-KEM-1024 + SHA-512 + NIST P-521 (Group 21, hybrid, maximum security)

The hybrid profiles are intentional defense-in-depth: even if ML-KEM is someday broken, the classical ECC component still holds, and vice versa. This is the cryptographic equivalent of belt-and-suspenders during a transition era.

A new PTK derivation formula using HKDF (RFC 5869) that binds the session key to both the ML-KEM shared secret and a transcript hash of the authentication frame exchange — providing integrity over the full handshake sequence, not just the key material.

Proof of Work DoS mitigation — an interesting addition. ML-KEM operations are expensive enough that an AP could be denial-of-service attacked by flooding it with spoofed-MAC PQC auth attempts. The solution is exactly the mechanism Bitcoin originally used for Sybil resistance, and that early Ethereum used before its proof-of-stake transition: require the prover to find a value where Hash(challenge || solution) has a required number of leading zero bits. The verifier checks in one hash; the prover iterates exponentially with difficulty. When an AP’s concurrent PQC instance count exceeds a threshold, it issues a POW_REQUIRED challenge before doing any expensive ML-KEM work. What’s not defined: what difficulty setting is appropriate, or how an operator should tune it. High difficulty protects the AP but punishes legitimate battery-powered IoT clients. The spec leaves this entirely to the operator.

What D0.2 doesn’t yet show. The 802.11bt PAR has a broader mandate than the current draft reflects. It explicitly authorises four items: new PQC AKMs, PQC digital signatures, PQC key establishment algorithms, and — significantly — a password-authenticated key exchange that uses PQC (PQC-PAKE). That last item is the eventual replacement path for WPA3-SAE’s ECDH-based exchange. D0.2 focused on the enterprise 802.1X AKMs first; the PQC-PAKE and digital signature work appears queued for later drafts. The academic literature has candidate constructions — lattice-based PAKEs built on LWE/MLWE hardness — but none has received the same level of community review as ML-KEM. The path for quantum-safe WPA3-Personal exists inside 802.11bt’s own mandate; the work simply hasn’t started in earnest yet.

The EU Cyber Resilience Act adds a regulatory layer. The CRA (Regulation (EU) 2024/2847) entered into force in December 2024 and fully applies from late Q3 / early Q4 2027 — the exact date follows the 36-month enforcement window from its entry into force, landing around September–October 2027. It covers all products with digital elements sold in the EU market — which includes Wi-Fi APs, IoT devices, routers, and the firmware running on them. Key provisions: mandatory security-by-design, “state-of-the-art” cryptography requirements (explicitly referencing PQC readiness), SBOM requirements, and active vulnerability reporting obligations from September 2026 onward. For Wi-Fi vendors, this lands alongside the Radio Equipment Directive (RED), which has had cybersecurity requirements applying since August 2025. The intersection is sharp: a Wi-Fi AP sold in Europe from late 2027 onward needs to demonstrate cryptographic currency. If 802.11bt isn’t ratified and shipping by then — which it won’t be — what does “state-of-the-art cryptography” mean for a Wi-Fi device under CRA? That question currently has no clean answer, and it’s a compliance gap that will affect every major AP vendor with EU sales.

WPA3-Personal’s quantum path is slow. 802.11bt’s PAR explicitly includes a PQC-PAKE — a post-quantum password-authenticated key exchange to eventually replace SAE — but D0.2 contains no draft text for it. The enterprise 802.1X AKMs came first. SAE, OWE, and FILS replacements are authorised within the same amendment but are the least developed items on the task group’s agenda. Until that work matures, home and SMB networks with WPA3-Personal remain quantum-vulnerable. The path exists; the timeline does not.

Silicon commitment is the gating factor. No chipset vendor has publicly committed to ML-KEM acceleration on a timeline. Until Qualcomm or Broadcom publishes a roadmap for Wi-Fi SoCs with hardware PQC support, enterprise deployment timelines are speculative regardless of what the standard says.

The IoT stranding problem. 802.11bt changes the authentication flow, which requires updated supplicants everywhere — phones, laptops, IoT devices. An ML-KEM-1024 encapsulation key is exactly 1568 bytes; management frame sizes grow accordingly. For IoT devices on bespoke firmware with no update path, migration may be practically impossible. The installed base of WPA3-incapable enterprise devices is already a pain point; 802.11bt creates a harder version of the same problem.

The 2027 compliance gap. NSA CNSA 2.0 targets 2027 for PQC in network equipment. 802.11bt won’t be ratified by then, and certified products even later. How are federal and defense-adjacent organizations supposed to handle Wi-Fi under that mandate? Compensating controls? VPN overlay? Waivers? No one has addressed this publicly.

The timeline, honestly

D0.3 expected mid-2026. Working group ballot 2026/2027. Standard publication 2027/2028 at the optimistic end. Chip design cycles run 2–3 years after a stable spec. Driver and supplicant work in open-source stacks (hostap/wpa_supplicant, ZephyrRTOS) typically starts during late balloting. Certified enterprise APs with 802.11bt support: realistically 2028–2030.

That aligns uncomfortably with when cryptographically-relevant quantum computers enter serious risk models. There is no comfortable buffer. And unlike TLS or SSH, where PQC migration is already underway — Google shipped ML-KEM in Chrome for TLS 1.3 in 2024 — Wi-Fi has no early adopter running ahead of the spec.

Questions worth raising

A few threads I think the community should be pulling on:

1. When do silicon vendors publicly commit to ML-KEM acceleration in Wi-Fi chipsets? That’s the actual gating factor.
2. What is the right PoW difficulty curve for enterprise APs serving a mix of laptops and constrained IoT? Is borrowing from blockchain’s playbook even the right model for a real-time wireless handshake?
3. For IoT devices on Zephyr, FreeRTOS, or custom RTOS stacks — is there a realistic supplicant migration path, or is the deployed base effectively stranded?
4. How should enterprises close the gap between NSA’s 2027 mandate and 802.11bt availability? VPN overlay is the obvious interim answer, but it doesn’t protect the Wi-Fi layer itself.
5. The EU CRA requires “state-of-the-art cryptography” for products sold in the EU from December 2027. 802.11bt won’t be ratified by then. What does CRA compliance actually mean for a Wi-Fi AP vendor with EU sales — and who is going to answer that question?
6. 802.11bt’s PAR includes a PQC-PAKE to replace SAE, but D0.2 has no draft text for it. Will that work get the same rigour as ML-KEM, or will it arrive as an afterthought? And what does the WPA3-Personal migration path look like for the billions of devices that won’t wait for a new standard?

At Dotstar Systems, we work across the wireless firmware and protocol stack — from IEEE draft specs down to the wpa_supplicant commit and ZephyrRTOS Wi-Fi stack. If you’re working through PQC readiness for wireless infrastructure, IoT client migration, or stack-level implementation, we’d welcome the conversation.

References

Quantum algorithms

1. P. W. Shor, “Algorithms for Quantum Computation: Discrete Logarithms and Factoring,” Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), 1994, pp. 124–134. https://doi.org/10.1109/SFCS.1994.365700
2. L. K. Grover, “A Fast Quantum Mechanical Algorithm for Database Search,” Proceedings of the 28th Annual ACM Symposium on the Theory of Computing, 1996, pp. 212–219. https://arxiv.org/abs/quant-ph/9605043

PQC standards

1. NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), August 2024. https://csrc.nist.gov/pubs/fips/203/final
2. NIST, “NIST Releases First 3 Finalized Post-Quantum Encryption Standards,” August 2024. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

Key derivation

1. H. Krawczyk and P. Eronen, RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF), IETF, May 2010. https://www.rfc-editor.org/rfc/rfc5869.html

Policy and regulatory

1. NSA Cybersecurity Advisory, Announcing the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), September 2022. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
2. European Commission, Regulation (EU) 2024/2847 — Cyber Resilience Act, October 2024. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

IEEE 802.11bt

1. IEEE 802.11 Working Group, Task Group bt (Post-Quantum Cryptography) — Status and Documents, ongoing. https://www.ieee802.org/11/Reports/tgbt_update.htm
2. IEEE 802.11 Working Group, TGbt Public Document Archive, IEEE Mentor portal. https://mentor.ieee.org/802.11/documents
3. J.-C. Zuniga et al., IEEE P802.11bt Draft PAR: Enhancements for Post-Quantum Cryptography, IEEE 802.11-25/0597r4, May 2025.

---

PS: This article was drafted with AI assistance (Claude + Gemini) from raw technical notes and spec analysis. The opinions, observations, and questions are the author’s; the AI helped shape them into a coherent narrative.