PCI-DSS 4.0 TLS Requirements, Explained Like You're Busy
Think of PCI-DSS as the health inspection your restaurant takes every year, except the restaurant is your business and the food is your customers' credit card data. The inspector has a checklist. You don't have to enjoy the checklist. You do have to know what's on it.
PCI-DSS 4.0 - the latest version of the standard - has been mandatory since March 31, 2024, with its "future-dated" requirements mandatory since March 31, 2025. If your organisation handles cardholder data, you are already subject to all of it. The grace period is over.
Most of PCI-DSS is about general security hygiene: firewalls, access control, logging, patching. But there is a specific set of TLS-related requirements that often get either glossed over or, alternatively, used as a cudgel by auditors who happen to like cryptography. This post is about those requirements, what they actually mean, and what you need to be able to show.
If you're trying to read the standard from cover to cover, you have my sympathies. This is the version you can read while drinking your coffee.
What changed in 4.0 (the TLS-relevant parts)
PCI-DSS 4.0 - and its minor revision 4.0.1, published June 2024 - tightened TLS requirements in three meaningful ways.
Inventory. The new requirement 4.2.1.1 mandates that you keep an inventory of trusted keys and certificates used to protect cardholder data - including where they live, who owns them, and when they expire. This sounds boring. It is the requirement most teams quietly fail.
Stronger crypto enforcement. Requirement 4.2.1 has always required "strong cryptography" for transmissions of cardholder data over public networks. In 4.0, the standard is more specific about what "strong" means - TLS 1.2 minimum, TLS 1.3 preferred, no SSL, no early TLS, and specific cipher suite expectations.
Risk-based deviations. 4.0 introduces a "customised approach" - you can deviate from the prescribed controls if you can document a risk assessment and a compensating control. This sounds permissive. It is. It's also where many audits go sideways, because the documentation bar is higher than most teams realise.
The first one - inventory - is the one that catches most teams. Let's start there.
Req 4.2.1.1 - The inventory requirement
Plain text: maintain an inventory of all keys and certificates used to protect cardholder data, including expiry dates and ownership.
What this actually means in practice:
- Every cert that touches a system handling cardholder data must be in a documented inventory. The inventory must include the cert's purpose, the system it protects, the expiry date, and a named owner. The inventory must be kept current. A spreadsheet last updated in 2023 does not count.
Why this is the hard one: most organisations have never maintained an accurate certificate inventory. They have spreadsheets that are mostly right. They have a CMDB that's mostly right. They have a person who mostly knows.
An auditor asks: "show me your inventory of all keys and certificates used to protect cardholder data." If the answer involves the words "let me check with Bob," you have already failed this requirement.
The fix is continuous, automated discovery - pulling from cloud accounts, CDNs, load balancers, internal CAs, and Certificate Transparency logs - reconciled into a single source of truth that updates itself.
Req 4.2.1 - Strong cryptography
Plain text: cardholder data in transit over any public network must use strong cryptography.
What this means:
- TLS 1.2 minimum. TLS 1.0 and 1.1 are no longer acceptable, full stop. If you have legacy systems still negotiating them, they need to be replaced or fenced off from cardholder data. TLS 1.3 strongly preferred. Not technically required, but auditors increasingly expect to see it where the technology supports it. No SSLv2, no SSLv3, no early TLS. Disabled everywhere. Cipher suite requirements. No RC4, no MD5, no NULL ciphers, no anonymous suites, no export-grade. Modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305) preferred. Forward secrecy. Configurations should support perfect forward secrecy - typically via ECDHE key exchange.
This is mostly a server configuration problem. The gotcha is internal systems that haven't been touched in five years. Old load balancers, legacy admin tools, archived endpoints that aren't externally facing but still process cardholder data - these are where TLS 1.0 still lives.
Reqs 2.2.5, 2.2.6, 2.2.7 - Secure configuration
These requirements aren't TLS-specific but they wrap around TLS configuration. Plain text: systems must be configured according to industry-accepted hardening standards; insecure services must be disabled.
For TLS, this means:
- A documented hardening baseline (often CIS, NIST, or PCI's own guidance). Configuration management that enforces the baseline (Ansible, Terraform, configuration scanning). Evidence that drift is detected and remediated.
The auditor will not ask you "is your TLS hardened?" They will ask "show me your hardening baseline, your scan reports, and three examples of drift detection in the last quarter."
What auditors actually look for
Auditors are not trying to catch you out. They are trying to confirm that you have systems, not heroics.
Specifically, on TLS:
- Can you produce the inventory in a meeting? (Not "we'll get back to you.") Can you show how the inventory stays current? (Not a one-time scan.) Can you produce evidence that TLS 1.0/1.1 is disabled everywhere? (Including the systems you forgot about.) Can you show ownership of each cert in the inventory? (Not a person's personal email.) Can you produce evidence of regular vulnerability scanning against TLS endpoints?
If the answer to any of these is "we have a spreadsheet," the answer is "no."
What you need to be able to show
For a clean PCI-DSS 4.0 TLS audit, three artifacts matter most:
- A live cert inventory, generated by automation, demonstrably current. A TLS configuration scan, run regularly, with evidence of remediation when issues are found. A named owner for every cert in scope, with that ownership living in a system that survives turnover.
TLS Radar gives you the first two out of the box. It will not write your hardening baseline for you, and it will not assign owners - those are your decisions. But "we have continuous external scanning of every cert in scope, with a complete inventory and audit history" is most of what an auditor wants to see.
One small ask
PCI-DSS 4.0 isn't trying to make your life harder. It's trying to make sure that the next time someone breaches a payments processor, the post-mortem doesn't say "they didn't know which certs they had." If you can answer that question today, you're most of the way there. If you can't, the free tier of TLS Radar is enough to find out.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.