Start free trial

By Yair Knijn · November 19, 2025

PCI DSS 4.0 wants a cryptographic inventory. Your cardholder estate doesn't have one.

Three clean PCI assessments in a row teach a compliance director that the next one is a re-run: same scope, same evidence, new clause numbers. So the 4.0 cycle gets booked like routine maintenance. That booking is the mistake. The future-dated requirements went live on 31 March 2025, and two of them ask for an artifact your cardholder data environment has almost certainly never produced as a standing record: an inventory of the keys, certificates, cipher suites, and protocols protecting account data.

This is not a discipline problem. The previous standard never asked for that inventory as a maintained list, so nobody kept one. Under 4.0 an estate without it is non-compliant by construction, not merely untidy.

Requirements 4.2.1.1 and 12.3.3

Requirement 4.2.1.1 reads plainly: maintain an inventory of the entity's trusted keys and certificates used to protect PAN over open, public networks. Requirement 12.3.3 reaches further. It wants the cipher suites and protocols in use documented and reviewed at least once every twelve months, each with its purpose and location, plus active monitoring of whether each remains viable and a written plan for when one breaks.

Read the two together and the obligation is not a spreadsheet you assemble for the assessor. It is a living record with a review cadence and a deprecation plan attached. An inventory accurate on audit day and stale a week later fails 12.3.3, because the clause is about ongoing review, not a snapshot.

Why three passing 3.2.1 audits never built this

Under the older standard, an assessor confirmed strong cryptography on the links carrying PAN. TLS 1.2 with an approved suite on the payment gateway, evidence captured, control passed. Nobody had to enumerate every certificate, trust anchor, and negotiated cipher across the environment and write it down. Demonstration satisfied the control; inventory did not enter into it.

So a clean 3.2.1 history tells you the crypto was probably right on the paths someone checked. It says nothing about the certificate on an internal load balancer, the legacy TLS 1.0 listener on a forgotten admin interface, or the wildcard key issued four years ago and renewed by someone who has since left. The question was never asked in this shape.

Weak protocols and dead certs are exposure, not paperwork

The standard demands the list because the gaps it exposes are real. An expired certificate on a PAN-carrying endpoint either drops the connection or conditions operators to click through warnings until a genuine man-in-the-middle rides in behind one. A deprecated protocol still accepting connections is a downgrade target. A key whose owner left and whose rotation date nobody tracks is an incident waiting for its trigger. The list is what makes any of this findable before it bites. The recurring offenders are predictable:

Make the inventory a byproduct, not a sprint

The way through is to let the inventory fall out of how certificates get issued and renewed, instead of mounting a separate evidence hunt before each assessment. When every issuance records the owner, the endpoint, the protocol and suite, and the renewal mechanism, the 4.2.1.1 list and the 12.3.3 review write themselves, and the assessor reads a current record rather than an archaeological dig.

That is the shape Automate Certificates is built around. Each Environment keeps a live record of every key and certificate it manages, with expiry, owner, and negotiated protocol surfaced continuously instead of reconstructed under audit pressure. To find out whether your cardholder estate could produce that inventory today, map what you have against 4.2.1.1 and 12.3.3, then close the gap before the assessor does. Our security documentation walks through how the record is kept.