Post-Quantum Cryptography Support in the Campus LAN

Executive summary

Post-quantum cryptography (PQC) should not be a distant concern for campus network teams.

The threat horizon has moved closer. Google Quantum AI's 2025 research cut the estimated qubits needed to break RSA-2048 by roughly an order of magnitude, and WWT assesses that a cryptographically relevant quantum computer (CRQC) could arrive as early as 2029, ahead of the U.S. government's 2035 planning horizon. Adversaries are already harvesting encrypted traffic today to decrypt once a CRQC is available. CNSA 2.0 sets a separate compliance clock for national security systems: New acquisitions must comply from January 1, 2027; networking equipment must use it exclusively by 2030; and full transition is targeted for 2035.

The window to act is now, and the campus LAN is not exempt.

This WWT Research Note examines why MACsec-enabled campus networks are exposed to quantum threats, despite using AES encryption, and what organizations can do about it. It covers the architecture of LAN MACsec and where the quantum vulnerability actually lives, a four-stage PQC maturity model to guide phased adoption, the technical and operational prerequisites for achieving full PQC protection, a practical migration path designed for brownfield environments and a time-horizoned readiness roadmap tied to the Q-Day timeline.

Readers will come away with:

• A clear understanding of why the 802.1X/EAP-TLS control plane is the quantum risk surface and not the MACsec data plane
• A framework for assessing where their infrastructure sits today and what it takes to move forward
• Actionable guidance on hybrid PQC deployment as the recommended near-term enterprise state
• A realistic migration path that maintains network availability throughout the transition
• A clear sense of timing: 2026 is the year to inventory, test and begin deploying. Not the year to start planning.

Who should read this note

This WWT Research Note serves two primary audiences:

1. IT security leaders and network architects responsible for PQC strategy will find the executive summary, threat vectors, maturity model summary, and Q-Day Readiness Roadmap most relevant.
2. Network engineers and PKI administrators who implement migration will find the most value in our practitioner deep dives, available in the MACsec architecture, PQC key types and prerequisites sections.

Why the LAN cannot be overlooked when preparing for Q‑Day

At first glance, worrying about PQC on a MACsec-enabled link seems counterintuitive. MACsec uses AES symmetric encryption, which is widely considered quantum resistant. The vulnerability, however, lies not in the data plane but in the control plane and key exchange mechanism.

Key threat vectors

Four threat vectors explain why the campus LAN cannot be excluded from PQC planning:

1. The key exchange vulnerability (MKA and 802.1X)

MACsec (IEEE 802.1AE) secures the link but relies on MACsec Key Agreement (MKA) to establish and rotate keys, which is tightly coupled to 802.1X port-based authentication. AES session keys are derived from the EAP-TLS authentication phase, which relies on X.509 certificates secured by RSA or ECC. Both are broken by Shor's algorithm on a CRQC. 

If a recorded 802.1X/EAP-TLS handshake is later cracked, the Master Session Key and resulting Secure Association Keys are exposed, and all associated MACsec-encrypted traffic becomes readable.

2. The "harvest now, decrypt later" (HNDL) threat

A threat actor who taps a campus link today can record both the encrypted MACsec traffic and the initial 802.1X/EAP-TLS handshake. Once a CRQC is available, they can crack the handshake's asymmetric encryption, extract the session keys and retroactively decrypt years of harvested internal traffic

While HNDL is typically associated with WAN traffic, it is a real threat inside the campus LAN for organizations handling sensitive data. Healthcare, government and financial environments are particularly exposed: these sectors share long data-retention requirements (years or decades), high sensitivity of data in transit and significant regulatory consequences for breach. Internal LAN traffic in these environments (patient records, financial transactions, government communications) has long-term value to an adversary, making it worth harvesting today and decrypting once a CRQC is available.

A crypto asset inventory will surface LAN MACsec as a cryptographic risk, flagging classical key exchange in 802.1X/EAP-TLS infrastructure as a weakness requiring migration. Organizations should begin this inventory now, before Q-Day planning forces reactive action.

3. Rogue device injection and NAC bypass

Modern NAC relies on device identity. If a CRQC can forge the RSA or ECC signatures underpinning your PKI, certificate-based authentication collapses. An attacker with forged certificates can plug a rogue device into any campus switch port, pass 802.1X authentication and gain trusted, encrypted MACsec access to segmented network resources. PQC ensures device identities and digital signatures remain mathematically unforgeable. 

4. Zero trust and defense in depth

Campus zero trust assumes the internal network is not inherently trusted. MACsec provides the link-level enforcement layer that makes this assumption enforceable. Moreover, physical access to LAN infrastructure is a real threat vector. Insider threats and compromised branch physical security are documented attack paths, not theoretical ones. Applying PQC at the MACsec layer ensures the cryptographic foundation of Zero Trust remains sound over the coming decade, not just today.

