PCI DSS and TLS: what the card rules actually require of your site

Updated August 2026 · about a 6-minute read

If your site touches card payments in any way, PCI DSS applies to you — and the part of it that trips people up on the technical side is almost always about TLS. The good news: this slice of the standard is far less scary than the acronym suggests. It comes down to encrypting card data properly in transit, not serving anything weak, and being able to show you kept it that way. Let me translate the requirement into what you actually have to do.

What Requirement 4 is really saying

Requirement 4 is the transmission one: protect cardholder data with strong cryptography whenever it crosses open, public networks. Strip away the formal language and it's three practical demands:

• Use strong TLS. TLS 1.2 is the floor; TLS 1.3 is better. This is non-negotiable for any page that transmits card data.
• Turn off the weak stuff. SSL and early TLS (1.0 and 1.1) were deprecated years ago. If your server still answers on them, that's a finding — even if nobody's using them, offering them is the problem.
• Use a valid certificate. Trusted CA, not expired, matching the hostname. An expired cert on a payment page isn't just an outage; it's a compliance hole.

That's the heart of it. Most modern hosts default to a decent TLS config, so plenty of sites are already compliant on this and don't realize it. The trouble is never the initial setup — it's the drift.

Where compliant sites quietly fall out of compliance

Here's the pattern I've watched play out. A site passes its assessment, everyone exhales, and then over the following year:

• A server gets rebuilt and someone re-enables TLS 1.0 "for an old client" and forgets to turn it off.
• The certificate quietly expires because the auto-renewal broke and nobody was watching.
• A load balancer or CDN config change reintroduces a weak cipher suite.

None of these announce themselves. The site keeps taking payments, and the compliance gap sits there until the next assessment — or until it's found the hard way. PCI DSS's whole model assumes controls stay in place continuously, not just on assessment day, which is exactly why "we set it up right once" isn't the same as "we're compliant."

An assessor doesn't just want to see that your TLS is strong today. They want confidence it was strong every day since the last time they looked. That's a different kind of evidence than a screenshot.

Headers matter more than people expect

Requirement 4 is about encryption in transit, and here's a subtle way that breaks: if your payment page is reachable over plain HTTP and doesn't enforce HSTS, an attacker on the network can try to downgrade the connection before TLS ever kicks in. So while headers aren't the letter of Requirement 4, HSTS directly protects the encryption the requirement demands — and it comes up. It's cheap insurance either way; the security headers guide covers how to add it.

How to stay compliant instead of scrambling

The sustainable version of PCI TLS compliance isn't an annual panic. It's:

1. Get TLS 1.2+ only, weak protocols disabled, valid cert. (Probably already true.)
2. Have something check that from the outside, continuously, so a regression is caught the day it happens.
3. Keep the dated records, so when the assessor asks "was this true all year?" you have the answer instead of a shrug.

That third point is the one people undervalue. The same continuous evidence that satisfies a PCI assessor is the evidence that satisfies SOC 2 and ISO 27001 — different frameworks, same dated record of "our TLS held." Set it up once and it pays into all three.