A practical guide to post-quantum cryptography migration

Name an accountable owner and include security, infrastructure, application, identity, procurement, risk, and legal stakeholders. Define which business services, data classes, suppliers, and environments are in scope. Record the assumptions behind every readiness decision.

Find where public-key cryptography is used across TLS, certificates, APIs, service meshes, VPNs, identity, code signing, key management, firmware, backups, and third-party services. An external TLS security scan provides fast evidence for public endpoints, while internal discovery completes the picture.

Ask how long each protected data set must remain confidential, how long migration will take, and when a capable threat could emerge. Long-lived sensitive information can face harvest-now-decrypt-later risk before production quantum attacks are practical. Prioritisation should also consider service criticality, exposure, replacement complexity, and supplier dependency.

Document where algorithms and certificate formats are fixed by products, protocols, hardware, or contracts. Ask vendors which standards they will support, how upgrades affect interoperability, and whether hybrid deployment is available. Avoid treating a roadmap statement as deployed evidence.

Prepare systems to replace algorithms and keys without redesigning the whole service. Test certificate automation, larger keys and signatures, handshake size, latency, network middleboxes, observability, rollback, and mixed-client compatibility. Use isolated environments before production rollout.

Turn each gap into an owned action with priority, due date, dependency, and acceptance evidence. Preserve the scan scope and limitations in reports. Repeat assessments after certificate, platform, or vendor changes so leadership can see whether exposure is falling.