PCI DSS 12.3.3: how to build the cryptographic inventory your QSA will ask for

If you take card payments, you already owe your QSA a document most teams have never written: a documented inventory of the cryptography you use. Not next year, not when a quantum computer exists — since 31 March 2025, when PCI DSS v4.0 requirement 12.3.3 became mandatory (PCI DSS v4.0.1, §12.3.3).

This is a payments-compliance story, not a quantum one. The quantum part is two sentences at the end. Right now the requirement is simply: write down what you run, and confirm none of it is broken.

What 12.3.3 actually asks for

The requirement has three parts. You need to maintain:

1. An inventory of the cipher suites and protocols in use, including where they are used and for what.
2. A documented review, at least once every 12 months, of which of those are still acceptable — and which are being deprecated by the industry.
3. A plan to respond when something you depend on stops being acceptable.

That is the whole thing. There is no template mandated, no tool required, no "quantum readiness" language in the text. An auditor wants a list, kept current, that proves you know what your systems use and that you looked at it in the last year.

The trap is not the format. It is that almost nobody can produce the list, because the cryptography is scattered across places a person cannot hold in their head.

What a good inventory looks like

Concretely, a row per cryptographic asset, with columns an assessor can work with:

The "status" column is the one the QSA cares about, and it is where an honest inventory earns its keep: it surfaces the SHA-1 and MD5 and RSA-1024 that nobody meant to still be running. You want to find those before the assessor does.

You can start from a blank version of exactly this — the free inventory template (.xlsx) has the columns, dropdowns and a deadline map already in it.

Why you cannot grep your way to it

The reason 12.3.3 is hard is that cryptography hides in at least ten different places, and searching your source for AES finds almost none of them:

• the crypto your code calls;
• the crypto your dependencies ship, whether or not you call it;
• the suites your nginx / Apache / HAProxy config will accept;
• the key specs your Terraform will mint on the next apply;
• the certificates in your JKS / PKCS#12 keystores;
• the algorithms your TLS and SSH endpoints actually present;
• the signing keys in your JWKS;
• the keys and certs in your cloud KMS / ACM that never touch a disk.

Miss any of those and the inventory flatters you — which is worse than no inventory, because now it is a document that says you looked and didn't.

Building one in an afternoon

This is the job PQLens does. Point it at each surface and it classifies every finding — broken/deprecated, quantum-vulnerable, quantum-weakened, or PQC-ready — with the algorithm, key size and exact location. Here is a real run against a small service:

PQLens 0.7.0 — scanned demo
4 crypto asset(s), 4 occurrence(s)

  BROKEN / deprecated: 2
  QUANTUM-VULNERABLE:  2

STATUS              ALGORITHM  LIBRARY              LOCATION
broken              SHA-1      node/crypto          demo/app/sign.js:4
broken              MD5        python/hashlib       demo/app/tokens.py:5
quantum-vulnerable  ECDSA      node/crypto          demo/app/sign.js:3
quantum-vulnerable  RSA-2048   python/cryptography  demo/app/tokens.py:8

Two of those four are the "remediate" rows that make an assessor nervous, found in seconds. Run the source scan across your repos, the TLS scan across your endpoints, and the other surfaces, then merge them into one consolidated list you can export straight to Excel. The full walkthrough is in the cryptographic inventory guide.

Everything runs locally. Nothing about your code, configs or certificates leaves the machine — which matters, because the last thing a PCI-scoped shop needs is a second tool uploading its crypto posture somewhere.

The two-sentence quantum part

The reason PCI added 12.3.3 now, rather than leaving cryptography as an implicit control, is that the industry has started deprecating the public-key algorithms almost everything currently depends on — NIST plans to deprecate RSA and ECDSA after 2030 and disallow them after 2035 (NIST IR 8547 draft). When that migration lands, the organisations that already have an inventory will do a data migration; the ones that don't will do an archaeology project first. The deadline map has every dated requirement with its source.

Either way it starts with the same afternoon of work. You can do it with the free scanner today.