You've seen the NIST announcements. You've read the vendor whitepapers. Now someone in your organization is asking when you're planning to implement post-quantum cryptography to protect cardholder data. Here's what compliance teams are actually asking when they evaluate protocols like CAKE-HI and what the answers mean for your PCI DSS roadmap.
These questions come from real conversations with QSAs, internal audit teams, and infrastructure architects who need to reconcile quantum threat timelines with current compliance obligations. You're not behind if you haven't deployed post-quantum algorithms yet, but you need a plan.
Do We Need to Worry About Quantum Threats for PCI DSS Compliance Right Now?
Not immediately, but your cryptographic inventory work starts now.
PCI DSS v4.0 doesn't mandate post-quantum algorithms. Requirement 4.2.1 still allows you to use strong cryptography based on current industry standards, AES-256, RSA-2048, and similar algorithms remain compliant. But you need to know where you're using cryptography and have a process to respond when standards evolve.
The Council's guidance on cryptographic agility means you should be able to answer: where do we encrypt cardholder data in transit? What key lengths are we using? How quickly could we rotate to new algorithms if NIST or PCI SSC updates their guidance?
Start building that inventory now. When quantum-resistant requirements do arrive, you'll need to know every TLS handshake, every encrypted database column, every HSM configuration that touches a Primary Account Number (PAN).
What Makes CAKE-HI Different from Just Upgrading to Bigger Keys?
It's designed for devices that can't handle the overhead.
Standard post-quantum algorithms produce significantly larger keys, ciphertexts, and digital signatures than classical cryptography. If you're running payment terminals with limited bandwidth, IoT devices in your card-present environment, or mobile point-of-sale systems, those larger handshakes create real problems.
CAKE-HI reduces the handshake size and computational overhead of establishing a quantum-secure link. That matters when you're trying to maintain sub-second transaction times while also future-proofing against quantum attacks.
Think about a payment terminal that needs to establish a secure channel before processing transactions. Traditional post-quantum key exchange might add seconds to initialization or require hardware upgrades. A protocol optimized for constrained environments keeps your existing infrastructure viable longer.
How Do We Evaluate Whether a Protocol Is Actually Secure?
Look for formal verification, not just vendor claims.
CAKE-HI's security properties were formalized and proven using Verifpal and CryptoVerif, protocol analysis frameworks that mathematically verify security claims. This is the standard you should expect from any cryptographic protocol you're considering for production use.
When a vendor pitches you on quantum-resistant technology, ask:
- Has the protocol been formally verified?
- Which properties were proven (confidentiality, authentication, forward secrecy)?
- Were the proofs conducted by independent researchers?
- Are the verification artifacts publicly available?
For PCI DSS purposes, you're already required to use "strong cryptography" as defined by industry standards. When those standards shift to include post-quantum algorithms, the protocols with formal security proofs will be the ones that make it into NIST and PCI SSC guidance first.
Should We Wait for PCI SSC to Mandate Post-Quantum Crypto Before We Act?
No. Build cryptographic agility into your systems now.
Waiting for mandates means you'll be scrambling during a compressed timeline. Better approach: design your systems so you can swap cryptographic primitives without architectural changes.
Practical steps:
- Abstract your cryptography behind well-defined interfaces.
- Ensure your key management infrastructure can handle multiple algorithm types.
- Test your ability to rotate algorithms in non-production environments.
- Document which systems would need hardware upgrades for post-quantum algorithms.
This isn't theoretical. When PCI DSS v4.0 deprecated SSL and early TLS versions, organizations that had hardcoded protocol versions into applications faced expensive rewrites. Those that had configurable cryptographic parameters updated a config file.
What About Our Existing Hardware Security Modules?
Most current HSMs won't support post-quantum algorithms without firmware updates or replacement.
Your HSM inventory is part of that cryptographic agility assessment. Contact your HSM vendors and ask:
- What's their post-quantum roadmap?
- Will current hardware support new algorithms via firmware, or do you need new devices?
- What's the timeline for NIST-approved post-quantum algorithm support?
For PCI DSS Requirement 3.6 (cryptographic key management), you'll eventually need HSMs that can generate, store, and manage post-quantum keys. If your current HSMs are approaching end-of-life, factor post-quantum support into your replacement criteria now.
How Does This Affect Our Compensating Controls Documentation?
It doesn't, yet, but it will change how you think about cryptographic strength.
Right now, if you're using AES-256 for encryption of cardholder data at rest, you're meeting PCI DSS requirements. You don't need compensating controls for quantum resistance because it's not a requirement.
But when you document compensating controls for other requirements, consider the cryptographic assumptions. If you're relying on TLS mutual authentication as a control, and that TLS uses RSA key exchange, you're building on cryptography that quantum computers will eventually break.
This doesn't invalidate your current controls. It means you should be thinking about what changes when "strong cryptography" gets redefined to include quantum resistance.
Where Do We Go from Here?
Start with your cryptographic inventory. Map every place you're encrypting, hashing, or authenticating cardholder data. Document the algorithms, key lengths, and hardware dependencies.
Then build a monitoring process. Subscribe to NIST's post-quantum cryptography updates. Watch for PCI SSC guidance on cryptographic agility. Set calendar reminders to review your cryptographic standards quarterly.
You don't need to deploy CAKE-HI or any other post-quantum protocol tomorrow. But you need the organizational capability to deploy it when the time comes, and that capability takes longer to build than the actual algorithm swap.
The teams that will handle the post-quantum transition smoothly are the ones treating it as an infrastructure modernization project, not a compliance checkbox. Start now.
