Is TLS 1.2 End of Life? No — the Full TLS Protocol Lifecycle: What Died in 2021, What Shipped in 2018, and What Compliance Actually Requires

By Scott Bissett  ·  Published: August 12, 2026  ·  Evergreen compliance reference  ·  Verified against RFC 8996, RFC 8446, NIST SP 800-52 Rev. 2, PCI SSC migration guidance, and our tracked lifecycle data — methodology

Three questions arrive at this site constantly, and the honest answers fit in one paragraph. Is TLS 1.2 end of life? No — no standards body has deprecated it, none has announced a date, and both NIST and PCI DSS permit it today. When was TLS 1.3 released? August 10, 2018, as RFC 8446. What is TLS 1.3's status? It is the current version of the protocol — no successor exists, and no deprecation is planned. The versions that actually died are TLS 1.0 and TLS 1.1, formally deprecated in March 2021 by RFC 8996 — and the real TLS end-of-life story in 2026 is that, five years after the standards-level death certificate, both are still being found in production.

Every TLS version: released, deprecated, status

Four protocol versions, two of them dead. Each version links to its lifecycle page with live status and risk score; the deprecation dates below are re-checked against our tracked TLS data at every site build.

Dates from our tracked dataset, which records the end-of-life date for TLS 1.0 and 1.1 as March 23, 2021 — the publication date of RFC 8996 — and marks TLS 1.2 and 1.3 with no deprecation, which is rendered here exactly as the data says: none planned. Release dates are the publication dates of each version's defining RFC.

A protocol dies differently than software — and stays dead the same way

Software reaches end of life when a vendor stops shipping patches on a published date. A protocol has no vendor and no patch stream, so it dies by two other events. The first is standards action: in March 2021 the IETF published RFC 8996 — Deprecating TLS 1.0 and TLS 1.1, part of Best Current Practice 195 — with unusually blunt normative language: TLS 1.0 MUST NOT be used, TLS 1.1 MUST NOT be used, negotiation of either from any TLS version MUST NOT be permitted, and implementations should reject a Hello offering them with a protocol_version alert. The defining specifications, RFC 2246 and RFC 4346, were reclassified as Historic. The rationale is the protocol-level equivalent of an unpatchable CVE list: dependence on SHA-1, no support for modern AEAD ciphers, and mandatory cipher suites that no longer meet any current bar — the PCI Council's own migration guidance names POODLE and BEAST among the attacks that made SSL and early TLS unsalvageable.

The second event is ecosystem removal, and it actually came first: Chrome, Firefox, Safari and Edge all disabled TLS 1.0 and 1.1 in 2020, a year before the RFC made it official. A protocol is dead when the standard disowns it and the clients stop speaking it — and by that test, both events are years behind us.

The effect, though, is identical to software EOL: permanent exposure. A protocol version never gets fixed — the fix is the next version. Every weakness in TLS 1.0 as deployed in 2026 is a weakness forever, on every endpoint still offering it. And in practice, old TLS does not live in the abstract: it lives inside software with an end-of-life problem of its own. Java 6/7-era application stacks default to — or top out at — old TLS versions unless specifically updated, which is one more reason old Java runtimes carry more risk than their CVE lists show. Applications with a bundled cryptography library of matching vintage have the same ceiling — the modern edition of that problem is OpenSSL 3.0's September 7, 2026 end of life. Add embedded devices, network appliances, and payment or industrial hardware that shipped once and never updated, and the pattern is consistent: where you find TLS 1.0, you almost always find end-of-life software underneath it. They travel together, and the 2026 EOL calendar keeps adding to the second list.

Is TLS 1.2 end of life? The honest answer is no

This question gets asked constantly — usually because someone has seen a migration deadline, a scanner finding, or a vendor slide and concluded that TLS 1.2 is next. The record says otherwise. No standards body has deprecated TLS 1.2, and no deprecation date exists. RFC 8996 deliberately stopped at 1.1. NIST SP 800-52 Rev. 2 — the federal TLS guideline — requires that TLS 1.2, configured with FIPS-based cipher suites, be supported by all US government TLS servers and clients. PCI DSS accepts it for payment environments. Our dataset records it, honestly, as having no end-of-life date — the same status as TLS 1.3.

