TLS Version Compliance: Why the Standard Starts at TLS 1.2, and Why TLS 1.3 Is the Target

Under the current PCI DSS standard (v4.0.1), the configuration of TLS protocol versions is one of the core items examined at every assessment. Plenty of clients are told during assessment that they "need TLS 1.2 or above deployed, and should upgrade straight to TLS 1.3" without being shown the security reasoning behind the requirement, the compliance basis for it, or how the versions got here.

In practice, a good number of legacy business systems and internal services still run on TLS 1.0 or even SSL 3.0. On the surface nothing breaks, but underneath sit serious risks — traffic interception, tampering, and man-in-the-middle attacks — and this remains one of the most frequent sources of findings in compliance assessments. Below we break down the security differences between TLS versions and explain the reasoning behind the requirement.

What Each TLS Version Iteration Actually Changed

TLS (Transport Layer Security) is the core protocol protecting encryption, authentication, and data integrity for network traffic. HTTPS, encrypted internal communication, and secure system-to-system transfers all depend on it. From the early SSL protocol through to today's TLS, every version iteration has fundamentally been an exercise in patching high-risk vulnerabilities, retiring weak cryptographic algorithms, and raising transport security.

Industry and compliance standards are now quite clear on where each version stands:

• SSL 3.0 and TLS 1.0: classified by both industry and compliance standards as retired, and should not remain in use.
• TLS 1.1: the PCI SSC has determined it does not meet the definition of strong cryptography, and current NIST guidance advises against its use (that guidance is still in its public comment period). It is not, however, absolutely prohibited. Secure Vectors does not recommend it as a long-term option.
• TLS 1.2: the baseline version under the current strong cryptography requirement, and the minimum organisations should deploy. (The PCI DSS requirement text does not specify version numbers verbatim, but TLS 1.0 and 1.1 have been officially excluded from the strong cryptography definition — see the references at the end.)
• TLS 1.3: the best current version, combining high performance with high security, and the preferred upgrade target.