MACsec architecture: Where PQC fits

MACsec provides line-rate Layer 2 encryption and integrity for Ethernet frames, bootstrapped by 802.1X authentication and managed by MKA for session key derivation and rotation. Understanding where cryptography actually operates within this stack is essential to understanding where the quantum risk lies.

The data plane vs. the control plane

How PQC applies

PQC is introduced into the existing MACsec architecture by upgrading the EAP-TLS handshake. No changes are made to the MACsec data plane or the underlying AES encryption.

• TLS 1.3 introduces ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardized by NIST as FIPS 203 in August 2024, to generate quantum-resistant shared secrets. These are available in two enterprise-relevant security levels:
  • ML-KEM-768: The minimum recommended level and a strong practical baseline for most enterprise LAN deployments. Its public key and ciphertext add roughly 2 KB to the handshake.
  • ML-KEM-1024: A higher security margin at roughly 3 KB on the wire. The added cost is message size, not compute, since ML-KEM adds only microseconds per handshake at either level. For most enterprise use cases, the security return over ML-KEM-768 does not justify the extra bytes.
• Two fallback paths exist. A TLS 1.3 peer that lacks ML-KEM negotiates a classical key exchange such as X25519 inside TLS 1.3. A legacy device that cannot run TLS 1.3 drops to TLS 1.2, which carries no PQC at all. WWT's ATC trial exercised both.
• The handshake operates in one of two modes:
  • First, a hybrid mode negotiates two independent keys simultaneously: one classical (e.g., X25519) and one post-quantum (e.g., ML-KEM-768), combined into a single composite key (e.g., X25519MLKEM768). The PQC path is attempted first. If the peer does not support it, the session re-negotiates using the classical fallback. This is the recommended approach during transition periods.
  • Second, a PQC-only mode accepts no classical fallback. All sessions must use quantum-safe keys.
• The resulting MACsec session keys distributed via MKA inherit the quantum-resistant properties of the TLS 1.3 handshake.
• The underlying MACsec encryption remains AES.

Performance and overhead     

The cost of PQC in EAP-TLS is bandwidth, not compute. ML-KEM adds only microseconds per handshake, but it adds bytes on the wire — about 2 KB for ML-KEM-768 and 3 KB for ML-KEM-1024. The larger factor arrives with PQC certificates. Once identities move to ML-DSA signatures, those signatures run 3 to 5 KB, roughly 30 to 70 times an ECDSA signature, which inflates the Certificate and CertificateVerify messages. Over 802.1X this can push the EAP-TLS exchange past a single frame and trigger fragmentation and extra round trips. Test handshake completion on access ports with realistic certificate chains, not just key exchange. The data plane is unaffected, since MACsec continues to encrypt frames with AES at line rate.

What this means for your organization

Upgrading to PQC does not require replacing or reconfiguring your MACsec data plane. The work is in the authentication and key exchange layer: primarily the RADIUS infrastructure, endpoint supplicants and PKI. Not the switching hardware. If your switches support TLS 1.3 and your RADIUS and CA infrastructure can be updated, the path to PQC-Protected MACsec is a configuration and certificate management exercise, not a forklift upgrade.

The four PQC key types

Before defining maturity levels, it helps to understand the four distinct key types that exist in a PQC migration context. These apply across all PQC-Capable protocols, including MACsec via EAP-TLS 1.3, and give organizations a common language for assessing their current state and defining a migration target.

*Sources: IETF draft-ietf-tls-hybrid-design and  draft-ietf-tls-ecdhe-mlkem
 

What this means for your organization

Most enterprises are still running legacy key exchanges. Hybrid mode is the recommended migration vehicle. It introduces quantum resistance without breaking compatibility with devices that have not yet been upgraded. Pure PQC is the target end state, but reaching it requires complete ecosystem readiness. The maturity model in the next section shows where each key type fits in the migration and which to target first.

PQC maturity levels for MACsec

Organizations can assess their current state and plan migration using a four-stage maturity model. Each stage describes a device's PQC capability, its operational behavior and the security posture it delivers.

Maturity level summary

Examining each level of PQC maturity

Level 1: PQC-Capable

Hardware and software support post-quantum algorithms, but this does not mean PQC is in use. A PQC-Capable device may still be operating in a purely classical mode until explicitly configured otherwise, and many are.

• A "PQC-Capable" switch or router has TLS 1.3 with ML-KEM in its software stack and sufficient hardware acceleration.
• Without explicit configuration, it operates in classical mode.

Note: "Capable" is not the same as "protected." Configuration and policy determine whether PQC is actually used, not hardware spec sheets.

