PCI DSS v4.0.1 does not require a specific type of SSL/TLS certificate, and it never mentions Extended Validation, Organization Validation or Domain Validation. What Requirement 4.2.1 asks is that account data crossing open, public networks is protected with strong cryptography and secure protocols, that only trusted keys and certificates are accepted, and that the certificates doing that work are confirmed as valid rather than expired or revoked. Two further requirements turn that into paperwork: 4.2.1.1 wants an inventory of those keys and certificates, and 12.3.3 wants the cipher suites and protocols documented and reviewed at least once every 12 months. Both became mandatory on 31 March 2025.
If you landed here holding a scan report and a purchase decision, the short version is that compliance narrows your options far less than most vendor pages imply. Any publicly trusted certificate clears the bar, so the SSL certificates My-SSL issues through Certum are worth comparing on coverage and validation effort rather than on a compliance badge. Everything below is the reasoning, with requirement numbers you can quote back to an assessor.
Does PCI DSS require an SSL certificate?
Not in those words. Requirement 4.2.1 says that strong cryptography and security protocols must protect the primary account number whenever it is transmitted over open, public networks. On a website that means TLS, and TLS that a browser will complete means a certificate chaining to a root the browser already trusts. The certificate is how you satisfy the rule. It is not the rule.
The distinction matters more than it sounds, because it explains why two merchants can hold completely different certificates and both pass. The requirement is written against observable behaviour of a connection: what algorithms it negotiates, whether the peer’s certificate is trusted, whether that certificate is still valid. A scanner can test all three from outside. None of them ask what you paid.
Version matters when you are quoting the standard. PCI DSS v4.0.1 was published on 11 June 2024 and became the only active version once v4.0 retired on 31 December 2024, so an assessment running in 2026 is against v4.0.1. It is a limited revision that clarified wording rather than adding requirements, which is why the numbering below is identical to the v4.0 numbering you may have seen in older guidance.
Which requirements actually mention certificates?
Four, and they cover different objects. Requirement 4.2.1 governs the connection carrying cardholder data. Requirement 4.2.1.1 governs the list of keys and certificates protecting it. Requirement 12.3.3 governs the list of cipher suites and protocols in use. Requirement 2.2.7 covers encrypted administrative access, which is where the certificate on your management interface comes in. Knowing which number applies saves an argument during an assessment.
| Requirement | What it covers | In force since |
|---|---|---|
| 2.2.7 | Non-console administrative access encrypted with strong cryptography | v4.0 |
| 4.2.1 | Strong cryptography and secure protocols for PAN in transit; only trusted keys and certificates accepted; certificates confirmed valid, not expired or revoked | v4.0 |
| 4.2.1.1 | An inventory of trusted keys and certificates used to protect PAN during transmission | 31 March 2025 |
| 12.3.3 | Cipher suites and protocols in use documented and reviewed at least every 12 months, with a plan for cryptographic change | 31 March 2025 |
The 31 March 2025 date is the one that catches people out. Requirements 4.2.1.1 and 12.3.3 shipped inside v4.0 as future-dated items, which meant they were best practice during the transition and did not have to be met. That grace period ended, along with the other 50 future-dated requirements, and any assessment from that date onward treats them as ordinary requirements. Guidance written in 2023 or 2024 frequently still describes them as optional.
Does PCI DSS require an EV or OV certificate?
No. Extended Validation is not required by PCI DSS, and neither is Organization Validation. The standard’s certificate language is about trust and validity, and a domain-validated certificate from a publicly trusted CA is trusted and valid in exactly the sense Requirement 4.2.1 uses those words. Any page telling you that PCI compliance obliges you to buy EV is selling something.
That myth has a history. EV certificates once produced a green address bar carrying the company name, and it was easy to attach that visual to the idea of a payment-grade site. Browsers removed the green bar years ago, and the identity information moved into the certificate details where almost nobody looks. The compliance argument was never in the standard to begin with.
There are still honest reasons to pay for organization validation, and they are business reasons rather than audit ones. An OV or EV certificate carries a verified legal entity name, so anyone inspecting the certificate can see which company is behind the site, and some enterprise procurement and insurance processes ask for it explicitly. If that describes your situation, the differences are set out in our organization-validated certificate options and in the OV versus EV comparison. Choose it because you want the vetting, not because you think an assessor will demand it.
One caveat worth stating plainly: your acquirer, payment gateway or a customer contract can impose requirements that PCI DSS does not. Those are real obligations and they are enforceable against you. They are simply not PCI DSS, and it is worth knowing which document a demand comes from before you buy against it.
Which TLS version does PCI DSS require?
Requirement 4.2.1 does not name one. It asks for strong cryptography and secure protocols, and the floor is assembled from two other documents: the PCI SSC glossary, which defines strong cryptography as industry-tested, accepted algorithms providing at least 112 bits of effective key strength with proper key management, and the council’s migration guidance, which set 30 June 2018 as the point after which SSL and early TLS could no longer be used as a security control to meet PCI DSS requirements. TLS 1.2 is where those two lines meet.
In practice this is settled: TLS 1.2 is the minimum an assessor or an ASV scan will accept on a public-facing service, TLS 1.3 is better on both security and handshake latency, and TLS 1.0 and 1.1 are findings. If you are still running the older versions for a legacy client, that is a compensating-controls conversation rather than a configuration preference, and it is one you want to have before the scan rather than after it.
Key strength is the other half of the same sentence and gets less attention. The 112-bit floor is what rules out 1024-bit RSA, and it is comfortably met by the 2048-bit RSA or P-256 ECDSA keys any public CA will issue today. Our comparison of ECC and RSA keys covers the trade-off if you are choosing between them, and the guide to reading cipher suites is the practical companion to Requirement 12.3.3, since that requirement asks you to write down exactly what your servers negotiate.
Are self-signed certificates allowed?
Not on anything an ASV scan can reach. A self-signed certificate cannot meet the expectation that only trusted keys and certificates are accepted, because the only party vouching for it is the server presenting it, which is precisely the assurance a certificate is supposed to provide. Expired certificates fail the same clause for a different reason. Both are routine findings in scan reports.
The surprise for most teams is not the web server. It is everything else listening on a public IP address: mail ports running POP3, IMAP and SMTP, management consoles, a hypervisor interface someone exposed years ago for convenience. ASV scanning covers services rather than websites, and a default self-signed certificate on port 993 fails just as cleanly as one on port 443.
Internal systems are judged on their own terms. PCI DSS does not extend Requirement 4.2.1 to traffic that never crosses an open, public network, and an internal CA can be a perfectly reasonable answer inside a datacentre as long as the keys are managed properly and the relying systems genuinely trust that CA. What does not change is the record: an internally issued certificate protecting cardholder data still belongs in the 4.2.1.1 inventory. We cover the trade-offs in the guide to when a self-signed certificate is appropriate.
The inventory requirement most people miss
Requirement 4.2.1.1 asks that an inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. It is one sentence, it has been mandatory since 31 March 2025, and it is the requirement organisations most often discover late, because unlike a TLS setting there is nothing on a server to switch on. Somebody has to build a list and keep it true.
The standard does not dictate the format, and the council has noted that recording the issuing CA and the expiry date is good practice. A list that survives contact with an assessor generally holds, for every certificate in scope: where it is installed, which hostnames it covers, which CA issued it, its key type and strength, when it expires, and who is accountable for replacing it. The last column is the one that turns an inventory into something operational rather than decorative.
Requirement 12.3.3 sits next to it and is frequently conflated with it. That one is about cipher suites and protocols rather than certificates: what your systems negotiate, whether those choices remain viable, and what you will do when they stop being viable. It carries an explicit cadence, a review at least once every 12 months, which 4.2.1.1 does not. Treating them as one task is how organisations end up with a tidy certificate spreadsheet and no protocol documentation at all.
Building the first inventory is usually the hard part, and discovery almost always turns up more than expected: certificates on load balancers nobody documented, a wildcard reused across four environments, an expired certificate on an internal service still quietly serving traffic. Our guide to certificate management covers the discovery and tracking side in more depth.
Why 200-day certificates changed this in 2026
PCI DSS did not change in March 2026. The certificates did. Under CA/Browser Forum ballot SC-081v3, approved in April 2025, the maximum validity of a publicly trusted TLS certificate dropped to 200 days on 15 March 2026, falls to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Requirement 4.2.1 still says no expired certificates and 4.2.1.1 still says keep an inventory, but both obligations now have to survive roughly twice as many replacement events per year as they did in 2025.
Run the arithmetic across an estate and the shape of the problem shows up quickly. Forty certificates on 398-day terms produced something like forty renewals a year, which one person could track in a spreadsheet with calendar reminders. The same forty on 200-day terms produce around eighty, and the same estate in 2029 produces well over three hundred. The failure mode is not that a renewal is difficult. It is that the list stops reflecting reality between assessments.
This is where the two requirements start pulling in the same direction. An inventory maintained by hand is exactly what breaks under that cadence, which makes automated issuance and automated discovery the sensible response rather than a nice-to-have. Certificates issued through ACME and Certbot renew themselves and can be enumerated from the client’s own state, which happens to answer the inventory question at the same time. Our guide to preparing for 47-day certificates works through the migration in more detail.
A certificate checklist for your next assessment
Most certificate findings come from a short list of conditions, and all of them are testable before anyone else tests them. Work through these on every host in scope, not only the ones you think of as the website, and the certificate section of an assessment tends to be uneventful.
- Every public-facing service presents a publicly trusted certificate. Web, mail and API endpoints alike. No self-signed certificates, no internal CA on anything reachable from the internet.
- Nothing is expired. Check the actual expiry dates rather than trusting the renewal you remember doing, and confirm no certificate in scope has been revoked.
- The chain is complete and the hostname matches. A missing intermediate certificate is one of the most common causes of an otherwise valid certificate failing a scan.
- TLS 1.2 or 1.3 only, with weak cipher suites disabled. TLS 1.0 and 1.1 are disabled everywhere, including on mail and administrative ports.
- Keys meet the 112-bit floor. 2048-bit RSA or P-256 ECDSA and above. Anything older on a legacy host needs replacing rather than documenting.
- The 4.2.1.1 inventory exists and is current. Location, hostnames, issuing CA, key strength, expiry and an accountable owner for each entry.
- The 12.3.3 documentation exists and was reviewed within 12 months. Cipher suites and protocols in use, plus a written plan for responding to cryptographic change.
- Administrative access is encrypted. Requirement 2.2.7 covers the management interfaces that certificate inventories tend to forget.
If a scan has already flagged something, our reference on what each SSL certificate error means maps the common messages to their causes, and the certificate chain guide covers the missing-intermediate case specifically.
Buy for the estate you have to maintain
Since compliance does not pick the validation level for you, the useful questions are how many hostnames one certificate has to cover and how much validation work each renewal will cost you now that renewals come around twice a year. Our Certum certificate options and pricing set out coverage, validation level and the documents each product asks for, so you can judge both before the next assessment window opens.
Related reading
- Which SSL certificate do I need? — the decision without the compliance folklore attached to it.
- The 200-day certificate limit — what changed on 15 March 2026 and why renewals doubled.
- Certificate management — building the inventory Requirement 4.2.1.1 asks for.