The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab) are defined in the glossary.
Read this first
The IETF EMU working group published draft-ietf-emu-pqc-eap-tls-01 on 21 September 2026. It applies post-quantum cryptography to EAP-TLS, EAP-TTLS, PEAP and TEAP, and it treats large post-quantum certificate chains as an operational problem rather than an afterthought. This is a standards-track Internet-Draft, not an RFC, so teams should use it as migration evidence and test guidance, not as a final interoperability target.
Post-quantum TLS is usually discussed as a browser-to-server problem. The new IETF draft pushes the same migration question into enterprise access control, where TLS sits inside Extensible Authentication Protocol methods used for Wi-Fi, wired 802.1X and other authenticated network access. The draft explicitly covers EAP-TLS, EAP-TTLS, PEAP and TEAP.
That matters because an organization can harden its public web edge and still leave authentication infrastructure on quantum-vulnerable public-key cryptography. A useful cryptographic inventory therefore has to include RADIUS-facing TLS, supplicant configuration, access infrastructure and the certificate authority chain behind EAP, not only HTTPS endpoints.
The draft joins key exchange and authentication
TLS 1.3 already gives EAP-TLS a modern base. RFC 9190 specifies EAP-TLS with TLS 1.3 and requires forward secrecy. Post-quantum migration adds two different jobs on top of that base. Hybrid or post-quantum key establishment protects recorded sessions against a future cryptographically relevant quantum computer. Post-quantum signatures protect certificate authentication once classical signature schemes are no longer sufficient.
| Surface | Migration goal | Operational evidence |
|---|---|---|
| TLS key establishment | Negotiate a post-quantum or hybrid key exchange | Capture the selected group, not only client support |
| Certificate authentication | Move certificate and handshake signatures to post-quantum-capable schemes | Verify the actual chain and CertificateVerify algorithms |
| EAP transport | Carry the larger handshake reliably | Measure fragmentation, round trips, failures and timeout behavior |
This separation is important. A deployment can negotiate a hybrid key exchange while still authenticating with a classical certificate. The reverse can also happen. Calling either state simply 'post-quantum' hides which security property changed. The same distinction is central to our hybrid TLS migration guide and to end-to-end hybrid TLS verification.
Certificate size becomes a network problem
The draft gives unusual weight to certificate size because EAP transports TLS through an authentication exchange with its own fragmentation and round-trip behavior. Post-quantum public keys and signatures can make certificate chains substantially larger than familiar elliptic-curve chains. That can turn a cryptographic upgrade into a latency, fragmentation or interoperability regression if it is tested only in a lab with one supplicant and one authentication server.
The IETF already standardized TLS certificate compression in RFC 8879. It lets peers compress the Certificate message in TLS 1.3 and newer, where certificate chains often dominate handshake bytes. The new EAP draft uses that existing mechanism as part of the answer to larger post-quantum authentication material rather than inventing a separate compression format.
Compression does not remove the need to test size limits
A smaller transmitted certificate message is useful, but the peer still has to decompress, parse and validate the full chain. Test maximum chain sizes, fragment counts, timeout behavior and failure paths. Do not treat a successful compressed handshake as proof that every supplicant, access point and RADIUS path will tolerate the same certificate profile.
What enterprise teams can test now
- Map every EAP method in use and the TLS version behind it. EAP-TLS, EAP-TTLS, PEAP and TEAP should not be treated as one homogeneous deployment.
- Record where TLS terminates and which component owns key-exchange and certificate policy. Include supplicants, access infrastructure, RADIUS proxies and authentication servers.
- Test hybrid key exchange and post-quantum certificate authentication separately. Keep the negotiated algorithms in the evidence bundle.
- Measure full handshake byte counts, fragments, round trips and authentication time before and after changing algorithms or certificate chains.
- Exercise failure paths with oversize chains, unsupported compression, classical-only peers and resumed sessions before widening rollout.
This is exactly the kind of migration boundary that gets lost when a program starts with algorithm names instead of protocol paths. The PQC migration roadmap should treat enterprise authentication as its own workstream, and an audit should verify what was actually negotiated across representative access paths rather than accepting product support claims.
It is useful now, but it is still a draft
draft-ietf-emu-pqc-eap-tls-01 is an Internet-Draft with intended Standards Track status. It can change before publication, and implementations that pin behavior to this revision may need to follow later revisions. The practical value today is narrower and still significant: the IETF working group is defining how post-quantum migration reaches enterprise network authentication, and it is explicitly connecting cryptographic choices to certificate size and handshake transport.
For teams already moving public TLS, the next inventory question is simple: where else is TLS carrying identity inside the organization? EAP is one of those places. The new draft gives that hidden surface a concrete standards path and a testable set of engineering constraints.
References
- IETF: Post-Quantum Enhancements to TLS-Based EAP Methods, draft-ietf-emu-pqc-eap-tls-01, published 21 September 2026.
- RFC 9190: EAP-TLS 1.3, the Standards Track specification for using TLS 1.3 in EAP-TLS.
- RFC 8879: TLS Certificate Compression, the Standards Track mechanism for compressing Certificate messages in TLS 1.3 and later.
- NIST FIPS 203: ML-KEM, the finalized NIST key-encapsulation standard referenced by current post-quantum migration work.