The IETF has officially frozen TLS 1.2. RFC 9851, published July 2026, specifies that no new features will be approved for TLS 1.2, with narrow exceptions for urgent security fixes, new TLS Exporter Labels, and new ALPN Protocol IDs. This applies only to TLS, not DTLS. The move accelerates the industry's transition to TLS 1.3, which has been available since 2018 and fixes known deficiencies in TLS 1.2.

What RFC 9851 Actually Says

The document, authored by Rich Salz (Akamai) and Nimrod Aviram, modifies the instructions to IANA and the TLS Designated Experts. It adds a note to most TLS registries (Cipher Suites, Supported Groups, ExtensionType, etc.) stating that new entries after this RFC are intended for TLS 1.3 or later. The note reads: "Any TLS entry added after the IESG approves publication of RFC 9851 is intended for TLS 1.3 or later, and makes no similar requirement on DTLS. Such entries should have an informal indication like 'For TLS 1.3 or later' in that entry."

This means new cryptographic algorithms, groups, or extensions will be specified only for TLS 1.3. TLS 1.2 remains usable for now, but it will not evolve.

Why This Matters for Post-Quantum Cryptography

The most significant immediate impact is on post-quantum cryptography (PQC). The RFC explicitly states: "PQC for TLS 1.2 will not be specified (see Section 4) at any time; anyone wishing to deploy PQC should expect to use TLS 1.3." This is a hard stop for anyone hoping to bolt quantum-resistant algorithms onto TLS 1.2.

NIST standardized ML-KEM, ML-DSA, and SLH-DSA in August 2024. The IETF's PQUIP working group and the TLS working group are actively specifying hybrid algorithms for TLS 1.3. The TLS working group's effort is "focused exclusively on TLS 1.3 or later." If you're planning for quantum resistance, TLS 1.3 is the only path forward.

Security and Practical Implications

TLS 1.3 encrypts more of the handshake, removes weak cryptographic primitives, and has robust security proofs. The freeze on TLS 1.2 is a security-driven move. The RFC notes that TLS 1.3 "fixes most known deficiencies with TLS 1.2." By halting TLS 1.2 development, the IETF prevents the protocol from becoming a long-term liability.

For developers, this is a clear signal: if you haven't already, you need to plan your migration to TLS 1.3. The longer you wait, the more you'll miss out on new features and security improvements. For example, new TLS extensions or cipher suites will be TLS 1.3-only. Your infrastructure might support both, but you won't get new capabilities on TLS 1.2.

What This Means for Your Code

If you're maintaining a TLS library or a service that handles TLS, check your configuration. For OpenSSL, you can enforce TLS 1.3 with:

SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

In Nginx, you can set:

ssl_protocols TLSv1.3;

In Go, the default http.Server supports TLS 1.3 automatically, but you can set it explicitly:

tls.Config{
    MinVersion: tls.VersionTLS13,
}

These are just starting points. The key is to test your applications against TLS 1.3 and ensure compatibility. Also, review any custom extensions or cipher suites you've implemented — they may need to be updated for TLS 1.3.

The Road Ahead

The RFC is effective immediately. The TLS working group will now focus all new work on TLS 1.3. For anyone building new systems, there's no reason to start with TLS 1.2. For existing systems, start planning your upgrade now. The post-quantum transition is coming, and TLS 1.2 won't be part of it.

Next Steps

  1. Audit your current TLS configuration and identify any TLS 1.2-only dependencies.
  2. Enable TLS 1.3 on your servers and clients.
  3. Monitor IETF discussion for new TLS 1.3 extensions and hybrid PQC standards.
  4. If you're implementing PQC, focus on TLS 1.3 and stay tuned for hybrid key exchange specifications.