Level 2: PQC-Ready

A PQC-Ready device is configured to negotiate PQC with peers that support it, while still accepting classical connections for backward compatibility. This is the entry point for real PQC deployment without requiring a hard cutover.

• TLS 1.3 is enabled and the device is configured to negotiate hybrid or PQC-only key exchange modes.
• Performs a post-quantum key exchange when the peer supports it and falls back to classical ECDH when not.
• PQC is introduced link by link without breaking compatibility with legacy devices.

Level 3: PQC-Safe (recommended near-term state)

At this stage, PQC is broadly enabled and preferred by default, but a controlled classical fallback persists as a safety net. This is the most realistic state for most enterprises during the transition period and where the bulk of the migration work happens.

• Uses a hybrid EAP-TLS 1.3 handshake. If both sides support ML-KEM, they use it. If not, they negotiate classically.
• Quantum-resistant keys are used whenever possible while maintaining interoperability with older devices.
• Security teams should monitor which sessions use PQC vs. falling back and work to reduce the latter over time.
• Vendor interoperability for hybrid keys requires explicit lab testing. Standards for hybrid key negotiation are still maturing and interoperability between different vendors' implementations is not guaranteed. Do not assume it works across your environment without validating it first.
  • To see what lab validation looks like, read how WWT validated hybrid EAP-TLS 1.3 with ML-KEM on the Cisco 8000 Series in our Advanced Technology Center (ATC), including the fallback path for non-PQC peers.

Note: Most enterprises will spend considerable time in PQC-Safe mode. That is expected and by design.

Level 4: PQC-Protected

PQC-Protected is the target end-state. Post-quantum key exchange is mandatory, enforced by policy and there is no classical fallback. Getting here requires complete ecosystem readiness across every device, server and PKI component on the network. Rushing this step is the most common cause of widespread authentication failures.

• Configured to enforce PQC-only key exchange with no classical fallback.
• TLS 1.3 handshake refuses to proceed without a PQC algorithm.
• Non-PQC endpoints and/or peers fail 802.1X authentication and are denied network access.

Requirements before enforcing this level:

• Every connected supplicant, network device and authentication server must support TLS 1.3/PQC.
• PKI infrastructure (RADIUS/CA) must be PQC-compatible.
• Any single non-upgraded component will cause denied connections.

Prerequisites for achieving PQC-Protected MACsec

Reaching PQC-Protected status is not simply a configuration change. Both the technical infrastructure and the operational processes supporting it must be fully prepared. In most organizations, PKI readiness will be the bottleneck rather than the switching infrastructure. Root CA rotation, issuing CA upgrades, OCSP/CRL infrastructure updates and certificate lifecycle tooling may all need to change before PQC-compatible certificates can be issued at scale. PKI modernization is frequently a multi-year program in its own right. PKI readiness assessment should run alongside network device inventory, not after it.

Technical prerequisites

Operational prerequisites

Even with the right hardware and software in place, operational readiness determines whether a PQC deployment succeeds. The following areas require deliberate attention before enforcement mode is enabled:

• Robust certificate management: RADIUS/EAP servers must trust new root CA certificates and devices must have valid client certificates.
• Cryptographic mode visibility: NAC systems should log whether a given MACsec session used a PQC handshake or fell back to classical. Without this visibility, there is no way to measure progress or diagnose issues.
• Fallback and failure monitoring: Authentication fallback or failure events indicate misconfigurations or unsupported devices. These should be treated as actionable signals, not background noise.
• Change management discipline: Moving from "PQC allowed" to "PQC required" should be done gradually. Any TLS version or policy mismatch between switch and client will result in authentication failure, and the blast radius can be significant if the change is made broadly before readiness is confirmed.

Transition & fallback considerations

Campus networks are almost always brownfield environments. A complete cut-over to PQC is not instantaneous, and there will be an extended period where some links and devices are upgraded while others are not. The EAP-TLS 1.3 + PQC implementation in MACsec is explicitly designed for this reality, allowing organizations to tighten policy incrementally as readiness improves.

WWT validated this behavior in practice. In a Cisco early field trial run in WWT's Advanced Technology Center, engineers confirmed MACsec encryption using ML-KEM via EAP-TLS 1.3 on the Cisco 8000 Series, with fallback to TLS 1.2 for devices that do not support PQC. ML-KEM was negotiated whenever both peers supported it, and sessions with non-PQC peers kept running on classical algorithms. Migration proceeded device by device without disrupting live operations.

Recommended migration path

Campus networks are brownfield, so migration runs as four phases rather than a single cutover. Each phase moves a device or segment to the next maturity level, and you can enter at whichever phase matches your current state.

