The standards most audits point to are the TLS protocol itself, RFC 8446 for version 1.3, and NIST SP 800-52 Rev. 2, which tells organisations how to select and configure TLS. In practice: support TLS 1.3 and 1.2 with strong cipher suites, disable everything older, and keep certificates valid and well managed.
What is the difference between SSL and TLS?
SSL is the older name. The protocol was renamed TLS when it was standardised, and every SSL version is now obsolete. When someone says "SSL certificate" they almost always mean a certificate used with TLS. Compliance language still says SSL in places, so read it as TLS.
What does RFC 8446 change?
RFC 8446 defines TLS 1.3. It removes older, weaker options from the protocol rather than leaving them to configuration. That is the point: fewer choices means fewer misconfigurations. A server that speaks TLS 1.3 cannot be talked down into some of the legacy features that caused earlier attacks, though it can still be configured to accept older versions if you let it.
Read the RFC's security considerations when you need to defend a choice to an auditor. It is the primary source, and it is short compared with how often it is paraphrased badly.
What does NIST SP 800-52 Rev. 2 require?
Its abstract says it guides selection and configuration of TLS implementations using FIPS and NIST recommended cryptographic algorithms. It requires that TLS 1.2 configured with FIPS based cipher suites be supported by all government TLS servers and clients, and requires support for TLS 1.3 by 1 January 2024. It also covers certificates and TLS extensions.
Strictly, those requirements bind US federal systems. Many private frameworks and customer questionnaires borrow them as the reference, which is why the document shows up in non government audits.
What do auditors actually ask for?
Expect questions in four groups.
- Protocol versions: which are enabled on each public endpoint, and is anything below TLS 1.2 on?
- Cipher suites: are weak ones disabled, and is forward secrecy used?
- Certificates: who issues them, how long they last, how renewal is tracked, and who is paged on expiry.
- Evidence: scan output or configuration exports with dates, not a statement that it is fine.
Internal traffic counts too. A frequent finding is a strong public edge with plain HTTP or old TLS between internal services.
Do certificate lifetimes belong in this conversation?
Yes, and they are getting shorter. The CA/Browser Forum Baseline Requirements set a maximum validity of 200 days for subscriber certificates issued from 15 March 2026, with further reductions scheduled for 2027 and 2029. Any process that relies on a person renewing a certificate once a year will fail the new schedule, so automated issuance and renewal is now a compliance topic as much as an operations one.
A constructed example
A company answers a customer questionnaire by saying "we use TLS 1.2 or higher." A scan of their endpoints shows the marketing site and API are fine, but a legacy reporting host still accepts TLS 1.0 and an older cipher suite, and an internal queue uses a self signed certificate that expired last year.
The honest answer was "TLS 1.2 or higher on all public endpoints except one host being retired on a stated date." That is a better answer to an auditor than a clean claim that a scan contradicts.
How to check or apply this
- List every endpoint that terminates TLS, public and internal, including load balancers, CDNs, mail and databases.
- Scan each for enabled protocol versions and cipher suites, and save the dated output.
- Disable TLS 1.1 and older everywhere. Disable cipher suites that lack forward secrecy.
- Turn on TLS 1.3 where your stack supports it.
- Inventory certificates with issuer, expiry and owner, and alert well before expiry.
- Add HTTP Strict Transport Security on web endpoints that are fully on HTTPS.
- Rescan after every infrastructure change and on a schedule.
- Write down exceptions with an owner and an end date.
Quick check
Is TLS 1.2 still acceptable?
Yes, with strong cipher suites. NIST SP 800-52 Rev. 2 requires TLS 1.2 support for federal systems alongside TLS 1.3. Versions below 1.2 should be off.
Does using TLS make me compliant?
No. Frameworks ask for correct configuration, certificate management and evidence. TLS is one control among many.
Sources
- RFC 8446, The Transport Layer Security Protocol Version 1.3
- CA/Browser Forum Baseline Requirements
- NIST SP 800-52 Rev. 2, Guidelines for TLS Implementations
Last reviewed: 18 October 2026.