A necessary clarification: the PCI DSS requirement text does not itself specify which TLS version numbers must be used. It requires organisations to use strong cryptography. According to the PCI Security Standards Council FAQ "Does PCI DSS define which versions of TLS must be used?" (Article #1491, updated July 2026), "early TLS" covers at minimum TLS 1.0 and TLS 1.1, neither of which meets the PCI DSS definition of strong cryptography, and neither can therefore be used to satisfy requirements that call for it. The same FAQ recommends prioritising cipher suites that support forward secrecy, and evaluating the adoption of post-quantum cryptographic algorithms.

Separately, NIST SP 800-52 Rev. 2 (the current TLS implementation guidance) requires government-only servers to support TLS 1.2, states explicitly that TLS 1.1 should not be configured for use, and that TLS 1.0 shall not be used. For servers that must interoperate with the general public or with business partners, the use of TLS 1.1 and TLS 1.0 falls into a more flexible space — generally discouraged, but retainable where interoperability demands it. Worth noting: NIST opened a public comment period on this guidance in May 2026 (comments closed 10 July 2026), covering among other things whether to adjust the provisions on TLS 1.1 and 1.0. The current version is not the final word.

Taking the current PCI SSC and NIST positions together, our assessment at Secure Vectors is this: TLS 1.0 has no legitimate remaining use case and is excluded from the security baseline by both official documents consistently — it should be disabled immediately. TLS 1.1 is a transitional protocol in the "not recommended" category; organisations should plan a replacement timeline, but it does not yet amount to an outright prohibition.

Why TLS 1.0 Must Be Disabled, and TLS 1.1 Should Not Continue

TLS 1.0 dates from 1999. Its architecture is dated, its algorithms weak, and it carries several high-risk vulnerabilities that cannot be fixed. The BEAST attack (2011) targeted the initialisation vector flaw in TLS 1.0 under CBC mode. The CRIME attack exploited a side-channel weakness in TLS/SSL compression, affecting both SSL 3.0 and TLS 1.0. The POODLE attack (2014) targeted primarily the padding validation flaw in SSL 3.0. Each of these can be used to break encrypted traffic, steal data, or tamper with what is transmitted. Mainstream browsers, server software, and compliance standards worldwide have now disabled TLS 1.0 across the board, which makes it one of the hard lines in any current compliance check.

TLS 1.1 fixed the CBC initialisation vector flaw that BEAST exploited, which made it an important transitional version at the time and kept a degree of compatibility with older business systems. Its overall cryptographic mechanisms remain weak, though, and it is no longer regarded as something to depend on for compliance in the long run.

That is also why TLS 1.1 was once treated as the minimum compliance threshold, back in the PCI DSS v3.x era: it reduced some of the risk relative to TLS 1.0 while accommodating legacy systems. But to be explicit — the PCI SSC FAQ now states clearly that TLS 1.1 does not meet the strong cryptography definition, and current NIST guidance advises against continued use (with that guidance still in public comment). Reading both official sources together, we do not recommend TLS 1.1 as a long-term option. That said, it sits at the "not recommended" level rather than "absolutely prohibited", which is a different characterisation from TLS 1.0 — consistently excluded, and to be disabled now.

Why TLS 1.2 Is the Recommended Minimum Baseline

Even when TLS 1.1 was treated as an acceptable floor, its shortcomings were plain: only some vulnerabilities fixed, continued reliance on dated weak hash algorithms, no forward secrecy, lower encryption efficiency, and limited resistance to newer attacks. Both the PCI SSC and NIST now list it as a protocol version they advise against.

TLS 1.2, by contrast, is the minimum version organisations can adopt under the current strong cryptography requirement (the PCI DSS text does not name version numbers verbatim, but TLS 1.0 and 1.1 are officially excluded from the strong cryptography definition), and it is both stable and widely supported. Its core advantages:

• Comprehensive algorithm upgrade: weak hash algorithms such as MD5 and SHA-1 are retired entirely, with support for SHA-256 and the AES-GCM cipher mode, substantially raising cryptographic strength.
• Sound vulnerability protection: the overwhelming majority of known high-risk vulnerabilities in TLS 1.0 and 1.1 are fixed, with no publicly exploitable fatal flaw at present and markedly better resistance to attack.
• Good compatibility: works with the vast majority of current servers, endpoints, and business systems, balancing security against interoperability.
• Broad compliance coverage: helps satisfy corporate security management policies, data security audits, financial sector supervisory requirements, and public sector procurement security checks.

TLS 1.3, the next iteration, builds on 1.2 by streamlining the handshake, making forward secrecy mandatory, and removing every weak algorithm — faster and more secure, and the best upgrade target for larger organisations and core business systems. TLS 1.3 also pairs more readily with cipher suites supporting forward secrecy and post-quantum cryptographic algorithms, helping organisations get ahead of the encryption challenges of the post-quantum era. That is one of the best-practice directions the PCI SSC FAQ itself points to.

Practical Recommendations for Getting Compliant

Combining the compliance checks with real deployment experience, here is the upgrade order we work through with clients:

• Remediate immediately: disable SSL 3.0 and TLS 1.0 on every service, eliminating the hard-line violations.
• Handle by tier: TLS 1.1 is not absolutely prohibited but is no longer recommended; plan an upgrade timeline for it too, rather than depending on it indefinitely.
• Roll out broadly: upgrade all business systems, old and new, to TLS 1.2 as the stable long-term version.
• Optimise: move core business, external-facing services, and highly sensitive data systems to TLS 1.3 progressively.

Closing: The Secure Vectors View

TLS protocol versions look like basic configuration, but they are the first line of defence for network transport security. Vulnerabilities in older protocol versions are among the most common entry points for intrusion and data exfiltration. Under the current strong cryptography requirement, "start at TLS 1.2, prefer TLS 1.3" is the position that actually holds up — not a paperwork exercise, but a practical necessity for reducing network security risk. We would also suggest keeping an eye on developments in post-quantum cryptography, to prepare the ground for longer-term compliance.

Completing protocol version upgrades promptly and disabling weak cipher suites helps organisations pass compliance assessments smoothly and strengthens data transport protection at the source. If you have not yet inventoried your TLS versions, or are unsure whether your current configuration meets the strong cryptography requirement of PCI DSS v4.0.1, contact the Secure Vectors consulting team — QSA-qualified consultants can assist with the technical inventory and the rollout plan.

Glossary

• TLS (Transport Layer Security): the encryption protocol protecting data in transit across networks; the successor to SSL.
• SSL (Secure Sockets Layer): the predecessor to TLS, retired across the industry because of multiple high-risk vulnerabilities.
• Strong cryptography: a PCI DSS term for a combination of cryptographic techniques meeting specified key length (112 bits), algorithm strength, and security requirements. It designates a set of security criteria rather than a single protocol version.
• Forward secrecy: a key exchange mechanism under which previously encrypted communications cannot be recovered even if a long-term private key is later compromised.
• Post-quantum cryptography: the next generation of cryptographic techniques, designed against the possibility that future quantum computers break today's algorithms.
• BEAST / CRIME / POODLE attacks: known attack techniques developed against implementation flaws in SSL and early TLS, and the technical background to the retirement of TLS 1.0 and SSL 3.0.

Frequently Asked Questions

Q1: Does PCI DSS explicitly mandate TLS 1.2 or above?
The requirement text does not name TLS version numbers verbatim; it requires strong cryptography. But per the PCI SSC FAQ, neither TLS 1.0 nor TLS 1.1 meets the strong cryptography definition, so in practical terms TLS 1.2 becomes the minimum version threshold an organisation has to reach.

Q2: Can we still use TLS 1.1? Will it be written up?
TLS 1.1 currently sits at the "officially not recommended" level rather than "absolutely prohibited". If you are still using it, an assessment will usually ask you to set out the replacement timeline and the risk controls covering the transition period. Long term, plan the upgrade to TLS 1.2 or above.

Q3: What is the difference between TLS 1.3 and TLS 1.2? Do we have to upgrade?
TLS 1.3 streamlines the handshake, makes forward secrecy mandatory, and removes all known weak algorithms, so it outperforms TLS 1.2 on both security and efficiency. PCI DSS does not mandate TLS 1.3, but for core business systems and environments processing highly sensitive data, Secure Vectors recommends planning the upgrade first.

Q4: Do internal systems also have to meet the TLS version requirements?
If a system falls within the cardholder data environment (CDE), it must meet the PCI DSS strong cryptography requirement whether or not it is externally exposed. An internal system still running SSL 3.0 or TLS 1.0 will be recorded as an assessment finding just the same.

References

• PCI Security Standards Council FAQ, Article #1491, "Does PCI DSS define which versions of TLS must be used?", updated July 2026: pcisecuritystandards.org/faqs/1491
• NIST SP 800-52 Rev. 2, "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations": csrc.nist.gov/pubs/sp/800/52/r2/final
• NIST, "NIST Requests Public Comments on SP 800-52 Rev. 2", May 2026: nist.gov/news-events/news/2026/05/nist-requests-public-comments-sp-800-52-rev-2-guidelines-selection