← Back to knowledge areas
Knowledge area 08

Quantum
Readiness

Quantum readiness is not a prediction exercise. It is the ability to understand exposure to quantum-vulnerable public-key cryptography and to prepare an orderly, risk-based transition to post-quantum cryptography.

The migration challenge connects every part of cryptographic resilience: discovery, dependency mapping, governance, crypto-agility, PKI, key management and third-party readiness.

The uncertainty of the quantum timeline does not remove the need to prepare.

Cryptographically relevant quantum computers do not exist today at the scale required to break widely deployed public-key cryptography. The exact future timeline remains uncertain. Risk management therefore should not treat a speculative date as the primary planning input.

The more actionable question is whether data, systems and business processes depend on public-key cryptography that will require replacement — and how long the organisation needs to discover, prioritise, test and migrate those dependencies.

Risk lens

Quantum risk is partly a future threat problem, but quantum readiness is a present-day dependency, governance and change-management problem.

Not all cryptography is affected in the same way.

The most urgent migration concern is current public-key cryptography based on mathematical problems that sufficiently capable quantum computers could solve efficiently.

PUBLIC-KEY

RSA

Widely used for signatures and key establishment. A sufficiently capable quantum computer would undermine the mathematical assumptions on which RSA security depends.

PUBLIC-KEY

Elliptic-curve cryptography

ECC-based signatures and key-establishment mechanisms are also considered quantum-vulnerable and require transition planning.

SYMMETRIC

Symmetric cryptography

Quantum impact is different from the effect on RSA and ECC. Symmetric algorithms are not replaced by PQC public-key standards in the same way; appropriate key strengths and current guidance still matter.

HASHING

Hash functions

Hashing is affected differently from public-key cryptography. Organisations should follow applicable standards rather than treating every cryptographic mechanism as equally vulnerable.

Migration lead time can be longer than the threat lead time.

Long-lived sensitive dataInformation requiring confidentiality for many years may warrant earlier attention, including consideration of capture-now/decrypt-later exposure.
Large dependency estatesPublic-key cryptography is embedded across applications, protocols, certificates, devices, libraries, identity systems and infrastructure.
Technology refresh cyclesHardware and commercial products may require planned upgrades or replacement before PQC support is available.
Supplier timelinesAn organisation may depend on cloud, SaaS, software, PKI and hardware providers to expose supported migration paths.
InteroperabilityMigration affects communicating parties and protocols; compatibility and testing can constrain deployment sequencing.
Operational changePKI, key management, identity, application and network processes may all require coordinated updates.

From awareness to controlled transition.

A useful readiness programme can be organised around six connected activities rather than a single technology replacement project.

01DiscoverIdentify where quantum-vulnerable public-key cryptography exists across systems, software, protocols, certificates, devices and services.
02ContextualiseConnect cryptographic findings to business criticality, data sensitivity, required protection lifetime, owners and dependencies.
03Assess & prioritiseEvaluate exposure, migration complexity, external dependencies and the consequences of delayed transition.
04GovernSet decision rights, standards, risk acceptance, programme ownership, reporting and transition principles.
05Plan & migrateBuild roadmaps, coordinate suppliers, test interoperability and transition systems using approved PQC-capable technologies.
06Sustain agilityMaintain inventories and design future cryptographic change so the next transition is faster and less disruptive.

PQC is no longer only a research topic.

NIST published its first three final post-quantum cryptography standards in August 2024. FIPS 203 specifies ML-KEM for key establishment, while FIPS 204 and FIPS 205 specify the ML-DSA and SLH-DSA digital signature standards. NIST states that organisations should begin applying these standards and migrating systems to quantum-resistant cryptography.

FIPS 203

ML-KEM

A module-lattice-based key-encapsulation mechanism used to establish shared secret keying material.

FIPS 204

ML-DSA

A module-lattice-based digital signature standard for authentication and integrity use cases.

FIPS 205

SLH-DSA

A stateless hash-based digital signature standard providing a different cryptographic foundation from ML-DSA.

ONGOING

Additional standards

NIST continues standardisation work on additional algorithms. Migration governance should distinguish final standards from algorithms or profiles still under development.

Governance principle

Do not build the programme around chasing every new algorithm announcement. Build governance that can adopt approved standards when the relevant products, protocols and use cases are ready.

Prioritise by exposure and migration difficulty — not fear.

A risk-based roadmap should combine the sensitivity and required protection lifetime of information with business criticality, quantum-vulnerable cryptographic use, external exposure, migration complexity and supplier readiness.

Data protection lifetimeHow long must confidentiality remain effective, and could encrypted information be collected now for future decryption?
Business criticalityWhat is the impact if the affected service, identity mechanism or trust relationship cannot migrate on time?
Quantum-vulnerable useWhich public-key algorithms and protocols are actually used, and for what security purpose?
Migration complexityIs the cryptography configurable, embedded, hardware-bound, proprietary or dependent on coordinated ecosystem change?
Supplier readinessAre vendors providing supported PQC roadmaps, product versions and interoperability plans?
Change windowHow long would design, procurement, testing, deployment and fallback realistically take?

What should Information Security Risk Management expect to see?

Accountable programme ownershipClear governance for PQC transition across security, architecture, technology, risk, procurement and business ownership.
Cryptographic inventoryEvidence of quantum-vulnerable public-key cryptography, its purpose, location, owner and relevant technical dependencies.
Business and data contextCriticality, data sensitivity, protection lifetime and external exposure linked to cryptographic findings.
Risk-based prioritisationA documented method for determining which systems and data require earlier migration attention.
Migration roadmapSequenced remediation plans aligned to technology refresh, standards, supplier capability and realistic testing windows.
Supplier engagementEvidence that critical vendors are being asked about embedded cryptography, PQC support, timelines and migration constraints.
Crypto-agility assessmentUnderstanding of where cryptographic replacement is straightforward and where architecture or product constraints make change difficult.
Progress and residual riskMetrics, exceptions, blockers and risk acceptance that allow leadership to understand readiness over time.

Useful questions for a risk conversation.

01

Do we know where RSA, ECC and other quantum-vulnerable public-key mechanisms are used across our critical services?

02

Which sensitive datasets require confidentiality for long enough that future decryption is relevant to today's risk?

03

Which critical systems would be hardest to migrate because cryptography is embedded in products, hardware or protocols?

04

Who owns the enterprise PQC transition risk and who owns remediation within individual services?

05

Which suppliers control our ability to migrate, and have we obtained credible roadmaps from them?

06

Are architecture and procurement decisions being made today that could create new long-lived quantum-vulnerable dependencies?

07

How will we test interoperability, performance and operational impact before production migration?

08

Are we using the PQC transition to improve long-term crypto-agility rather than creating the next hard-coded dependency?

Quantum readiness is the outcome of good cryptography governance.

An organisation that can discover its cryptography, understand dependencies, assign ownership, prioritise risk and execute controlled change is already building the capabilities required for PQC migration.

The goal is not simply to become “post-quantum compliant.” It is to become resilient enough to manage this transition — and the cryptographic transitions that follow it.

Standards and guidance behind this page.

Quantum-computing timelines remain uncertain. This page intentionally focuses on risk-based preparedness and current public standards rather than predicting when a cryptographically relevant quantum computer will exist.

Previous knowledge area← Third-Party DependenciesKnowledge baseReturn to all topics →