Purpose of the Checklist
You can't swap out cryptographic algorithms like you replace a server. Payment systems, cardholder data environments, and transaction processing pipelines embed cryptographic elements deep in their architecture, including HSMs, TLS configurations, tokenization vaults, key management hierarchies, and authentication flows. When NIST finalizes post-quantum cryptographic standards, you'll need to transition without breaking authorization flows or compromising PCI DSS compliance.
This checklist helps you inventory your cryptographic dependencies, assess quantum vulnerability, and build a migration roadmap. It's designed for teams managing cardholder data environments under PCI DSS 4.0, where Requirement 4.2.1 mandates strong cryptography for transmission protection and Requirement 3.5 governs key management for stored account data.
The threat model is straightforward: adversaries can capture encrypted payment traffic today and store it until quantum computers capable of breaking RSA-2048 or ECC become available. For data that must remain confidential for decades, like cardholder data, authentication credentials, and encryption keys, that's an unacceptable risk.
Prerequisites
Before using this checklist, ensure you have:
System documentation access. You can't inventory what you can't see. Gather architecture diagrams, data flow maps, and network topology documentation for your cardholder data environment. Include third-party connections such as payment gateways, processors, and acquiring banks.
Cryptographic visibility. Deploy discovery tools that identify TLS versions, cipher suites, certificate chains, and cryptographic libraries across your environment. If you're running containers or serverless functions that handle payment data, you need runtime visibility into their crypto implementations.
Stakeholder alignment. Crypto-agility isn't just an infrastructure project. You'll need input from application teams, compliance officers, and vendor management. Schedule a kickoff meeting to explain the quantum threat and the regulatory timeline.
A test environment. Validate post-quantum algorithms in a non-production setting before touching live payment flows. Ensure your test environment mirrors production cryptographic configurations.
The Checklist
Phase 1: Cryptographic Asset Inventory
☐ Map all systems that transmit or store cardholder data. Include point-of-sale terminals, payment gateways, authorization switches, tokenization services, and data warehouses. For each system, document the cryptographic protocols in use (TLS 1.2, TLS 1.3, IPsec).
☐ Identify asymmetric cryptography dependencies. List every instance where your systems use RSA, Diffie-Hellman, or elliptic curve cryptography. These are vulnerable to quantum attacks. Common locations: TLS handshakes, digital signatures on transaction messages, key exchange protocols in HSMs, certificate-based authentication.
☐ Document symmetric encryption usage. While AES-256 remains quantum-resistant, you need to know where it's deployed and how keys are managed. Check: database-level encryption, file system encryption, tokenization vaults, key encryption keys in your HSM hierarchy.
☐ Audit key management infrastructure. Document your Key Encryption Key and Data Encryption Key hierarchy. Note how keys are generated, stored, rotated, and destroyed. If you're using FIPS 140-3 validated HSMs, record the firmware version and supported algorithms.
☐ Catalog third-party cryptographic dependencies. Payment processors, fraud detection services, and card networks all use cryptography. Request their post-quantum readiness statements. Ask when they plan to support quantum-resistant algorithms and whether that transition will require changes on your side.
Phase 2: Quantum Vulnerability Assessment
☐ Calculate data confidentiality timelines. For each data type you protect, determine how long it must remain confidential. Cardholder data after a transaction settles? Probably months. Encryption keys that protect historical transaction logs? Potentially years. If the confidentiality requirement exceeds the estimated timeline for quantum computers capable of breaking your current algorithms, flag it as high-risk.
☐ Prioritize by exposure. Systems with internet-facing endpoints transmitting encrypted payment data are the highest priority. Adversaries can passively collect that traffic today. Internal systems behind network segmentation controls carry lower immediate risk but still need migration plans.
☐ Identify migration blockers. Some systems can't be upgraded easily. Legacy HSMs that don't support algorithm agility, payment terminals with firmware burned into ROM, and proprietary protocols from vendors who've gone out of business. Document these constraints now.
Phase 3: Crypto-Agility Roadmap
☐ Establish algorithm negotiation capability. Your systems should support multiple cryptographic algorithms simultaneously and negotiate which one to use at runtime. This lets you introduce post-quantum algorithms alongside existing ones, then phase out the old algorithms once validation is complete.
☐ Design a key management transition strategy. You can't flip a switch and replace all your encryption keys. Plan for a hybrid period where you maintain parallel key hierarchies, one using current algorithms and one using post-quantum algorithms. Define how you'll migrate data encrypted under old keys.
☐ Build a vendor engagement timeline. Contact HSM vendors, payment processors, and gateway providers. Ask when they'll release post-quantum firmware updates or API changes. Schedule quarterly check-ins to track their progress.
☐ Create a testing protocol. Define how you'll validate post-quantum algorithms in your test environment. Include performance benchmarks, interoperability testing with payment networks, PCI DSS compliance validation, and rollback procedures if something breaks.
☐ Draft a phased deployment plan. Start with low-risk systems that have the fewest dependencies. Move to internet-facing payment endpoints once you've validated performance and stability. Save the most complex migrations, like core authorization switches and HSM key hierarchies, for last.
Phase 4: Validation and Monitoring
☐ Verify algorithm support. After deploying post-quantum cryptography, confirm that all endpoints are using the new algorithms. Check TLS handshake logs, inspect certificate chains, and validate that quantum-resistant key exchange mechanisms are active.
☐ Measure performance impact. Post-quantum signatures and key exchanges consume more CPU and bandwidth than RSA or ECC. Monitor transaction latency, authorization timeframes, and system resource utilization. If you see degradation affecting payment processing, you may need to scale infrastructure.
☐ Update compliance documentation. Revise your PCI DSS self-assessment questionnaire and system security plan to reflect your post-quantum cryptographic controls. Document the algorithms you're using, the key sizes, and your key management procedures.
☐ Schedule annual reviews. Cryptographic standards will continue evolving. Set a recurring calendar reminder to review NIST's post-quantum cryptography project updates, assess new vulnerabilities, and evaluate whether your algorithm choices still meet current guidance.
Customizing the Checklist
If you operate a Level 1 merchant environment with multiple acquiring relationships, expand Phase 1 to include a detailed inventory of each processor's cryptographic requirements. You may need separate migration timelines for different payment networks.
If you're a service provider handling cardholder data for multiple clients, add a client communication workstream. Notify clients about algorithm changes, provide migration timelines, and coordinate testing windows.
If you run payment terminals or point-of-sale hardware, add a hardware lifecycle assessment. Determine which devices can accept firmware updates and which will require physical replacement. Budget accordingly.
Validation Steps
After completing this checklist, you should be able to answer:
- Which systems in your cardholder data environment use quantum-vulnerable cryptography?
- What's your longest data confidentiality requirement, and does it exceed the quantum threat timeline?
- Do you have the infrastructure to support algorithm negotiation and parallel key hierarchies?
- Have you scheduled vendor engagement meetings and confirmed their post-quantum roadmaps?
If you can't answer these questions, revisit Phase 1 and Phase 2. Crypto-agility depends on visibility. You can't migrate what you haven't inventoried.
