Nobody Knows Where Their Crypto Is. PCI Made That a Finding.
A control quietly became mandatory in March 2025. Most organisations met it with a spreadsheet and that spreadsheet is also their quantum exposure.
On 31 March 2025, PCI DSS Requirement 12.3.3 stopped being a best practice and became a requirement that must be fully considered during an assessment, which means that every organisation assessed against the standard since that date has been obliged to answer it properly rather than aspirationally.
The requirement asks for three things. It wants a current inventory of every cryptographic cipher suite and protocol in use, including what each one is for and where it lives. It wants active monitoring of industry trends bearing on whether those remain viable. And it wants a documented plan describing how the organisation will respond when they cease to be viable. Read quickly, all of this has the texture of paperwork, the sort of control that gets satisfied with a policy document, a review date, and a signature. Read carefully, it turns out to be the hardest question most security programmes have never been asked to answer.
Why most cryptographic inventories are incomplete
Ask a CISO whether the organisation can produce a cryptographic inventory and the answer will usually be yes, delivered with some confidence. Ask what is actually in it, and the picture tends to resolve into something considerably narrower: the TLS versions running on the external estate, the cipher suites the load balancers negotiate, and the algorithms named in the key management policy. That is a real document, and it is not an inventory. It is a record of the cryptography that somebody happened to remember.
The cryptography that matters is precisely the cryptography nobody remembers, and every environment of any age contains a great deal of it. There is an RSA key hardcoded into a payment integration written in 2014 by a contractor who left in 2016 and documented nothing on the way out. There is a vendor appliance performing certificate validation that cannot be inspected and cannot be changed, because the vendor does not expose it and the contract never required them to. There is a batch job signing files with an algorithm chosen for no better reason than that it was the default in the library someone imported a decade ago. There are certificates issued by a team that has since been reorganised out of existence, renewing themselves automatically on a schedule nobody set, owned by no one at all.
None of that appears in the spreadsheet, and every part of it falls within scope.
The element of 12.3.3 that defeats organisations is not the inventory in the abstract, which sounds tractable enough, but the qualifier attached to it, which requires that each entry record its purpose and where it is used. You cannot write down where an algorithm is used if you do not know that it is running in the first place, and the honest position for nearly every organisation is that some meaningful fraction of its cryptography is undocumented, unowned, and entirely invisible until either something breaks or an assessor asks a question that cannot be answered.
Does PCI DSS require post-quantum cryptography?
There is a word that does not appear anywhere in PCI DSS v4.0.1, across the whole of the standard and all of its nearly four hundred pages, in no requirement, testing procedure, guidance column, or appendix.
The word is quantum.
It is worth being precise about this, because the precision is the whole of the argument that follows. PCI DSS does not require post-quantum cryptography, and any vendor claiming otherwise is either selling something or has not read the document they are citing.
Having established that, read the second and third elements of the requirement again, this time with some attention. The standard asks for active monitoring of industry trends regarding the continued viability of the cryptographic cipher suites and protocols an organisation is running, and it asks for documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.
In 2024, NIST finalised the first of its post-quantum cryptographic standards, and standards bodies have since signalled a transition away from RSA and elliptic-curve cryptography on a timeline that runs to the end of this decade and some way beyond it. This is not a trend that might conceivably emerge at some point. It is, on any reasonable reading, the single largest anticipated change in the continued viability of deployed cryptography in the history of the field, and it is already a matter of public record. If an organisation's monitoring of industry trends has somehow failed to surface it, then the monitoring is not happening in any meaningful sense, and if the documented response plan does not contemplate it, then there is no plan worth the name.
The guidance accompanying Requirement 12.3.3 is built around a term the standard takes the trouble to define explicitly, which is cryptographic agility: the ability to monitor and manage the encryption and related verification technologies deployed across an organisation, and to move to an alternative primitive without having to tear up the system infrastructure in order to do it. The same guidance directs readers to NIST's work on transitioning the use of cryptographic algorithms and key lengths.
PCI did not say quantum, and it is important not to pretend otherwise. What PCI did do, in some detail and at some length, was describe the discipline an organisation would need in order to survive it.
Why act now, if quantum computers do not exist yet?
The usual objection arrives immediately and in roughly the same form every time: cryptographically relevant quantum computers do not exist, the published estimates for their arrival keep moving, and this can therefore reasonably wait until the picture clarifies. The objection misunderstands the risk, and it does so for two separate reasons, either of which would be sufficient on its own.
The first is the problem known as harvest now, decrypt later. Encrypted traffic captured today can be stored indefinitely and decrypted at whatever point in the future the capability becomes available, which means that for any data carrying a long confidentiality life, including payment data, health records, legal and regulatory material, source code, and commercial or state secrets, the exposure does not sit somewhere in the future at all. It sits in the traffic that has already left the network. The clock started without anybody's permission and without any announcement.
The second reason is that migration is not an upgrade, and treating it as one is the error that turns a five-year programme into a ten-year one. There is no patch to apply and no product that renders an organisation quantum-safe upon installation. Cryptography is not a component that can be swapped out; it is a dependency threaded through every library, certificate, protocol handshake, hardware security module, embedded device, and third-party product in the estate, very much including the ones the organisation did not build and cannot modify. Organisations that have started this work report, with a consistency that ought to be instructive, that discovery alone has taken longer than they originally budgeted for the entire project.
Which leads to an unglamorous conclusion. The work that has to happen first is the work that Requirement 12.3.3 has already asked for.
What is a cryptographic bill of materials (CBOM)?
The output of that work has a name and an established standard behind it. A cryptographic bill of materials applies the logic of a software bill of materials to cryptography, recording every algorithm, key, certificate, protocol, and library in the environment, alongside where each one runs, what depends on it, and when it expires, in a machine-readable format rather than a document that is stale on the day it is signed.
The essential characteristic is that it is discovered rather than surveyed. Nobody fills in a form, because forms return the cryptography that people remember, which is the problem the exercise exists to solve. The estate is scanned and interrogated, and what emerges is what is genuinely running, including the things no one would ever have reported for the simple reason that no one knew they were there.
An organisation holding an artefact of this kind can answer Requirement 12.3.3 properly and without improvisation. It can also answer the question its board will eventually ask about quantum, and the questions its regulators are increasingly beginning to ask, and it can do all of this from the same inventory rather than commissioning a fresh exercise for each audience. The work is done once and serves repeatedly.
It also pays for itself well before quantum enters the conversation at all, which is the part that tends to surprise people. Every discovery engagement surfaces expired and orphaned certificates, deprecated protocols still quietly negotiating in production, keys that have outlived the people who owned them, and algorithms that would fail an assessment conducted this afternoon. That is a risk register for this quarter, not a hypothetical for the next decade.
This is not a regional question: PCI DSS, MAS TRM, BNM RMiT
Payment security has no nationality, and Requirement 12.3.3 applies in identical terms to an acquirer in Kuala Lumpur, a processor in Singapore, and a merchant in New York, none of whom get a variation on account of geography.
The pattern repeats well outside the payments world. United States federal requirements have set the most concrete post-quantum migration deadlines currently in existence anywhere. European financial resilience regulation obliges firms to manage technology risk in terms that cryptographic agility sits squarely inside, whether or not the regulation uses that vocabulary. In Asia-Pacific, the Monetary Authority of Singapore's Technology Risk Management guidelines and Bank Negara Malaysia's Risk Management in Technology policy already require exactly the technology risk discipline that a cryptographic inventory exists to serve.
Different regimes, different deadlines, and underneath all of them a single question that does not change as it crosses borders: do you know what cryptography you are running, and can you change it? Every regulated organisation is going to answer that question at some point in the next several years. The only variable genuinely available to them is whether they answer it deliberately, on their own schedule, or extemporaneously, sitting across a table from an assessor.
Where to start: discovery before strategy
The instinct in most organisations is to begin with a strategy, which is understandable and almost always wrong, because a strategy written in the absence of an inventory is a document about assumptions rather than about the estate.
The first genuinely useful step is discovery against a bounded scope, and the cardholder data environment is the natural candidate for it, on the straightforward grounds that the obligation already exists there and somebody has already drawn the boundary. Find what is actually running. The findings will make the argument for everything that follows more persuasively than any business case assembled in advance of them could.
From there the inventory extends outward across the estate, and the organisation decides what genuinely needs to change and in what order, weighing each decision against how long the data in question must remain confidential. And then, because ML-KEM will not be the last algorithm anyone is ever obliged to migrate to, the organisation builds the agility to do all of it again without the same pain.
AKATI Sekurity is a PCI SSC Qualified Security Assessor and Approved Scanning Vendor, and has assessed cryptographic controls across banking, payments, and critical infrastructure since 2007. To discuss a cryptographic discovery engagement, contact hello@akati.com.
What Organisations Actually Ask Us
Straight answers on cryptographic inventory, Requirement 12.3.3, and post-quantum exposure, including the answers that do not help us sell anything.
It does not. The word "quantum" does not appear anywhere in PCI DSS v4.0.1, and any vendor telling you that the standard mandates post-quantum cryptography has not read the document they are citing.
What Requirement 12.3.3 does require is that your cryptographic cipher suites and protocols are documented and reviewed at least once every 12 months, which includes active monitoring of industry trends bearing on their continued viability, together with a documented plan for responding to anticipated changes in cryptographic vulnerabilities. It is AKATI Sekurity's view that the post-quantum transition is the largest such anticipated change currently on the public record, and that an inventory built to satisfy 12.3.3 is the same artefact a migration would require in any case. That reading of the standard is our own, and it is not a PCI mandate.
The requirement obliges an organisation to document and review the cryptographic cipher suites and protocols it has in use at least once every 12 months, and it sets out three elements that the exercise must cover. It calls for an up-to-date inventory of every cipher suite and protocol in use, recording the purpose of each one and where it is used. It calls for active monitoring of industry trends regarding the continued viability of all of them. And it calls for documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.
It applies to all cryptography used to meet PCI DSS requirements, which includes the cryptography that renders PAN unreadable in storage and in transmission, the cryptography protecting passwords, and the cryptography involved in authenticating access. It remained a best practice until 31 March 2025, after which it became a full requirement that must be fully considered during an assessment.
PCI DSS defines cryptographic agility as the ability to monitor and manage the encryption and related verification technologies deployed across an organisation. In practical terms it means that an alternative to the algorithm you are currently running is available to you, and that it can be adopted without requiring significant change to your system infrastructure in order to accommodate it.
The guidance accompanying Requirement 12.3.3 is built around this concept, and it refers readers to NIST SP 800-131a on transitioning the use of cryptographic algorithms and key lengths. Agility, rather than any single algorithm, is the durable outcome worth investing in, not least because ML-KEM will not be the last algorithm anyone is ever obliged to migrate to.
A cryptographic bill of materials is a complete inventory of every cryptographic asset in an environment, covering algorithms, keys, certificates, protocols and libraries, and recording where each one runs, what depends on it, and when it expires, in a machine-readable format rather than in a document that is stale on the day it is signed. It applies the same principle as a software bill of materials, directed at cryptography instead of packages.
The essential characteristic is that it is discovered rather than surveyed, and the distinction matters more than it sounds. Nobody fills in a form, because forms return the cryptography that people happen to remember. The estate is scanned and interrogated in order to establish what is genuinely running, which includes the cryptography that nobody would ever have reported for the simple reason that nobody knew it was there.
It cannot. There is no update to push out and no product that renders an organisation quantum-safe upon installation, whatever the marketing around it may suggest.
Cryptography is not a component that can be swapped out; it is a dependency threaded through every library, certificate, protocol handshake, hardware security module, embedded device and third-party product in the estate, very much including the ones you did not build and cannot modify. Migration is therefore a multi-year programme rather than a maintenance window, and its first phase is discovery. Organisations that have started this work report, with some consistency, that discovery alone has taken longer than they originally budgeted for the entire project.
Because of the problem known as harvest now, decrypt later. Encrypted traffic captured today can be stored indefinitely and decrypted at whatever point the capability arrives, which means that for any data carrying a long confidentiality life, including payment data, health records, legal and regulatory material, intellectual property, and commercial or state secrets, the exposure begins at the moment the traffic crosses the network rather than at the moment the hardware comes into existence.
The useful question, then, is not when quantum computers will arrive, since nobody can answer that with any authority. It is how long your data must remain confidential, measured against how long your migration will realistically take. If the first number is larger than the second, you are already late, and no amount of waiting for the estimates to firm up will change that arithmetic.
The obligation recurs across regulatory regimes, and it does so with a consistency that suggests the underlying problem is not jurisdictional at all. In Asia-Pacific, the Monetary Authority of Singapore's Technology Risk Management guidelines and Bank Negara Malaysia's Risk Management in Technology policy already require the technology risk discipline that a cryptographic inventory exists to serve. United States federal requirements have set the most concrete post-quantum migration deadlines currently published anywhere. European financial resilience regulation obliges firms to manage technology risk in terms that cryptographic agility sits squarely inside, whether or not the regulation uses that particular vocabulary.
Different regimes, different deadlines, and beneath all of them a single question that does not change as it crosses a border: do you know what cryptography you are running, and can you change it? Every regulated organisation is going to answer that question eventually, and the only variable available to them is whether they answer it deliberately and on their own schedule, or extemporaneously and in front of an assessor.
The engagement produces a discovered inventory of the cryptography actually running within a bounded scope, and the cardholder data environment is the natural place to begin, on the straightforward grounds that the obligation already exists there and somebody has already drawn the boundary around it.
The deliverable supports Requirement 12.3.3, establishes the organisation's post-quantum exposure, and surfaces a set of findings that matter immediately rather than eventually: expired and orphaned certificates, deprecated protocols still quietly negotiating in production, keys that have outlived the people who owned them, and algorithms that would not survive an assessment conducted this afternoon. It earns its cost well before quantum enters the conversation at all.
To discuss a cryptographic discovery engagement: hello@akati.com | Schedule a consultation →
References to PCI DSS describe Requirement 12.3.3 of the Payment Card Industry Data Security Standard v4.0.1. PCI DSS is a standard of the PCI Security Standards Council, LLC. AKATI Sekurity is a PCI SSC Qualified Security Assessor and Approved Scanning Vendor. The interpretation of how Requirement 12.3.3 relates to post-quantum cryptography is AKATI Sekurity's own, and it does not represent a position of the PCI Security Standards Council.