• Phase 1 - Inventory and assess: Establishes a PQC-Capable baseline.
• Phase 2 - Enable and test: Reaches PQC-Ready on pilot ports in a lab or staging environment.
• Phase 3 - Expand and monitor: Brings the campus to PQC-Safe, the recommended near-term state.
• Phase 4 - Enforce: Reaches PQC-Protected on segments where readiness is confirmed.

The next section maps these phases to the WWT PQC journey and roadmap horizons. The specific actions for each phase, sequenced by time, are in the Q-Day Readiness Roadmap section later in this note.

Mapping the PQC migration path to our PQC Readiness Roadmap

This note's maturity model describes where a device or link sits today. WWT's PQC customer journey, Assess, Design, Validate and Deploy, describes the engagement that moves it forward. The table below ties the two together, along with the migration phases and roadmap horizons used in this note

Key design principles

The fallback and failure behaviors built into EAP-TLS 1.3 + PQC are intentional. They make incremental migration operationally safe and give teams clear signals when something needs attention.

• Fallback is a feature, not a bug: It is a risk management tool for incremental migration. Administrators control fallback behavior through policy and tighten it progressively as deployment matures.
• Failures are predictable and contained: When there is a misconfiguration or non-compliant endpoint, 802.1X fails closed rather than silently downgrading. "Link Secure Failure" events give ops teams a clear signal rather than an undetected cryptographic regression.
• There are no silent downgrades: The device logs will indicate when a fallback to TLS 1.2 or non-PQC algorithms has occurred. If it happens, you will know.

Q‑Day Readiness Roadmap

Q-Day is projected around 2029 to 2030, but organizations should target readiness by 2027. Full-scale PQC migration across a campus environment takes years, and 2026 is the window to establish your strategy, complete crypto asset inventories and begin lab testing. The actions below sequence the four migration phases by time horizon to help teams prioritize their efforts.

If you are currently at PQC-Capable or PQC-Ready (maturity levels 1 or 2), the Immediate actions below are your starting point. If you are PQC-Safe (level 3) with hybrid mode broadly deployed, focus on the Mid-term actions to expand coverage and tighten policy. The Long-term actions are for when your environment is ready to enforce PQC-Protected (level 4) mode campus-wide.

Immediate (now to 12 months)

• Conduct a crypto asset inventory to identify all campus devices, links and services using classical key exchange in 802.1X/EAP-TLS.
• Identify hardware requiring firmware or software upgrades for TLS 1.3 and ML-KEM capability.
• Audit PKI infrastructure to confirm RADIUS/CA components can support PQC-compatible certificates.
• Begin piloting PQC-Safe (hybrid) mode on select switch ports in a lab or staging environment.
• Align networking, security and PKI teams on a shared roadmap and budget plan.

Mid-term (1 to 3 years)

• Roll out TLS 1.3 + hybrid PQC across campus access and distribution layers.
• Enable cryptographic mode logging in NAC to track PQC vs. classical session ratios.
• Validate hybrid key interoperability across all vendor device types in staging before production rollout.
• Progressively tighten policies as device upgrade coverage increases.
• Retire or isolate legacy endpoints that cannot support TLS 1.3.

Long-term (3 to 5 years/pre-Q-day)

• Enforce PQC-Protected mode on all campus segments where readiness is confirmed
• Confirm 100% of connected devices, RADIUS servers and PKI components are PQC-Capable
• Validate that no classical crypto fallback is occurring on critical network segments
• Maintain monitoring for newly onboarded legacy devices that could reintroduce classical sessions

Campus LAN and WAN PQC planning should be coordinated

The PKI infrastructure changes required for LAN MACsec are the same as those needed for WAN IPsec and TLS: root CA upgrades, issuing CA modernization and certificate lifecycle tooling. Running these programs independently creates duplicated effort and inconsistent timelines. See the companion WWT Research Note on WAN PQC for parallel planning guidance and to understand where LAN and WAN migration efforts can share resources. For the enterprise-wide migration strategy this fits within, see WWT's research note Accelerate Your Migration to Quantum-Safe Cryptography.

Key takeaway

For LAN environments, post-quantum security is not about encrypting frames differently. It is about ensuring that device identity, authentication and key establishment can survive a post-quantum world without breaking the network.

The investments required to get there also improve classical security hygiene along the way: TLS 1.3 adoption, PKI modernization and cryptographic asset visibility all pay off before Q-Day arrives. 

Organizations that treat PQC migration as a cybersecurity program, not a future-dated compliance checkbox, will find that each step pays off before Q-Day. For organizations subject to FIPS, CMMC, HIPAA or equivalent regulatory frameworks, migration is not optional; the question is only one of sequencing and timing.