Post-quantum cryptography migration plan

Post-quantum cryptography protects against attacks that a sufficiently capable quantum computer could carry out against today's public-key cryptography. A post-quantum cryptography migration strategy matters to IT leaders because replacing encryption protocols, certificates and embedded systems can take longer than a normal software upgrade.

Start with an inventory and a supplier plan. Do not buy a replacement estate on the strength of a predicted date for a cryptographically relevant quantum computer. Its arrival date remains uncertain. The useful question is whether information you protect today must remain confidential long enough for that future threat to matter.

Understand what needs to change

RSA and elliptic-curve cryptography underpin key establishment and digital signatures in many systems. Those functions face a different quantum threat from symmetric encryption such as AES. Increasing an RSA key size does not turn RSA into a post-quantum algorithm.

NIST approved its first three PQC standards on 13 August 2024. Their jobs differ:

These standards specify algorithms. They do not certify every product that implements them, or make every protocol ready to use them. Ask for the supported product version, protocol and validation status relevant to your requirements.

A TLS connection also has several separate cryptographic jobs. Changing key establishment does not automatically replace certificate signatures. A browser reporting a post-quantum key exchange is evidence about that connection, not proof that every component of your application has migrated.

NIST's FAQ says current applications can continue to use AES with 128-, 192- or 256-bit keys. Do not classify AES-128 as broken by quantum computing or apply a single minimum key length across unrelated algorithms. Assess the algorithm, its purpose and the way keys are stored, exchanged and recovered.

Decide which information needs early attention

The concern sometimes called "harvest now, decrypt later" is that an adversary could retain encrypted traffic and try to decrypt it after stronger computing capabilities become available. It is a threat model, not evidence that someone has collected your organisation's traffic.

Review information with a long useful life. Examples might include designs, trade secrets, health records or long-term commercial agreements. Ask the information owner how long disclosure would cause harm, rather than assuming that a statutory retention period is the same as a confidentiality requirement.

Consider a hypothetical manufacturer with three services:

The equipment service may need earlier planning even if it has less traffic. Replacing an appliance or updating devices already in customer premises can be harder than changing a hosted web service.

Build an inventory that supports decisions

A list of certificates is useful but incomplete. Record cryptography where it protects connections, stored information and software authenticity.

For each significant service, capture:

• The business owner, technical owner and supplier.
• The information protected and its confidentiality lifetime.
• Protocols, libraries, algorithms and product versions, with the source of that evidence.
• The purpose of each mechanism, such as key establishment, encryption or signature verification.
• External clients and partners that must remain compatible.
• Key storage, certificate issuance, renewal and recovery dependencies.
• Support expiry, expected replacement date and constraints on updates.
• The next decision, responsible owner and review date.

Start with remote access, externally exposed applications, identity systems, key management, backups and signed software distribution. Include managed services. You still need to understand the boundary between what a supplier changes and what your organisation must configure.

Document uncertainty. "Supplier has not confirmed algorithm support" is a useful finding. "Quantum ready" without a version, scope or technical explanation is not enough to close it.

Ask suppliers questions they can answer

A roadmap should distinguish work in research, preview and supported production releases. Ask suppliers which of your products and deployment modes they mean when they say PQC is available.

Useful questions include:

1. Which standardised algorithms and protocol combinations do you support in our version?
2. Does the change address key establishment, signatures or both?
3. What happens when a client cannot negotiate the new mechanism?
4. Which libraries, appliances, certificates or partner systems must also change?
5. What testing and independent assurance support the implementation?
6. What are the additional licence, hardware and operational costs?
7. Can we observe what was actually negotiated and detect unexpected fallback?
8. What support and rollback procedures apply if compatibility fails?

Add these questions to renewals and purchases through your technical consulting and architecture review. A replacement product with a credible upgrade path may avoid a second replacement later.

Treat hybrid cryptography as a specific design

Hybrid key establishment combines a conventional mechanism with a post-quantum mechanism. The intended security property is that the resulting keys remain secure if one component remains secure. NIST cautions that the construction needs analysis for its application. Combining two algorithms yourself is not sufficient.

Names and versions matter. Google's Chrome transition announcement distinguishes the experimental Kyber768+X25519 combination from the final ML-KEM768+X25519 combination. They use different TLS codepoints and are incompatible. X25519Kyber768 is not an interchangeable name for the standardised ML-KEM combination.

Use a supported implementation rather than assembling cryptographic components. A compatibility fallback may keep a service available while losing the intended post-quantum property. Decide whether that is acceptable for each service and retain evidence of the negotiated configuration.

Pilot against business requirements

Choose a bounded non-production service with representative clients and synthetic data. Include the proxies, load balancers and inspection devices that will exist in production. A successful direct connection between two test machines does not establish compatibility through your full network.

Compare the baseline and proposed configuration for connection success, handshake time, request latency, CPU and memory use, bandwidth and error rates. Include older supported clients, failed negotiation and recovery. Set acceptable thresholds from the service's requirements rather than borrowing another organisation's performance figures.

Record the exact builds and configuration. State what the pilot does not test, including any certificate or signature dependency that remains conventional. Rollback should have an owner and a trigger. If it restores a conventional-only path, record the temporary risk and a date to revisit it.

Fund the migration in stages

An initial business case can cover discovery, supplier responses and a pilot. It does not need to promise a fixed completion date for the whole estate before those dependencies are known.

Separate costs for application work, testing, appliances, certificate services and ongoing support. Align changes with planned renewals where the risk allows. Give leadership a list of priority services, unresolved supplier commitments and decisions that need funding.

Report progress as evidence: the proportion of important services inventoried, supplier responses received, supported paths confirmed and pilots accepted. Avoid a single "PQC complete" percentage that hides incompatible services or untested recovery.

For the implementation record, use the post-quantum cryptography checklist. Keep this programme alongside identity security and zero trust controls; PQC does not prevent stolen credentials or insecure applications.

Turn the inventory into an investment decision

The first deliverable is an owned, prioritised migration plan with known dependencies. It should let a director see which information needs long-term protection, which suppliers can support a transition and where an unsupported system could force early replacement.

If that decision crosses several suppliers or internal teams, book a consultation. My security consulting services can support the risk assessment, supplier questions and pilot acceptance criteria before you commit to a wider rollout.