PCI DSS 12.3.3: the cryptographic inventory your QSA actually wants

Since March 31, 2025, PCI DSS v4.0.1 requirement 12.3.3 has been mandatory for every entity assessed with a Report on Compliance or SAQ D. That covers most of the payments industry: gateways, processors, payment facilitators, billing and subscription platforms, POS software vendors, and fintechs with card programs.

The requirement reads simply and bites hard. You must maintain a documented inventory of all cryptographic cipher suites and protocols in use, including where each is used and for what purpose, review it at least annually, monitor industry developments that affect those algorithms, and keep a documented strategy for responding when an algorithm weakens. Its companion, requirement 4.2.1.1, asks for an inventory of the trusted keys and certificates that protect cardholder data in transmission.

What assessors ask for in practice

When the QSA reaches 12.3.3, they want to see four things: a current list of every cipher suite and protocol in scope, the purpose and location of each, evidence the list was reviewed within the last year, and evidence that the review was more than a rubber stamp. "In use" is the phrase that catches teams out. The inventory is not what your policy says you use. It is what your systems actually negotiate, in TLS configurations, in SDK defaults, in database encryption settings, in the dependency you added three years ago and forgot.

Why the spreadsheet hurts

Most teams satisfy 12.3.3 with a spreadsheet, and assessors accept that. The cost is hidden in the work: an engineer-week of grepping code, reading load balancer configs, and interviewing service owners, producing a document that starts going stale the day it is finished. Next year, the same week again, usually by someone who has to rediscover where everything lives.

The deeper problem is trust. A hand-built list is a claim by the party being assessed. Nothing about it proves completeness or currency. Your assessor accepts it because the alternative has been nothing.

What good looks like

A defensible inventory has a few properties. It is generated from the systems themselves rather than from memory. It records algorithm, protocol version, location, and purpose for each entry. It is dated, so the annual review requirement is provable rather than asserted. And increasingly, it is machine-readable, so next year's review is a diff instead of an excavation. There is now a standard format for exactly this: the CycloneDX 1.6 cryptographic bill of materials, or CBOM, which represents each algorithm with its properties, including how exposed it is to quantum attack.

The quantum column you did not know you needed

Requirement 12.3.3 explicitly expects you to monitor industry trends and plan for algorithm change. The largest algorithm change in the industry's history is scheduled now: NIST's transition guidance deprecates today's classical public-key cryptography over the coming decade, and United States federal policy already sets procurement dates for post-quantum systems. A cryptographic inventory that classifies each algorithm's quantum exposure answers the trend-monitoring half of 12.3.3 and doubles as the first deliverable of any post-quantum migration plan.

Doing this in an afternoon

We built a free scanner that produces the inventory from your code and configuration and classifies every finding, including quantum exposure, into a CycloneDX 1.6 CBOM. Run it inside your own environment; nothing leaves. If you need the QSA-ready version, we turn your scanner output plus a short guided questionnaire into a signed report covering 12.3.3 and 4.2.1.1, with every attested section labeled as such, delivered within one business day. The signature is verifiable with our open-source offline verifier, so your assessor does not have to trust you, or us.

The scanner is free at scrutari.ai/pci. The signed report is $990, and the signature date makes next year's annual-review evidence automatic.