How to build a PCI cipher suite inventory

What 12.3.3 requires

Requirement 12.3.3 of PCI DSS v4.0.1 has been in force since 31 March 2025. It is no longer a future-dated best practice — it is a mandatory control. In plain terms, it asks you to do three things and keep evidence of all three.

• Document what is in use. Maintain an up-to-date inventory of every cryptographic cipher suite and protocol used to protect cardholder data, including where each one is used.
• Review at least every 12 months. Re-confirm the inventory annually and whenever the environment changes, actively watching for anything weak or deprecated.
• Keep a response plan. Document how you will respond to anticipated changes in cryptographic viability, so a deprecation does not catch you mid-assessment.

The above paraphrases PCI DSS v4.0.1, Requirement 12.3.3. Read the official standard for the exact wording. For the full breakdown, see our 12.3.3 overview.

What counts as a cryptographic inventory

An inventory under 12.3.3 is more than a list of TLS versions on your load balancer. To satisfy an assessor, it has to capture the cryptography actually in use across your cardholder-data environment — and tie each entry to a location. A defensible cryptographic inventory typically records:

• Each protocol and version negotiated (TLS 1.2, TLS 1.3, and any lingering early TLS).
• The specific cipher suites enabled, including key-exchange, authentication, bulk-encryption, and MAC algorithms.
• Key types and sizes (RSA-2048, ECDSA P-256, AES-256-GCM, and so on).
• Hash and signature algorithms in use, including any deprecated SHA-1 usage.
• Where each item lives — the service, hostname, source file, or config that introduces it.
• A viability note: current, deprecated, or quantum-vulnerable.

A bare spreadsheet of "we use TLS 1.2" will not survive scrutiny. The control is about knowing your cryptography by location and condition — which is exactly why a machine-generated artifact beats a hand-built one.

How to build one

Cryptography hides in three different surfaces, and most teams only look at one. A complete inventory covers all of them:

1. Source code. Hard-coded algorithms, cipher constants, certificate-pinning logic, and library calls. Network scanners never see these because they only observe what is negotiated at runtime.
2. Configuration. java.security, OpenSSL configs, web-server and load-balancer TLS policy, and JVM properties. This is where weak suites are quietly re-enabled.
3. Live endpoints. What each service actually negotiates on the wire. Source-only tools miss this because runtime behavior can differ from the config you think is deployed.

Once collected, normalize the findings into a single machine-readable artifact, map each entry to its 12.3.3 reference and a viability note, and store it so you can diff it year over year. The output format that auditors and tools both understand is a CycloneDX CBOM — a cryptographic bill of materials. We explain why in CBOM as QSA evidence.

Common QSA findings

When assessors review a 12.3.3 inventory, the same gaps come up again and again:

• Stale spreadsheets. An inventory rebuilt by hand the week before assessment, with no evidence it reflects production.
• Network-only scope. A scan of public endpoints that ignores source code and internal services entirely.
• Early TLS still negotiable. TLS 1.0/1.1 enabled on an internal service or legacy listener. See TLS 1.0 and PCI in 2025.
• Weak suites re-enabled in config. Export-grade or CBC suites switched back on for a single legacy integration and never removed.
• No viability/response plan. An inventory with no notes on what is deprecated and no documented plan for replacing it.
• No annual-review trail. No evidence the inventory was actually reviewed in the last 12 months.

Every one of these is avoidable when the inventory is generated from your real environment, mapped to the requirement, and re-runnable on a schedule.