Three honest caveats keep that answer from becoming complacency. First, TLS 1.2 is the floor, not the target: NIST required agencies to support TLS 1.3 by January 1, 2024, and new protocol and performance work happens on 1.3. Second, configuration does the real work on 1.2: a TLS 1.2 endpoint running modern AEAD cipher suites and a 1.2 endpoint dragging legacy CBC suites are different security postures wearing the same version number — TLS 1.3 removed that entire failure mode by pruning every legacy algorithm from the protocol. Third, when a deprecation eventually comes, it will arrive the same way the last one did — an IETF action with years of ecosystem warning, not a surprise. If a vendor or auditor tells you TLS 1.2 must be gone by some date, ask which standard the date comes from. Today, the answer is none.

The compliance matrix: PCI DSS, NIST, CRA and NIS2

PCI DSS killed old TLS earliest. The PCI Security Standards Council set June 30, 2018 as the deadline for migrating off SSL and early TLS: after that date, SSL and TLS 1.0 could no longer be used as a security control in cardholder data environments — TLS 1.1 or higher was permitted at the time, with TLS 1.2 strongly encouraged — with one narrow carve-out for POS POI terminals verified as not susceptible to the known exploits. That deadline predates the IETF's own deprecation by almost three years; payment infrastructure was the test case for whether the ecosystem could actually retire a protocol. The current standard is PCI DSS v4.0.1 (released June 11, 2024; v4.0 retired December 31, 2024, and 3.2.1 retired March 31, 2024, per our tracked data) — it carries the requirement forward as strong cryptography for cardholder data over open public networks, which in practice means TLS 1.2 or 1.3.

NIST SP 800-52 Rev. 2 (August 2019) sets the federal bar: all US government TLS servers and clients must support TLS 1.2 with FIPS-based cipher suites, and agencies were required to support TLS 1.3 by January 1, 2024. Note the verb — support 1.3, not abandon 1.2. Federal guidance currently treats 1.2 as the minimum and 1.3 as the direction of travel.

The EU CRA and NIS2 never name protocol versions — and that makes deprecated protocols more dangerous under them, not less. The Cyber Resilience Act requires products with digital elements to be secure by default and to reflect the state of the art across their support period; NIS2 obliges essential and important entities to run risk-management measures that include cryptography policies. A protocol the IETF says MUST NOT be used fails a state-of-the-art test by definition — there is no compensating-control argument that survives the primary source being one sentence long. Financial entities under DORA inherit the same logic for legacy ICT. For the board-level version of this exposure, see the CISO compliance-risk briefing.

Framework rows summarize each body's published position on protocol versions as of August 2026; primary sources are linked in the prose above. The CRA/NIS2/DORA row states the obligation structure, not a protocol-by-protocol ruling — none exists.

Finding TLS 1.0 and 1.1 in your estate

The 2021 deprecation is only interesting in 2026 because these protocols keep turning up. Three places to look, in increasing order of pain:

1. Server configuration you control. The minimum protocol version is one line in most stacks — SSLProtocol in Apache httpd, ssl_protocols in nginx, ssl-min-ver on HAProxy binds, Schannel settings on Windows. Anything not explicitly pinned to TLSv1.2-or-higher on an older base install deserves a look: permissive defaults from the machine's install date tend to outlive every migration since.

2. What your endpoints actually negotiate. Configuration files describe intent; a handshake test describes reality. openssl s_client -connect host:443 -tls1 (and -tls1_1) answers the question directly — if the connection completes, the endpoint still speaks it. TLS-configuration scanners and external attack-surface tools report the same finding across a whole estate, and load-balancer listeners are the classic gap: the backend was hardened years ago, the listener in front of it never was.

3. The clients you forgot were clients. The hardest finds are the things that initiate old TLS: embedded management interfaces, printers and scan-to-email firmware, lab and medical devices, payment hardware, industrial controllers, and application stacks pinned to a Java or library version whose TLS ceiling was set a decade ago. This is where the protocol problem and the EOL-software problem become the same problem — raising the server-side minimum is a one-line change, but it breaks every legacy client the moment you flip it, which is why inventorying the clients comes first. The thing still speaking TLS 1.0 is usually the thing nobody can update — and that is an end-of-life software decision, not a TLS decision.

Frequently Asked Questions

Related

• All TLS versions with live status · TLS 1.2 — dates and risk score · TLS 1.3 — dates and risk score
• PCI DSS version lifecycle — every revision's release and retirement dates, including v4.0.1
• The EU Cyber Resilience Act and EOL software · NIS2 and end-of-life compliance · DORA and legacy ICT
• OpenSSL 3.0 End of Life: September 7, 2026 — where the TLS library itself hits the wall
• Java support deadlines and the Oracle licensing trap — the old-Java stacks with old-TLS ceilings
• The 2026 EOL Calendar — everything else going end of life this year