Hybrid post-quantum TLS in 2026: what is an RFC and what is still a draft?

FIPS 203 standardized ML-KEM in August 2024, and NIST SP 800-227 added final KEM-use guidance in September 2025. These publications establish the algorithm and important implementation principles. They do not, by themselves, define how every application protocol carries ML-KEM keys, combines ML-KEM with traditional key agreement, negotiates parameters, handles failures, or interoperates across deployed products.

As of July 20, 2026, RFC 9794 is a published Informational terminology document, and RFC 9935 and RFC 9936 are published Standards Track documents for specific X.509 and CMS uses. The IETF TLS working group's hybrid ECDHE-MLKEM specification had completed IESG approval and was in RFC Editor processing but was not yet an RFC. The separate pure ML-KEM TLS 1.3 specification remained in Working Group Last Call with a revision needed. A precise architecture record must name the exact layer and publication status instead of compressing all of them into the statement that post-quantum TLS is standardized.

RFC 9794 uses post-quantum/traditional, or PQ/T, hybrid language for designs that combine a post-quantum component with a traditional component. The intended security argument is that the combined scheme can preserve its target property when at least one component remains secure, subject to the combiner and protocol actually satisfying that argument. Naming two algorithms is not enough; their inputs, outputs, domain separation, failure handling, and binding to the transcript matter.

Protocol negotiation that lets peers choose either a traditional group or a post-quantum group is not automatically the same security construction as a hybrid group that combines both contributions in one exchange. Teams should document whether a connection used a combined group, a PQ-only group, or a traditional fallback; which party selected it; and whether an attacker could influence that selection. RFC 9794 also cautions that broad labels such as quantum-safe can create more confidence than the evidence supports.

RFC 9935 standardizes identifiers and encodings for ML-KEM public and private keys in the Internet X.509 public-key infrastructure. Because ML-KEM is a key-encapsulation mechanism rather than a signature algorithm, its certificates have a specialized key-establishment role. For TLS use, RFC 9935 says ML-KEM certificates could only serve as end-entity identity certificates and would require significant protocol updates. An ML-KEM certificate is not a drop-in replacement for the signature key that authenticates a conventional Web PKI server certificate.

RFC 9936 specifies direct ML-KEM recipient processing for Cryptographic Message Syntax. Its scope is CMS, and it explicitly does not define a hybrid key-establishment construction. Both RFCs use the final ML-KEM standardized by FIPS 203. RFC 9935 warns that final ML-KEM is incompatible with pre-standard Kyber encodings and identifiers, so an inventory must distinguish final-standard support from older experimental deployments instead of treating every Kyber or ML-KEM label as wire-compatible.

Version 05 of draft-ietf-tls-ecdhe-mlkem, published May 26, 2026, defines X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 for TLS 1.3. It has an intended status of Proposed Standard, had received IESG approval, and was in RFC Editor processing on July 20, 2026. That is an advanced publication state, but it is not publication as an RFC. Implementations and pilots must still pin the draft version until the RFC is issued because the final published record and identifiers are the claim boundary.

The version-05 wire contributions make sizing an operational concern. X25519MLKEM768 carries a 1,216-byte client key share and a 1,120-byte server share. SecP256r1MLKEM768 carries 1,249 and 1,153 bytes. SecP384r1MLKEM1024 carries 1,665 bytes in each direction. These are group key-share sizes from that draft version, not total TLS handshake sizes; certificates, signatures, extensions, and transport framing add further bytes.

The hybrid draft combines traditional elliptic-curve Diffie-Hellman with ML-KEM and, as noted above, had passed IESG approval while awaiting RFC publication. The separate draft-ietf-tls-mlkem describes pure post-quantum ML-KEM key agreement for TLS 1.3; version 08 was published June 24, 2026 with Informational intended status and remained in Working Group Last Call with a revised draft needed. Neither document was an RFC on July 20, 2026. A pilot may implement one for research or controlled interoperability, but its evidence should never present draft behavior as an immutable Internet standard.

Hybrid migration can retain confidence in a mature traditional primitive while adding a post-quantum contribution, but it adds bytes, implementation paths, validation duties, and combination logic. PQ-only key agreement removes the traditional component but places the targeted property on the post-quantum construction and ecosystem. The decision should consider assurance requirements, implementation maturity, interoperability, policy, performance, fallback behavior, and the lifetime of protected data. Authentication remains a separate design axis in either case.

Start with a bounded path and enumerate every TLS endpoint: client, CDN, load balancer, API gateway, service mesh sidecar, origin, inspection appliance, and management interface. A hybrid external connection followed by a traditional internal hop is not end-to-end hybrid protection. Capture the negotiated group at every termination point and connect it to software version, configuration, certificate and signature profile, request path, and test timestamp.

Measure full ClientHello and ServerHello behavior, packetization and fragmentation, MTU interaction, middlebox tolerance, retry rate, tail latency, CPU, memory, throughput, connection establishment under loss, resumption, and failure recovery. Test unsupported groups, reordered preferences, disabled PQ support, malformed key shares, partial fleet rollout, and intentional downgrade attempts. Confirm that fallback is observable and governed rather than silently converting a security requirement into a best-effort preference.

Package the pilot evidence with the business and data boundary, threat property, topology and termination map, exact specification versions, algorithm and group identifiers, implementation builds, configuration, test corpus, supported interoperability matrix, performance distributions, failure and downgrade results, residual traditional hops, authentication method, owner, approval, and refresh trigger. Draft expiry or revision, library updates, certificate changes, or topology changes should reopen the record.

Prefer a claim such as: a named pilot successfully negotiated X25519MLKEM768 under draft-ietf-tls-ecdhe-mlkem-05 across a defined client and server matrix, with measured overhead and documented traditional fallback. Avoid saying that the entire platform uses standardized quantum-safe TLS unless the publication status, whole path, authentication layer, operational configuration, and evidence actually support every part of that sentence.