Skip to content

Supply Chain & Resilience

Post-quantum readiness

What this is

Post-quantum readiness prepares an organisation's cryptography for algorithms resistant to quantum attack. The first and largest task is a cryptographic inventory: establishing where public-key cryptography is used, what data it protects and for how long that data must stay confidential. Migration cannot be planned for algorithms that have not been located.

The problem

Harvest now, decrypt later means the clock already started for long-lived data.

The quantum threat is unusual because it is a future capability that attacks the past. Encrypted traffic captured today - VPN sessions, TLS connections, encrypted archives - can be stored now and decrypted later, once a cryptographically relevant quantum computer exists. Nobody needs to break the encryption today to benefit from capturing it today.

That inverts the usual planning logic. For data that stops mattering in two years, this is not a current problem. For data that must stay confidential into the 2030s and beyond, the exposure is already live, because the capture is happening now regardless of when the decryption becomes possible.

The honest first step is not migration, it is inventory. Most organisations cannot answer where public-key cryptography is used across their estate, which algorithms and key lengths are in play, which are embedded in appliances and third-party products they cannot change, and which protect data with a long confidentiality requirement. Without that, any migration plan is guesswork.

Who this is for

  • Organisations holding data that must remain confidential for a decade or more - health, financial, legal, defence.
  • Firms whose regulators or major customers have begun asking about quantum readiness.
  • Companies with long-lived embedded systems or appliances where cryptography cannot easily be changed.
  • Teams who cannot currently produce a cryptographic inventory for any purpose, quantum or otherwise.
  • Organisations planning a multi-year infrastructure programme where crypto-agility should be designed in now.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 011 week

    Scope and approach

    Which parts of the estate are in scope and how cryptography will be discovered - configuration analysis, traffic inspection, code and vendor documentation.

  2. 023-4 weeks

    Build the inventory

    The largest task by far, and the one with lasting value regardless of quantum timelines - a cryptographic inventory is useful for several other purposes.

  3. 031-2 weeks

    Map data lifetimes

    How long each data class must stay confidential, done with the business and with legal rather than assumed.

  4. 041-2 weeks

    Prioritise and sequence

    The intersection of long-lived data and vulnerable algorithms, sequenced into a migration plan with crypto-agility work first.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Post-quantum readiness, with what each one contains and when it lands
DeliverableWhat it containsWhen
Cryptographic inventoryWhere public-key cryptography is used across the estate, which algorithms and key lengths, and in what protocols. Includes what is embedded in third-party products.Week 3-5
Data lifetime mappingHow long each protected data class must remain confidential, which is what determines urgency. Most estates have a small subset with genuinely long horizons.Week 4
Exposure prioritisationWhere long confidentiality requirements meet vulnerable algorithms on capturable channels - the intersection is the actual priority list, and it is usually short.Week 5
Crypto-agility assessmentWhere algorithms are hardcoded versus configurable, because agility determines whether migration is a change or a rebuild.Week 6
Supplier positionWhere your critical suppliers stand on post-quantum roadmaps, since much of your cryptography is in products you do not control.Week 6
Sequenced migration planA realistic multi-year sequence starting with the highest-exposure systems, aligned to standards and vendor availability rather than to a wish.Week 7-8

Frameworks this touches

FAQ

Questions people actually ask

What is harvest now, decrypt later?

It is the practice of capturing encrypted data today and storing it until decryption becomes feasible. Because the capture and the decryption are separated in time, an adversary does not need quantum capability today to benefit from collecting today. This is why data with a long confidentiality requirement is already exposed, and why the planning horizon is set by data lifetime rather than by when quantum computers arrive.

Which cryptography is affected?

Public-key cryptography is the primary concern: RSA, Diffie-Hellman and elliptic curve algorithms, which underpin TLS key exchange, digital signatures, VPNs and code signing. Symmetric cryptography such as AES is affected far less severely and is generally addressed by increasing key length. The practical implication is that key exchange and signatures need migrating, while bulk encryption largely does not.

Should we start migrating now or wait?

Start the inventory now and migrate on a prioritised basis. The inventory is the long pole, takes months in a large estate, and is useful for several purposes beyond quantum. Migration itself should be sequenced by exposure, starting with long-lived data on capturable channels, and paced against standards maturity and vendor support. Waiting until migration is urgent means starting the inventory when there is no time for it.

What is crypto-agility and why does it matter more than the algorithm choice?

Crypto-agility is the ability to change cryptographic algorithms without rebuilding the system - algorithms configured rather than hardcoded, key sizes parameterised, protocol negotiation supported. It matters more than any specific algorithm choice because it is what makes the next transition tractable. Organisations that build agility now will migrate on a schedule; those that do not will rebuild systems under time pressure.