Your TLS infrastructure isn't ready for post-quantum cryptography just because you've read about ML-KEM. Migration is an architectural program, not an algorithm swap. This checklist separates the operational work of confidentiality migration from authentication migration and identifies what deployment readiness actually requires.
What This Checklist Covers
This checklist addresses the structural dependencies that determine whether your TLS migration will succeed or stall. You'll verify that your key establishment, authentication mechanisms, certificate infrastructure, and operational tools can support hybrid post-quantum constructions. Each item has a clear completion state. If you can't check the box, you'll know what's blocking you.
Prerequisites
Before starting this checklist, confirm:
You have a complete cryptographic inventory. List every TLS endpoint, library version, certificate authority relationship, and hardware security module (HSM) in your cardholder data environment. If you don't know where classical ECDHE is running, you can't plan its replacement.
You understand your data classification tiers. Not all TLS sessions protect the same risk profile. Identify which connections carry Primary Account Number (PAN) data, authentication credentials, or other high-value secrets that quantum computers could retrospectively decrypt.
You have interoperability test capacity. Post-quantum migration will break connections if clients, servers, middleboxes, or monitoring tools can't parse hybrid key exchanges or larger certificates. You need a staging environment where failures don't leak cardholder data.
Checklist Items
1. Separate Confidentiality and Authentication Migration
Confidentiality migration (protecting session keys) and authentication migration (protecting certificate signatures) are distinct security programs. They have different threat timelines and dependencies.
Done when: You have two parallel work streams with separate owners, timelines, and success criteria. Confidentiality migration can proceed with hybrid ECDHE-ML-KEM while authentication still uses classical ECDSA or RSA certificates.
What good looks like: Your project documentation explicitly states which program addresses harvest-now-decrypt-later threats and which addresses future signature forgery.
2. Verify TLS Library Support for Hybrid ECDHE-ML-KEM
Hybrid ECDHE-ML-KEM is a strong transitional architecture for confidentiality migration when the relevant TLS integration and implementation support are available.
Done when: You've confirmed that your TLS libraries (OpenSSL, BoringSSL, or vendor-specific implementations) support the standardized hybrid construction, not just ML-KEM in isolation.
What good looks like: You can demonstrate a successful hybrid handshake in your test environment between a client and server you control, and you've captured the wire format to verify it matches the standard.
3. Test Certificate Chain Compatibility with Post-Quantum Signature Algorithms
Your certificate infrastructure must support ML-DSA or SLH-DSA signatures. This includes server certificates, intermediate certificates, root trust anchors, and any certificate transparency logs you depend on.
Done when: You've issued a test certificate signed with a post-quantum algorithm and verified that your clients can validate the chain without parsing errors.
What good looks like: Your test certificate is under 10KB total (including chain), your clients complete the handshake in under 500ms on production hardware, and you've documented which trust stores require updates.
4. Confirm HSM Support for Post-Quantum Key Operations
Your HSMs must generate, store, and use post-quantum keys. Many HSMs deployed in payment environments are FIPS 140-3 validated for classical algorithms only.
Done when: You've received written confirmation from your HSM vendor that your specific model and firmware version support ML-KEM key generation and ML-DSA or SLH-DSA signing operations, or you've completed a proof-of-concept on the actual hardware.
What good looks like: You can generate a post-quantum key pair inside the HSM, sign a test payload, and verify the signature using the public key, all without extracting private key material.
5. Identify and Test Middlebox Behavior with Larger Handshakes
Post-quantum handshakes are larger than classical handshakes. Firewalls, load balancers, TLS-inspecting proxies, and intrusion detection systems may reject or corrupt packets that exceed expected size thresholds.
Done when: You've mapped every network device between your clients and servers that touches TLS traffic, and you've tested a hybrid handshake through each path.
What good looks like: You have a spreadsheet listing each middlebox, its vendor, its firmware version, whether it passed the hybrid handshake test, and if not, what error it produced and whether a firmware update is available.
6. Distinguish PSKs, Resumption, and KeyUpdate in Your Rekeying Strategy
PSKs, resumption, and KeyUpdate are not interchangeable forms of rekeying. Their security depends on the provenance and role of the secret. KeyUpdate remains within an existing traffic-secret lineage and does not create an independent post-quantum secret.
Done when: You've documented which rekeying mechanism you use in each context (session resumption for performance, PSK for out-of-band provisioning, KeyUpdate for long-lived connections) and verified that you're not relying on KeyUpdate to provide post-quantum confidentiality for sessions that started with classical key exchange.
What good looks like: Your security documentation explicitly states that KeyUpdate does not upgrade a classical session to post-quantum protection, and your monitoring can distinguish resumed sessions from fresh handshakes.
7. Plan Staged Authentication Migration with Hybrid or Composite Certificates
Authentication migration requires coordinating certificate issuance, trust store updates, and client capability detection. You can't flip all certificates to pure post-quantum signatures on a single date.
Done when: You have a timeline that phases in hybrid or composite authentication (classical + post-quantum signatures in the same certificate) before retiring classical-only certificates, and you've identified which clients will break at each phase.
What good looks like: Your certificate authority can issue hybrid certificates on demand, you've tested them with representative clients, and you have a rollback plan if a deployment phase fails.
8. Establish Observable Retirement Criteria for Classical-Only Mechanisms
You need telemetry to know when you can turn off classical-only TLS configurations. Without it, you're guessing whether clients still depend on ECDHE-only handshakes.
Done when: You're logging the cipher suite and key exchange method for every TLS connection, and you can query what percentage of sessions would fail if you disabled classical-only support.
What good looks like: Your dashboard shows zero classical-only connections from production clients for 90 consecutive days, and you've confirmed that the remaining classical-only traffic comes from deprecated test systems you can decommission.
Common Mistakes
Treating hybrid key exchange as optional. Hybrid ECDHE-ML-KEM protects you if either the classical or post-quantum component is broken. Pure ML-KEM offers no such fallback during the transition period.
Assuming certificate size doesn't matter. Post-quantum certificates can exceed 10KB. If your TLS record layer, firewall rules, or monitoring tools assume certificates fit in 4KB, you'll see silent failures or truncated handshakes.
Ignoring trust anchor migration. Your root certificate store must trust post-quantum signatures. If your clients ship with a static trust store that only validates RSA or ECDSA roots, you can't deploy post-quantum authentication until you update every client.
Conflating KeyUpdate with post-quantum rekeying. KeyUpdate derives new traffic secrets from the existing master secret. If that master secret came from a classical ECDHE exchange, KeyUpdate does not provide post-quantum confidentiality.
Next Steps
Start with your highest-value TLS sessions: connections that transmit cardholder data or authentication credentials. These face the greatest harvest-now-decrypt-later risk. Deploy hybrid ECDHE-ML-KEM on a controlled subset of endpoints, verify interoperability, then expand coverage. Authentication migration follows once you've confirmed your certificate infrastructure and trust stores can handle post-quantum signatures.
Don't wait for "full" post-quantum readiness to begin. Deployment readiness is constrained as much by certificates, trust stores, HSMs, middleboxes, inventory, and interoperability as by primitive availability. The organizations that start testing hybrid constructions now will have working migrations when quantum threats become operational. The ones waiting for perfect tooling will still be inventorying their dependencies.
