Is Your Enterprise WiFi Ready for Post-Quantum Cryptography?

Nobody has publicly demonstrated a quantum computer that can break modern encryption. And yet the migration away from quantum-vulnerable cryptography is already one of the fastest infrastructure shifts the internet has seen - your browser almost certainly negotiates quantum-resistant key exchange today, and Cloudflare reports that the majority of TLS-protected traffic reaching its network already uses it. Meanwhile the RSA and elliptic-curve cryptography underpinning enterprise WiFi - every EAP-TLS handshake, every RADIUS server certificate, every device credential - now has an official retirement schedule.

This is not a panic piece. Nothing in your WLAN needs replacing this quarter, and WiFi will not be the first thing a quantum computer attacks. But authentication infrastructure turns over slowly, certificates live in thousands of devices, and the deadlines are closer than a typical hardware refresh cycle. Here's what is actually happening, which parts of your WiFi stack are exposed, and the moves that make the transition boring instead of brutal.

Why Worry About a Computer That Doesn't Exist Yet?

The threat has a name: harvest now, decrypt later. Public-key algorithms like RSA and elliptic-curve Diffie-Hellman are safe against every classical computer on Earth, but a sufficiently large quantum computer running Shor's algorithm would solve their underlying math efficiently. An adversary doesn't need that computer today - they only need to record your encrypted traffic today and store it until the hardware exists.

That changes the risk calculation for any data with a long confidentiality lifetime. Patient records, financial data, government correspondence, intellectual property, and credentials stay sensitive for a decade or more. If they cross a network whose key exchange is quantum-vulnerable, a packet capture made in 2026 becomes a disclosure whenever the decryption capability arrives - retroactively, with no breach alert.

What Did NIST Standardize, and What Are the Deadlines?

In August 2024, NIST finalized its first three post-quantum standards after a public competition that ran for eight years:

• FIPS 203 (ML-KEM) - a key encapsulation mechanism derived from CRYSTALS-Kyber; the designated workhorse for key exchange
• FIPS 204 (ML-DSA) - a digital signature algorithm derived from CRYSTALS-Dilithium; the likely future of certificate signatures
• FIPS 205 (SLH-DSA) - a conservative hash-based signature scheme derived from SPHINCS+, standardized as a backup

The deadlines followed quickly. NIST's draft transition roadmap, NIST IR 8547, marks quantum-vulnerable public-key algorithms at the 112-bit security level - including RSA-2048 and ECC P-256, the two you almost certainly use - as deprecated after 2030 and disallowed after 2035. For US national security systems the clock runs faster: under the NSA's CNSA 2.0 guidance, new acquisitions are expected to support quantum-resistant algorithms beginning in 2027. And the commercial internet is ahead of both - mainstream browsers and TLS stacks enabled a hybrid of classical X25519 and ML-KEM-768 by default across 2024 and 2025, which is why most web traffic is already protected without anyone noticing.

Which Parts of Your WiFi Stack Are Quantum-Vulnerable?

Not everything in a wireless network is equally exposed. Ranked roughly by urgency:

• The EAP-TLS key exchange - exposed now. An 802.1X authentication is a TLS handshake carried in EAP frames, and its elliptic-curve key agreement is precisely what harvest-now-decrypt-later targets. This is the part worth moving to hybrid post-quantum key exchange first, because today's handshakes are recordable today.
• Certificate signatures - exposed later. The RSA or ECDSA signatures on your RADIUS server certificate, client certificates, and CA chain can't be exploited retroactively; forging one requires the quantum computer to actually exist. They must migrate before that day, but after key exchange - which buys time for ML-DSA support to mature in CAs, operating systems, and supplicants.
• RADIUS transport - depends on you. Legacy RADIUS over UDP has weak cryptographic protections regardless of quantum computing. Carrying it inside TLS via RadSec means your authentication backhaul inherits TLS 1.3's post-quantum upgrade path instead of needing one of its own.
• The air encryption - mostly fine. The symmetric AES encryption protecting frames after authentication is comparatively resistant: Grover's algorithm roughly halves effective key strength, a theoretical dent in AES-128 and a comfortable margin for AES-256. This is one more argument for WPA3-Enterprise, whose 192-bit mode brings GCMP-256 to the air.

