Since 31 March 2025, PCI DSS v4.0.1 requirement 12.3.3 is no longer a best practice but a requirement. It asks entities to document the cryptographic cipher suites and protocols in use and to review them at least every twelve months. It is one of the few rules that already forces a large number of mid-sized companies to produce a cryptographic inventory, and it is a natural starting point for post-quantum preparation.
This guide is practical information, not legal advice. Your Qualified Security Assessor decides how the requirement applies to your environment.
What the requirement says
The documentation must be reviewed at least once every 12 months and include at least:
- an up-to-date inventory of all cryptographic cipher suites and protocols in use, including their purpose and where they are used;
- active monitoring of industry trends regarding the continued viability of those cipher suites and protocols;
- a documented strategy to respond to anticipated changes in cryptographic vulnerabilities.
The third point is where post-quantum cryptography comes in: the retirement of RSA and elliptic curves announced by NIST, and the migration dates set by the EU, are precisely such anticipated changes.
Step 1: define the scope
Start from your cardholder data environment and every system connected to it: public websites and APIs, payment pages, load balancers, VPNs, internal service-to-service links, databases with TLS, and connections to your payment service providers. List each endpoint with its owner.
Step 2: collect what is exposed externally
For every public endpoint, record the protocol versions and the cipher suites the server actually accepts, not what the configuration file seems to say. An external scan gives you the real list. The PQC Status scanner enumerates every accepted suite per TLS version, the negotiated key exchange group and the certificate chain, which covers the external part of the inventory.
Step 3: collect what is internal
Internal links are usually the blind spot. Export the TLS settings of load balancers, reverse proxies, message brokers and database servers, and check the libraries used by your applications. Record the same fields as for external endpoints.
Step 4: document each entry
A simple table is enough, as long as it is complete and dated:
| Field | Example |
|---|---|
| System and endpoint | Checkout API, api.example.com:443 |
| Purpose | Transmission of card data from browser to API |
| Protocols | TLS 1.2, TLS 1.3 |
| Cipher suites | TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, ECDHE-ECDSA-AES128-GCM-SHA256 |
| Key exchange | X25519MLKEM768 (hybrid post-quantum), fallback X25519 |
| Certificate | ECDSA P-256, SHA-256, expires 2026-12-01 |
| Owner | Platform team |
| Last reviewed | 2026-09-28 |
| Status and action | Compliant; remove TLS 1.2 CBC suites in Q1 |
Step 5: monitor viability
Assign someone to follow changes that affect your entries: deprecations by NIST, new guidance from national agencies, vulnerabilities in protocols. Our algorithm reference tracks the official position of each authority for each algorithm, with its source.
Step 6: write the response strategy
The strategy explains what you will do when an algorithm becomes weak. For the quantum threat, it can be short and concrete:
- enable hybrid post-quantum key exchange on external endpoints first, because they carry traffic that can be recorded today;
- remove TLS 1.0, 1.1 and weak suites that are already obsolete;
- plan certificate and signature migration once post-quantum certificates are available from your providers;
- align the timeline with official deadlines, such as NIST's deprecation of 112-bit RSA and elliptic curves after 2030 (draft IR 8547).
Step 7: repeat every year
The requirement is a cycle, not a one-off. Keep the inventory in version control or in a tool, date every review, and rescan external endpoints after each infrastructure change. Automating the external part is the easiest way to keep the document true between reviews.