PCI DSS 4.0 introduced 64 new requirements. Fifty-one of them were future-dated, meaning they existed as best practice for a transition period before becoming fully mandatory on 31 March 2025 – a date confirmed directly by the PCI Security Standards Council itself, and unchanged by PCI DSS v4.0.1, the limited clarification release published in June 2024 that’s the currently official version of the standard. Several of the cryptography-related requirements, read closely, describe something close to the starting line of a post-quantum migration – not because PCI DSS mentions quantum computing at all, but because “know your cryptography” turns out to be the same first step for both problems.
What PCI DSS 4.0.1 actually requires
Requirement 12.3.3 is the one that matters most here. Since 31 March 2025, organisations must maintain an up-to-date, documented inventory of every cryptographic cipher suite and protocol in use, reviewed at least every 12 months. That inventory obligation is paired with something easy to miss: a requirement to actively monitor industry cryptographic trends and maintain a documented response to anticipated algorithm deprecation.
Three other requirements reinforce the same discipline. Requirement 4.2.1 (and 4.2.1.1) requires documenting which algorithms protect cardholder data and where, now covering every network the primary account number (PAN) crosses, not just public ones as under PCI DSS 3.x. Requirement 3.5.1 tightened encryption-at-rest: disk-level encryption alone no longer qualifies except on removable media, and PAN must be rendered unreadable specifically via keyed cryptographic hashes. Requirement 3.6 governs key management, limiting access to the custodians who actually need it.
Deliberately silent on which algorithm
None of this names a specific algorithm to adopt. PCI SSC defines “strong cryptography” as industry-tested algorithms carrying a minimum of 112-bit effective key strength, combined with proper key management – a bar to clear, not a fixed list. That’s a deliberate design choice: the standard is built to be crypto-agile, on the premise that organisations need to be able to change algorithms fairly rapidly as the industry’s understanding of what’s safe changes. Inventory and monitoring are how a crypto-agile standard stays enforceable without naming today’s algorithms in a document that has to remain accurate for years.
What this has to do with quantum readiness
PCI SSC hasn’t published standalone post-quantum guidance, and Requirement 12.3.3 doesn’t require adopting PQC algorithms. What it requires is the mechanism a PQC transition depends on regardless: a documented inventory of every cipher suite and protocol in use, reviewed regularly, plus active monitoring of exactly the kind of algorithm-obsolescence signal that NIST’s own PQC transition timeline represents. PCI DSS 4.0.1 doesn’t ask anyone to migrate to post-quantum cryptography yet – it makes the awareness and inventory work a mandatory first step, for a different reason, ahead of when most organisations would otherwise have started it.
The convergence isn’t only regulatory. In June 2025, Futurex became the first hardware security module vendor to achieve PCI HSM validation for a device with post-quantum cryptography support – a sign the compliance and readiness paths are already meeting inside the vendor ecosystem, not staying separate tracks.
Where ECEM picks up
Enterprise Cryptographic Exposure Management runs six continuous stages: Discover, Inventory, Assess, Prioritise, Transition, Monitor. Requirement 12.3.3’s inventory obligation is, in substance, ECEM’s Discover and Inventory stages, produced as a byproduct of compliance rather than a separate PQC-specific project. Its “active monitoring of industry trends” language is functionally ECEM’s Monitor stage, described for a narrower purpose – deprecation risk within card-data scope – than ECEM’s continuous posture monitoring across the whole estate.
The gap is scope, not method. PCI DSS’s inventory obligation is bounded by the cardholder data environment, because that’s what the standard governs. A PQC exposure assessment has to extend the same discipline – discover, inventory, assess, prioritise – across the full estate, not just the systems a QSA will ask to see. The evidence a PCI DSS audit already requires is a genuine head start on that wider work, not a substitute for it.
Further reading: compliance and regulatory readiness, cryptographic discovery and CBOM, and what ECEM actually is.