What Does Post-Quantum Actually Change for 802.1X?

Because EAP-TLS is TLS, enterprise WiFi inherits the TLS migration rather than inventing its own - good news, since that work is furthest along. The practical prerequisite is TLS 1.3: post-quantum key exchange is being deployed on 1.3's handshake, so RADIUS servers and supplicants still pinned to TLS 1.2 are a blocker to clear first.

The awkward part is size. Post-quantum key material is measured in kilobytes where classical material was measured in tens of bytes - an ML-KEM-768 public key is roughly 1.2 KB, and a single ML-DSA signature runs between two and five kilobytes depending on parameter set. A web server barely notices. EAP notices a lot: handshake messages must be fragmented across many RADIUS round trips, so early research on post-quantum WPA-Enterprise consistently flags added fragmentation and authentication latency as the cost to engineer around. Expect it at its most visible during morning onboarding storms and dense roaming, and expect vendors to compete on handling it well.

The realistic sequence for wireless mirrors the web: hybrid classical-plus-ML-KEM key exchange lands first through supplicant and RADIUS stack updates, and post-quantum certificates follow once CA and device support matures. The long tail will be the usual suspects - printers, badge readers, medical and industrial gear that authenticates with certificates but sees a firmware update once a presidency.

How Do You Build Crypto-Agility Into Your WiFi Now?

You can't buy "quantum-safe WiFi" today, and anyone selling it deserves skepticism. What you can do is make your network cheap to migrate - which happens to be the same work that makes it more secure right now:

• Inventory your cryptography. Which EAP methods are in use, what key types and lifetimes your certificates carry, which TLS versions your RADIUS servers and clients negotiate, and which devices can't do TLS 1.3. You can't schedule a migration you haven't measured.
• Move authentication to certificates - yes, really. It sounds backwards to invest in certificates that will themselves need re-issuing. But organizations that authenticate with certificate-based EAP-TLS under a managed PKI can swap algorithms through normal rotation; passwords and pre-shared keys offer no migration lever at all. Moving to WPA-Enterprise is step one of the post-quantum transition, not a detour from it.
• Automate enrollment so rotation is free. Short-lived certificates issued through SCEP and a managed cloud PKI turn an algorithm change into a re-enrollment cycle instead of a device-by-device redeployment. If replacing every credential on the network by hand sounds unthinkable, that - not the quantum computer - is the actual vulnerability.
• Modernize the RADIUS path. A managed cloud RADIUS service with RadSec and current TLS stacks means post-quantum key exchange arrives as a platform update on the server side, leaving client support as your remaining variable.
• Put it in your procurement questions. Every access point, controller, and client platform you buy from here forward outlives 2030. Ask vendors for TLS 1.3 support and a written post-quantum roadmap before the purchase, when your leverage is highest.

Conclusion

Post-quantum cryptography went from research topic to production reality in about two years: standards finalized, browsers migrated, and federal deadlines on the calendar. Enterprise WiFi sits earlier on the same curve - the protocols it depends on are being upgraded now, and the client ecosystem will follow at wireless speed, which is to say unevenly.

The teams that will struggle in 2030 are not the ones that skipped some exotic quantum product; they are the ones still running password authentication, hand-installed certificates, and RADIUS over bare UDP - networks with no mechanism for changing cryptography at all. The teams that will shrug are the ones for whom certificates already rotate automatically and transport security already rides TLS.

Quantum readiness for WiFi, it turns out, looks exactly like WiFi security best practice with a deadline attached. That deadline is now published. Plan the boring version.