PCI DSS 12.3.3 In Plain Language: The Cryptographic Inventory You Already Owe

If your organisation stores, processes or transmits payment card data, you are probably assessed against the Payment Card Industry Data Security Standard (PCI DSS). Version 4.0 introduced a requirement that has applied in full since 31 March 2025: requirement 12.3.3, which asks you to document and regularly review the cryptography you use.

This article explains the requirement in plain terms, the evidence a Qualified Security Assessor (QSA) is likely to ask for, and why the same work is the starting point for quantum readiness. It refers to PCI DSS v4.0.1, published in June 2024; check the PCI Security Standards Council (PCI SSC) document library for any later version before relying on the detail.

What Requirement 12.3.3 Asks For

Requirement 12.3.3 covers the cryptographic cipher suites and protocols in use. A protocol is the set of rules for a secure connection, such as TLS 1.2, TLS 1.3 or SSH. A cipher suite is the named set of algorithms a connection agrees to use. In TLS 1.2 the suite name covers key exchange, authentication, encryption and integrity together. In TLS 1.3 it names only the encryption and hash algorithms; key exchange groups and signature algorithms are negotiated separately, so an inventory needs its own fields for them.¹

Under the requirement, you keep documentation of the cipher suites and protocols your environment relies on and go back over it at least once every 12 months. As a minimum, that documentation holds three things:²

• a current list of every cipher suite and protocol you rely on, noting the job each one does and the systems where it runs;
• an active watch on industry developments that could make any of them unsafe to keep using; and
• a written plan for how you will react to cryptographic weaknesses you can see coming.

The scope is wider than it may first appear. According to the applicability notes, any cipher suite or protocol used to meet a PCI DSS requirement is covered. That includes the cryptography that hides the primary account number (PAN, the card number) when it is stored or sent, the cryptography guarding passwords, and the cryptography involved when people and systems prove who they are before gaining access.²

Requirement 12.3.3 was new in PCI DSS v4.0 and was one of its future-dated requirements.³ The standard treated it as a best practice until 31 March 2025. Since that date it has been required, and assessors must take it fully into account.²

Why The Requirement Exists

Cryptography ages. Protocols and algorithms that were once standard have repeatedly been found unsafe and had to be retired. When that happens, organisations that do not know where the affected cryptography runs face a slow and expensive search before they can fix anything.

Requirement 12.3.3 is designed to prevent that from happening again. Its stated objective is that an organisation can react quickly when a weakness in a cryptographic protocol or algorithm affects the protection of cardholder data. The guidance links this to cryptographic agility, the ability to move to a replacement algorithm or method without rebuilding the systems that rely on it.² If you know what you run and where, and you are watching for trouble, you can respond to the next weakness in an orderly way rather than in a rush.

What An Assessor Will Look For

A QSA tests whether the requirement is in place and working. In practice, that means documents and records that line up with each other and with what is running.

An inventory becomes unreliable when it is built once from a spreadsheet and never compared with reality. Assessors can test samples against live systems. An entry that says a server only accepts TLS 1.2 and above is easy to check with a scan.

Building The Annual Cycle

The requirement is easier to meet if it is treated as a repeating process rather than a document produced before each assessment.

Automated discovery helps a great deal. The US federal migration memo of June 2026 makes the same point for government agencies, recommending network scanners to detect protocols and cipher suites rather than relying on manual records.⁴

How 12.3.3 Connects To Quantum Readiness

Requirement 12.3.3 is written in general terms rather than about any particular threat, and the v4.0.1 text does not mention quantum computing.² Its purpose is to make sure you know what you use and can react when what is safe changes. Quantum computing is one of the biggest such changes on the horizon.

The annual review is where this shows up. NIST, the US standards body, proposes in a draft transition report to deprecate some uses of quantum-vulnerable public-key algorithms such as RSA and elliptic curve cryptography after 2030, and to disallow them entirely after 2035.⁵ The monitoring element of 12.3.3 is where an organisation would pick up a proposal like this, and the documented plan is where its response belongs.

The inventory is also an early step in every major quantum migration roadmap. The UK National Cyber Security Centre, for example, asks organisations to complete a full discovery exercise by 2028.⁶ A well-maintained 12.3.3 inventory covers a large part of that discovery work for the payment environment.

Common Gaps

Examples of gaps worth checking before an assessment include:

• Only external endpoints are covered. Internal connections between payment systems, databases and management interfaces also use protocols and cipher suites.
• Vendor and cloud services are missing. Managed load balancers, payment gateways and hosted services negotiate their own cipher suites, and these need recording too.
• No evidence of the review. A team may follow industry news informally but be unable to show it. Brief dated notes of what was reviewed and concluded help an assessor see that the review happened.
• A generic plan. The requirement calls for a written plan for reacting to foreseeable cryptographic weaknesses. A plan that only promises updates when needed gives an assessor nothing to test. Name owners, triggers and steps.