Read this first
PCI DSS does not require post-quantum cryptography and does not set a quantum deadline. Anyone telling you otherwise is selling something. What v4 does require, and this is new, is that you inventory the cryptography protecting card data and review it every twelve months with a plan for responding to cryptographic weaknesses. That review is where quantum risk arrives, on a recurring twelve-month clock, and the inventory it demands is the same inventory every post-quantum mandate asks for.
The two requirements that matter here
PCI DSS v4 has plenty to say about cryptography, but two of its future-dated requirements changed the shape of the obligation. Both became mandatory on 31 March 2025, having been advisory since v4.0 took effect a year earlier.
| Requirement | What it obliges | Why it matters for post-quantum |
|---|---|---|
| 4.2.1.1 | Maintain an inventory of the trusted keys and certificates used to protect the primary account number in transit. | A certificate and key inventory scoped to the cardholder data environment. Narrower than a full cryptographic inventory, but the same discipline and often the first one an organisation actually completes. |
| 12.3.3 | Document the cryptographic cipher suites and protocols in use, review them at least once every twelve months, and maintain a plan to respond to anticipated changes in cryptographic vulnerabilities. | This is crypto-agility written in audit language. The annual review is a recurring, dated moment where somebody has to ask whether the algorithms still hold, and 'anticipated changes' is exactly where the quantum question belongs. |
12.3.3 is the more consequential of the two, and it is frequently underread. It does not ask for a list. It asks for a list, a scheduled review of that list, and a plan for what you do when an algorithm you depend on stops being defensible. An organisation that can produce all three has, without using the word, a crypto-agility programme. One that cannot produce them will fail that requirement for reasons that have nothing to do with quantum computers.
What PCI DSS does not say
There is no PCI post-quantum deadline
PCI DSS v4 names no post-quantum algorithm, sets no quantum migration date, and does not require ML-KEM or ML-DSA anywhere. Its cryptographic requirements are framed around 'strong cryptography' as defined by industry standards, which today still means RSA and elliptic curve at appropriate key sizes. If a vendor tells you PCI requires post-quantum cryptography, they are inventing a requirement, and you should discount everything else they tell you accordingly.
This matters because the honest version of the argument is stronger. PCI's definition of strong cryptography follows industry standards, and those standards are moving: NIST has published the algorithms and, in IR 8547, the dates on which today's public-key cryptography becomes deprecated and then disallowed. PCI does not need its own quantum deadline for that to reach you, because its own definition points at the body setting one.
Where the quantum risk actually is
Card data has a short useful life compared to health records or state secrets, which genuinely reduces the harvest-now-decrypt-later exposure of a single transaction. That is a fair point and it is worth conceding before making the counter-argument.
The counter-argument is that the cardholder data environment contains more than transactions. It contains long-lived trust: certificate hierarchies, code-signing keys, HSM-held key material, archived logs and backups retained for years to satisfy other obligations. Those outlive the card numbers by a wide margin. And signature forgery against a payment-terminal code-signing root is not a confidentiality problem at all, so the short shelf life of a PAN does not speak to it.
- Ask the shelf-life question per asset, not per environment. A PAN in flight and a signing root in an HSM sit in the same scope and have nothing in common risk-wise.
- Treat 12.3.3's annual review as the scheduling mechanism you already have. You do not need to invent a governance moment for post-quantum; there is one on the calendar, and an assessor is going to attend it.
- Do 4.2.1.1's inventory once, properly, and reuse it. A key and certificate inventory scoped to cardholder data is a strict subset of the cryptographic inventory that NIS2, DORA, ISO 27001 and every post-quantum mandate will ask for. Building it twice is the waste, not building it.
How this sits with everything else
If you are an EU financial entity, PCI is not your binding constraint: DORA applies to you directly, with a supervisor attached, and asks harder questions about cryptographic controls. If you are a merchant or processor without that exposure, PCI may be the only cryptographic governance obligation you have, which makes 12.3.3 the whole of your programme rather than one part of it. Either way the sequencing is the same and it is set out on the deadlines page: inventory first, because it is the input to all of them.
Frequently asked questions
Does PCI DSS require post-quantum cryptography?
No. PCI DSS v4 sets no post-quantum requirement, names no post-quantum algorithm, and gives no quantum migration deadline. Its requirements are framed around strong cryptography as defined by industry standards. Any claim that PCI mandates post-quantum cryptography today is wrong.
What is requirement 12.3.3, in plain terms?
Write down which cipher suites and protocols you actually use, review that list at least once every twelve months, and have a plan for what you will do when one of them stops being trustworthy. It became mandatory on 31 March 2025. Most organisations can produce the list; far fewer can produce the review record and the plan, which is where assessments fail.
Is card data really at risk from harvest-now-decrypt-later?
A single card number has a short useful life, so the exposure for transactions in flight is genuinely lower than for medical records or archives. The risk in a cardholder data environment is concentrated elsewhere: certificate hierarchies, code-signing keys, HSM key material and multi-year retained backups all outlive the cards by a wide margin, and signature forgery is not a confidentiality question at all.
Does the 4.2.1.1 inventory count as a cryptographic inventory?
It is a useful subset, not the whole thing. It covers trusted keys and certificates protecting the primary account number in transit, which is narrower than the algorithm-level inventory of your whole estate that post-quantum migration requires. It is the right place to start if you are doing it anyway, provided you scope it so it can be extended rather than having to be redone.
PCI or DORA: which one drives our cryptography work?
If you are an EU financial entity, DORA, because it applies directly, has supervisory teeth, and asks harder questions about cryptographic controls and key management. PCI remains in scope for card data but is unlikely to be the binding constraint. For merchants and processors outside DORA's scope, PCI's 12.3.3 may be the only recurring cryptographic governance obligation you have.