Post-Quantum Cryptography: An IT Leader's Implementation Checklist

The threat is not theoretical. Encrypted data captured today will become readable within the next decade as quantum computers scale beyond their current capabilities. Nation-state actors and well-resourced adversaries are already using harvest-now-decrypt-later strategies — capturing encrypted traffic now with the expectation that future quantum machines will reveal the contents.

For most organisations, this is a distant concern. But if you are an IT leader responsible for systems that handle sensitive data with a lifespan beyond 2030 — personal data, financial records, intellectual property, health records, government contracts — you need to start planning now. The transition to post-quantum cryptography is not simple, and it cannot be rushed when the deadline arrives.

This checklist is a structured starting point. It is not a technical manual. It is a framework for understanding your exposure, prioritising your efforts, and building a transition plan that does not disrupt your current operations.

For context on why this matters and how the threat works, the article on post-quantum cryptography for IT leaders covers the strategic landscape in more detail.

Step 1: Identify what encryption you depend on

Before you can protect anything, you need to know where cryptography is embedded in your systems. This sounds straightforward but is often complex in practice — encryption is built into operating systems, applications, network protocols, and cloud services, much of it invisible to the teams using it.

Map your asymmetric encryption usage. RSA, Diffie-Hellman, and elliptic curve cryptography underpin most authentication systems, secure email, VPN connections, digital signatures, and key exchange protocols. Identify every system that uses these — particularly anything handling sensitive data or long-lived secrets.

Identify your symmetric encryption dependencies. AES-256 is currently considered safe against quantum attacks, but AES-128 is not. Audit your storage encryption, database encryption, and backup systems to confirm which key lengths are in use.

Review your TLS configuration. TLS 1.2 and 1.3 use elliptic curve Diffie-Hellman for key exchange — vulnerable to quantum attack. TLS with RSA key exchange is also vulnerable. Check which cipher suites your systems use and which are configured as defaults.

Document cryptographic dependencies by system. Build a register of which systems use which cryptographic algorithms, key lengths, and protocols. Include both internal systems and third-party services where you have limited visibility into the underlying configuration.

This mapping exercise is the foundation of everything that follows. Without it, you cannot prioritise, you cannot budget, and you cannot communicate risk to stakeholders.

Step 2: Classify your data by sensitivity and lifespan

Not all data requires the same protection urgency. The harvest-now-decrypt-later threat is most relevant for data that will still be sensitive in ten to fifteen years. Data with a shorter useful life may not need immediate action.

Identify long-lifespan sensitive data. Personal data, health records, financial history, intellectual property, strategic planning documents, authentication credentials, and government or defence-related information all have lifespans that extend well beyond the quantum threat horizon. Classify everything that falls into this category.

Assess data by consequence of exposure. Some encrypted data, if decrypted in ten years, would cause significant harm. Other data would have degraded in value or relevance. Use this assessment to separate critical encryption from important-but-less-urgent encryption.

Review regulatory requirements. UK GDPR requires appropriate technical measures for personal data — the definition of appropriate will almost certainly evolve as post-quantum standards become established. Sector regulations may also tighten. Build compliance horizon-scanning into your planning.

Consider data in transit versus at rest. Data in transit is immediately vulnerable to interception. Data at rest is protected until an adversary gains access to stored encrypted volumes. Both matter, but the risk profile differs.

Step 3: Audit your cryptographic inventory by system

With your data map in hand, audit specific systems for their cryptographic posture. Use this as a prioritisation tool — not a one-time compliance exercise.

Public key infrastructure. Document your certificate authorities, certificate types, key lengths, and renewal cycles. Certificates with expirations beyond 2030 will need to be reissued with post-quantum algorithms before the deadline. Begin with your most sensitive systems.

Hardware security modules and key management. If you use HSMs for key storage, check with your vendor on their post-quantum roadmap. Many HSM manufacturers have announced plans but timelines vary. Understand what your current hardware can support and what requires replacement.

Cloud services. Cloud providers vary significantly in their post-quantum readiness. AWS, Azure, and Google Cloud have all announced post-quantum support for some services, but the rollout is gradual. Check the cryptography standards supported by each service you rely on and note which are behind on the transition timeline.

VPN and network encryption. Site-to-site VPNs, remote access VPNs, and TLS-terminating load balancers all use key exchange algorithms that will need replacing. Identify which systems terminate TLS and what key exchange algorithms they accept.

Applications and databases. Custom applications with embedded cryptography are particularly difficult to upgrade retroactively. Applications handling sensitive data with long shelf lives are the highest priority for review.

For practical guidance on evaluating your current cryptographic tools and their risks, the guide on browser extension security risks covers a related attack surface — shadow IT and unmanaged cryptographic tools — that often surfaces in these audits.

Step 4: Build a prioritised transition roadmap

The transition to post-quantum cryptography is a multi-year programme. A practical roadmap prioritises by risk exposure and transition complexity.

Immediate priorities (now to twelve months).

