What PCI DSS 4.0 Requirement 12.3.3 Asks of Your Cryptography

Most PCI DSS requirements describe a control you put in place and then produce evidence for. Requirement 12.3.3 instead asks you to keep something true between assessments, about a part of the estate that changes without anyone deciding to change it.

What Requirement 12.3.3 asks for

Requirement 12.3.3 asks an organization to maintain a documented inventory of the cryptographic cipher suites and protocols in use, and to review that inventory at least every 12 months. The standard is published by the PCI Security Standards Council, whose document library carries the current revision as PCI DSS v4.0.1. The list is the starting point rather than the deliverable. Alongside it, 12.3.3 asks the organization to monitor whether the algorithms on the list remain viable, to document how it will respond when one of them stops being viable, and to act on that plan when a cryptographic weakness reaches data it is responsible for.

Those four parts describe a continuing responsibility rather than an annual document. An inventory assembled the month before an assessment satisfies the first part and says nothing about the other three, because it cannot show that anything was being monitored in the eleven months nobody was looking.

Why a payment estate makes this hard

Cryptography in a payment environment has not been confined to the cardholder data environment for a long time. It sits in cloud infrastructure, internal and external APIs, service-to-service traffic, machine identities, internal certificate authorities, build pipelines, VPN concentrators, network equipment, and the third-party platforms that carry part of a transaction.

That spread is what makes the inventory a different kind of problem from the one the requirement sounds like. Finding the certificates on public endpoints is tractable. Answering which cipher suites two internal services negotiate with each other, and who owns the certificate authority that issued them, generally is not, and neither question has an owner in most organizations.

Vendors compound it. A third party that describes its encryption as strong without naming an algorithm, a key length or a protocol version has given you nothing you can put in an inventory, and nothing you could assess for viability later.

Where the inventory breaks

The failure is rarely that nobody built one. It is that the one that was built stopped being true.

Nothing holds the record in one place

Certificates, TLS configurations, cipher suites, key lengths, cryptographic libraries and internal PKI relationships tend to be recorded in different systems by different teams, or not recorded at all. A spreadsheet assembled from those sources is accurate on the day it is compiled.

Legacy systems do not answer questions

Older applications often carry cryptographic dependencies nobody documented, and the only way to learn what they negotiate is to look at what they put on the wire.

Certificates get issued in more than one place

When business units, cloud accounts and development teams can each issue certificates, the result is several trust hierarchies that no single team can enumerate. Those are the certificates most likely to expire without warning.

The estate moves between reviews

Cloud providers change encryption defaults, applications add dependencies, and cipher suites are deprecated on someone else’s schedule. An organization can fall out of alignment with its own documented inventory without any change it made.

Continuous cryptographic discovery addresses this directly, by taking the inventory from live traffic rather than from documentation that has to be maintained by hand.

Responding to a weak algorithm is the half that gets skipped

The part of 12.3.3 that asks for a documented response plan is the part an inventory alone cannot satisfy, and it is the harder commitment. Knowing that a deprecated algorithm is in use somewhere is worth little if changing it means a coordinated release across every application that depends on it.

This is crypto-agility: being able to change algorithms, cipher suites, certificates and keys without an outage and without rewriting the applications behind them. Cryptographic standards keep moving, and each move has arrived on someone else’s timetable. SHA-1 was deprecated, older TLS versions were retired, and certificate validity periods have been shortened more than once.

An organization that can answer a cryptographic weakness by changing a policy is describing a response plan an assessor can read. One that would have to schedule a migration project is describing an intention.

What this sets up for post-quantum migration

PCI DSS 4.0 does not require post-quantum cryptography. What it requires is the groundwork any cryptographic transition needs, which is why the two are worth planning together rather than in sequence.

Payment infrastructure is exposed to the quantum question for reasons that have nothing to do with PCI DSS. It depends heavily on public-key cryptography, transaction records hold value for years after they are written, and the dependencies run through systems that are difficult to change quickly. Migrating any of that starts with knowing where RSA and elliptic-curve cryptography are in use, which systems depend on them, and which of those systems would be hard to update. That is the inventory 12.3.3 already asks for, read with a different question in mind.

A cryptographic bill of materials is the format that carries the answer, and it is the same artifact in both cases.

How QuProtect answers 12.3.3

QuProtect covers the requirement’s four parts with the three capabilities it is built from.

Reconnaissance discovers cryptographic assets continuously from live traffic, so the inventory reflects what is negotiated today rather than what was documented last quarter, and surfaces the weak and deprecated algorithms the viability question is about.

Resilience is what makes the response plan credible. It applies cryptographic policy across existing infrastructure at the network layer, so algorithms and cipher suites can be changed centrally without application rewrites.

Reporting turns the live inventory into evidence, including a current CBOM, so the annual review is a read rather than a project.

For how this sits alongside DORA and the other rules a financial institution answers to, see banking and financial services.