Published on
August 9, 2026
On July 4, 2026, the IETF working group Using TLS in Applications (UTA) published the third revision of the Internet-Draft titled "Post-Quantum Cryptography Recommendations for TLS-based Applications", formally referenced as draft-ietf-uta-pqc-app-03. Authored by Tirumaleswar Reddy (Nokia) and Hannes Tschofenig (University of the Bundeswehr Munich), draft-ietf-uta-pqc-app sits on the Standards Track and is taking shape as the reference profile for making TLS-based applications quantum ready.
Much of the post-quantum conversation to date has focused on algorithms, notably the NIST standardization of ML-KEM, ML-DSA and SLH-DSA. This draft addresses the layer where migration actually happens: applications. TLS 1.3, DTLS 1.3, QUIC, encrypted DNS, and the supporting protocols that virtually every client-server exchange on the Internet depends on. The document acknowledges an uncomfortable truth. The industry has managed cryptographic transitions before, from the deprecation of SSLv2 to the shift from RSA to elliptic curves, but the post-quantum transition is different. Keys and signatures are larger, implementations are younger, and the performance trade-offs cut in both directions.
For organizations operating their own PKI and certificate infrastructure, draft-ietf-uta-pqc-app deserves a close reading. It translates the abstract quantum threat into concrete protocol decisions, and several of them land squarely on the desk of the PKI team.
Two Threats, Two Timelines
The most structurally important contribution of draft-ietf-uta-pqc-app is its clear separation of the transition into two distinct problems with two distinct clocks.
The first clock is already ringing. Data confidentiality is exposed today to "Harvest Now, Decrypt Later" (HNDL) attacks: an adversary records encrypted TLS traffic now, stores it, and decrypts it once a Cryptographically Relevant Quantum Computer (CRQC) becomes available. The window of vulnerability is not the lifetime of the TLS session. It is the useful lifetime of the data itself, which can span decades for health records, industrial designs or state secrets. This is why the draft treats key exchange as the urgent front.
The second clock runs slower but cannot be ignored. Authentication, the certificate-based identity verification at the heart of every TLS handshake, cannot be retroactively broken. A CRQC arriving in 2035 cannot forge a signature that was verified in 2026. The draft nevertheless highlights a sobering asymmetry. While the signature in a CertificateVerify message lives for milliseconds, root CA certificates commonly carry validity periods of 20 years or more. Establishing, certifying and distributing new root CAs is a multi-year process. If a CRQC arrives earlier than expected, there will be no time to improvise a PKI migration.
From Principle to Protocol: The Confidentiality Requirements
On the confidentiality problem, draft-ietf-uta-pqc-app does not hedge. It requires applications using (D)TLS that are exposed to HNDL attacks to move to (D)TLS 1.3 and to adopt a quantum-ready key exchange. Two paths are defined.
The path the draft favors is hybrid key exchange, combining a traditional and a post-quantum algorithm so that the session remains secure as long as either component holds. Three hybrid groups are specified for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. The rationale is defense in depth. PQC implementations are young, and cryptanalysis is a moving target.
Take control of your PKI infrastructure
See how Evertrust simplifies certificate lifecycle management.
Get StartedThe second path, pure ML-KEM key exchange (ML-KEM-512, ML-KEM-768, ML-KEM-1024), is reserved for deployments whose regulatory or compliance frameworks mandate exclusively post-quantum algorithms.
The draft is equally pragmatic about deployment friction. Upgrading a TLS library is a necessary first step but not a sufficient one, as PQC groups are not always enabled by default. Applications that pin protocol versions or cipher suites are expected to update their configuration explicitly, and those relying on library defaults are invited to verify through documentation or interoperability testing that PQC groups are actually negotiated. An entire section is devoted to a subtle operational problem: the ClientHello. Hybrid key shares are large enough to exceed the MTU, fragmenting the handshake across packets that middleboxes may mishandle, particularly over DTLS. The draft weighs three strategies: sending both traditional and hybrid key shares upfront (fast, but heavy), signaling hybrid support and accepting a HelloRetryRequest round trip (lean, but slower), or using DNS-based key share prediction to let clients tailor their first message. None is declared universally correct. The choice depends on the network environment.
Authentication: Where PKI Takes Center Stage
The authentication chapters are where draft-ietf-uta-pqc-app speaks most directly to PKI operators, and three themes stand out.
The first is the certificate format decision. Deployments can go purely post-quantum, with ML-DSA certificates, or SLH-DSA for those who accept larger signatures in exchange for conservative security assumptions. Alternatively, they can adopt composite certificates that bind a traditional key (ECDSA, RSA, Ed25519) and a post-quantum key in a single X.509 structure. Composite verification succeeds only if all component signatures verify, which yields a notable property the draft analyzes in detail: even after a CRQC breaks the traditional component, TLS impersonation remains infeasible as long as the PQC component stays secure. In practice, this gives organizations a controlled transition window rather than an emergency migration, even in a scenario where the arrival of a CRQC is considered imminent.
The second theme is a warning the industry needed to hear: a post-quantum end-entity certificate issued under a classical CA hierarchy provides no post-quantum authentication. Every validation-critical signature, from the leaf up to the trust anchor, needs protection by a PQC or hybrid scheme, because an attacker equipped with a CRQC could forge signatures made with traditional CA keys anywhere in the chain. The draft consequently elevates trust anchor provisioning to a first-class migration concern. Long-lived or hard-to-update systems, such as embedded and industrial devices, may require PQC or hybrid trust anchors installed at manufacture, because a field update may never come. The draft also cautions that fallback policies accepting traditional-only chains deserve to be explicit, since they silently downgrade the security property.
The third theme is handshake economics. PQC certificate chains are large, and the draft surveys the mitigation toolbox: TLS certificate compression (of limited value against high-entropy PQC keys), the cached information extension (effective, though it carries session-correlation privacy trade-offs), abridged certificates that omit intermediates already known to the client, and trust anchor identifiers that help servers select the right chain when traditional, composite and PQC hierarchies coexist.
Beyond TLS itself, draft-ietf-uta-pqc-app extends its requirements to the protocols applications quietly depend on. Encrypted DNS (DoT, DoH, DoQ) and Encrypted Client Hello via HPKE are directed toward the same quantum-ready profiles, because a recorded DNS exchange is just as harvestable as any other ciphertext.
What This Means for Certificate Operations in Europe
For European organizations, draft-ietf-uta-pqc-app does not arrive in a vacuum. It lands on top of a regulatory trajectory that is already binding. DORA has applied to the financial sector since January 2025, with its explicit requirements for cryptographic inventory and risk-based key management. NIS2 transpositions extend comparable obligations across essential and important entities. The EU coordinated roadmap on post-quantum cryptography, together with national guidance from ANSSI and BSI, converges on the same horizon the draft implicitly serves: hybrid protection for high-risk flows well before 2030, and full migration trajectories extending to 2035.
Read through that lens, draft-ietf-uta-pqc-app is best understood as the protocol-level companion to those governance obligations. The regulators ask organizations to inventory their cryptography and plan the migration. The IETF now describes what the migrated state of a TLS estate looks like. Connecting the two is an operational problem, and it is largely a certificate lifecycle problem: knowing which endpoints negotiate which groups, which chains terminate on which anchors, which devices can receive new roots and which cannot, and being able to reissue at scale when an algorithm, a parameter set or an entire hierarchy changes.
That capability has a name, crypto-agility, and the transition considerations in the draft make clear it is not optional. Deployments with limited upgrade flexibility are steered toward hybrid schemes precisely because they cannot pivot quickly. Deployments with strong administrative control, such as centralized enterprise and telecom networks, are identified as those able to adopt PQC signatures earliest. The differentiator is not the algorithm. It is the automation and governance around it.
Closing Thoughts
Draft-ietf-uta-pqc-app-03 remains a work in progress, and Internet-Drafts can change before publication as an RFC. Its direction is stable across revisions, however, its requirements language is unambiguous on the points that matter most, and it aligns with the standards it builds on, from the NIST FIPS algorithms to the TLS hybrid design work. For application owners, it answers the question of what to actually configure. For PKI teams, it confirms that the post-quantum transition will be won or lost in the certificate layer: trust anchor strategy, composite issuance, chain optimization, and the ability to execute a phased migration without breaking production.
The prudent reading is the one the draft itself suggests: confidentiality first, authentication planned now. Organizations that treat their PKI as an agile, automated, inventoried system will experience the coming decade as a sequence of managed changes. Those that treat it as static infrastructure will experience it as a cliff.