Start with systems handling the most sensitive long-lifespan data. Target cryptographic key lengths below 256 bits for symmetric algorithms and below 384 bits for asymmetric algorithms. Begin vendor conversations now — the procurement and implementation cycle for cryptographic hardware and software is long.

Establish a governance structure for the transition. This means assigning ownership — someone accountable for tracking progress, managing vendor relationships, and reporting to leadership. Without explicit ownership, it will not get done.

Medium-term priorities (twelve to thirty-six months).

Migrate public key infrastructure to post-quantum algorithms. This is the most complex part of the transition — PKI underpins authentication, key exchange, and digital signatures across the entire estate. Pilot with lower-risk systems before migrating high-value targets.

Upgrade TLS configurations across all internet-facing services. TLS 1.3 with post-quantum key exchange should be the target configuration. Test thoroughly before broad deployment — algorithm support varies across client populations.

Long-term priorities (three to five years).

Complete the cryptographic inventory migration. Retire legacy RSA and elliptic curve configurations in internal systems. Ensure all new systems are provisioned with post-quantum defaults.

Re-evaluate data previously classified as long-lifespan. Some data classifications will change as the transition completes and risk profiles evolve.

Step 5: Engage your vendors and partners

Your cryptographic posture depends significantly on third-party systems. Vendor readiness is a material factor in your transition timeline.

Request vendor roadmaps. Every vendor whose products handle sensitive data should be able to tell you their post-quantum cryptography roadmap — which algorithms they plan to support, when, and at what cost. Vendors who cannot provide a credible roadmap are a risk to your programme.

Prioritise by concentration. If a single vendor manages the cryptography for your most sensitive systems, their readiness matters more than the readiness of peripheral suppliers. Identify your most concentrated dependencies and engage those vendors first.

Review contractual commitments. Where possible, negotiate contractual obligations for post-quantum support in new contracts. For existing contracts, understand your termination rights if a vendor fails to deliver a credible transition path.

Communicate with strategic partners. If your sensitive data is shared with partners or processed by processors under UK GDPR, the cryptographic posture of those processors is your concern. Request their PQC transition plans and factor them into your own risk assessment.

Step 6: Test in a controlled environment

Before deploying post-quantum cryptography into production, test thoroughly in an isolated environment. The goal is to confirm compatibility with your existing systems and identify any performance or interoperability issues before they affect real services.

Algorithm performance testing. Post-quantum algorithms have different performance characteristics from current algorithms. CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA), the NIST-selected algorithms, have larger key sizes and different computational requirements. Test latency and throughput in realistic traffic conditions.

Client compatibility. Not all client software supports post-quantum TLS. Test against the client populations in your organisation — older operating systems, embedded devices, IoT hardware. Some will not be upgradeable and will require replacement or network-level workarounds.

Key management integration. If you use a key management system, confirm it can store, transmit, and manage post-quantum keys. Key lifecycle management for larger keys has operational implications for storage, transmission, and rotation.

Certificate chain validation. Post-quantum certificates must validate correctly through your entire certificate chain. Check that your certificate authority software, validation libraries, and monitoring systems all handle the new certificate formats.

Step 7: Monitor the standards landscape

Post-quantum cryptography standards are still maturing. NIST finalised the first three standards in 2024, but the ecosystem is still catching up. Your roadmap needs to accommodate evolving guidance.

Track NIST recommendations. NIST continues to evaluate and standardise post-quantum algorithms. The initial standards are considered secure, but future recommendations may introduce new algorithms or deprecate current choices. Assign someone to monitor this.

Monitor browser and platform support. Browser vendors, operating system manufacturers, and cloud platforms are all at different stages of post-quantum support. Track support timelines for the platforms your users and systems depend on.

Watch for deprecation signals. If a widely deployed post-quantum algorithm is found to be vulnerable before it is widely adopted, the recovery cost will be significant. Monitor the cryptographic research community for any indications of weakness in selected algorithms.

Plan for hybrid cryptography. In the transition period, most deployments will use hybrid mode — running classical and post-quantum algorithms in parallel to ensure security even if one fails. Build this flexibility into your architecture from the start.

Step 8: Document and communicate to leadership

IT leaders need to communicate quantum risk to boards and executive teams who may not be familiar with the technical details. The business case for investment depends on clear, credible communication.

Quantify the exposure. Which systems handle data that would cause harm if decrypted in 2035? What would the consequences of exposure be? Frame this as a risk with a specific likelihood and impact, not a theoretical concern.

Estimate transition costs. Hardware upgrades, software licensing, consulting support, internal effort, and testing all have costs that need to be budgeted. Use current vendor information to build realistic estimates — these will be rough at this stage, but they are better than no estimate.

Set a timeline. Communicate when the transition will be complete and what milestones will mark progress. Executive teams need a clear endpoint and a way to track whether you are on course.

Review annually. Update the risk assessment and roadmap annually as the standards landscape clarifies and vendor capabilities become concrete.

---

The transition to post-quantum cryptography is a long-term programme that requires structured planning. If you need support assessing your current exposure or building a transition roadmap, get in touch to discuss how to proceed.