The Readiness Methodology — Quantum-Safe: Readiness Assessment

Quantum readiness becomes difficult when it is treated as one giant instruction: replace the cryptography. In a real organisation, cryptography is scattered through certificates, applications, cloud services, identity systems, devices, partners, and old code nobody likes to touch. The way through is not panic and not a one-time audit. It is a repeatable programme: govern, discover, assess, plan, execute and monitor.

Why a methodology matters

Post-quantum cryptography is not just a new set of algorithms. It is a migration of trust. That trust may sit in Transport Layer Security (TLS) connections, Virtual Private Network (VPN) gateways, code-signing systems, public key infrastructure, databases, firmware update channels, payment flows, identity providers, and third-party products.

Without a method, teams tend to make one of two mistakes. They either freeze because the problem feels too large, or they chase the most visible system rather than the most exposed one. A public website may look urgent because everyone can see it. A quiet archive containing sensitive data that must remain secret for twenty years may be more important.

The Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the National Institute of Standards and Technology (NIST) have published guidance on preparing for migration to post-quantum cryptography (PQC). Different organisations will adapt the details, but the shape is consistent: establish ownership, find the cryptography, rank the risk, build the plan, then migrate and keep watching.

📌

The core idea. Quantum readiness is a security programme with governance, inventory, risk management, delivery, and review, not a single technical scan.

The five phases

The readiness methodology can be expressed in five phases: govern, discover, assess risk, plan, and execute and monitor. The names are simple, but the order matters.

Govern comes first because migration competes for money, time, and change windows. Discover comes next because no team can protect cryptography it has not found. Risk assessment turns the inventory into priorities. Planning turns those priorities into a funded sequence of work. Execution then moves systems in controlled waves and feeds new findings back into discovery.

This sequence is useful because it gives every conversation a place to land. If someone asks whether a system is in scope, that is governance. If they ask where a certificate or algorithm is used, that is discovery. If they ask what must move first, that is assessment. If they ask when it will move, that is planning. If they ask whether the change worked and remains safe, that is execution and monitoring.

After governance, the core phases repeat as execution feeds new findings back into discovery.

Phase one: govern before you scan

Governance sounds administrative, but it is what prevents the work from disappearing when it meets the first budget conflict. A senior sponsor must make clear that quantum readiness is a multi-year migration programme, not an optional research exercise.

The organisation should name a programme lead, define the initial scope, agree how risk will be reported, and create a place to track decisions. Scope should cover more than central security tools. It should include business applications, cloud platforms, identity services, operational technology where relevant, suppliers, and data flows to partners.

Good governance also sets the tone for vendor conversations. Suppliers should be asked how they use cryptography, whether they can provide a cryptographic bill of materials, what their PQC roadmap is, and how they will support transition modes such as hybrid key exchange where those are appropriate.

Name an executive sponsor who can fund and unblock the programme.
Appoint a PQC programme lead with authority to coordinate across teams.
Write a short charter that defines scope, reporting, and success measures.
Create a risk register for findings, owners, dates, and decisions.
Make PQC readiness a standard topic in supplier and procurement reviews.

Phase two: discover where cryptography lives

Discovery is the first technical deliverable. Its purpose is to build an inventory of where cryptography is used, what algorithms and key sizes are involved, what data or trust relationship they protect, who owns the system, and whether the organisation can change it.

The main output is often called a Cryptographic Bill of Materials (CBOM). A CBOM is not merely a list of algorithms. A useful CBOM connects cryptography to business context: the application, the data, the protocol, the certificate authority, the library, the device, the supplier, and the dependency path.

Discovery is harder than it sounds because cryptography hides in many layers. Some is visible in network traffic. Some is compiled into software libraries. Some is embedded in appliances. Some is managed by cloud providers. Some sits in contracts with vendors who do not yet provide enough detail.

A useful CBOM connects each algorithm to its application, data, owner, and supplier.

Phase three: assess risk, not noise

Once there is an inventory, the next question is not simply which systems use Rivest-Shamir-Adleman (RSA) or elliptic curve cryptography (ECC). Many will. The better question is which uses create the most urgent exposure.

Risk depends on several factors: how long the protected data must remain confidential, how long the system will take to replace, how exposed the system is, how important the trust anchor is, and whether an attacker can collect the encrypted material today and decrypt it later. That last scenario is often called harvest now, decrypt later.

One useful framing is Mosca's inequality. In plain terms, it asks whether the shelf life of the secret plus the time needed to migrate is greater than the time until a cryptographically relevant quantum computer exists. If the answer may be yes, the system deserves early attention. This is not a prediction tool. It is a prioritisation tool for deciding where delay is dangerous.

The output of this phase is a ranked risk register. It should not be a vague heat map. It should name the system, the cryptographic dependency, the data or trust at stake, the owner, the urgency, the proposed treatment, and the next decision needed.

⚠️

Do not rank by visibility alone. The system that is easiest to see is not always the system where long-lived confidentiality or long-lived trust is most at risk.

If secrecy plus migration time exceeds time-to-quantum, the system needs early attention.

Phase four: plan the migration path

Planning turns risk into a roadmap. This is where teams decide what moves first, what must wait for vendor support, what needs testing, what depends on a certificate authority or protocol change, and what budget or people are required.

A good roadmap respects dependencies. An application cannot use a new cryptographic mode if the platform does not support it. A customer-facing service cannot change safely if older clients break. A signing system cannot be replaced casually if downstream systems reject the new signatures. Planning is where these constraints become visible before they become incidents.

Some systems may use hybrid approaches during transition. A hybrid design combines a classical algorithm with a post-quantum algorithm so that security does not depend on only one new mechanism. Hybrid modes can be useful, but they are not magic. They add complexity, require interoperability testing, and should be chosen for a reason.

Sequence systems by risk, dependency, and business change windows.
Identify where standards, products, or suppliers are not ready yet.
Decide where hybrid modes are needed during transition.
Define testing for performance, interoperability, rollback, and failure handling.
Assign funding, owners, milestones, and reporting dates.

A migration plan must clear platform, client, and signing dependencies in turn.

Phase five: execute, monitor, and feed the loop

Execution should happen in waves. Start where the risk is meaningful and the change can be controlled. Test in lower environments, measure performance, check interoperability, validate logging and monitoring, and rehearse rollback. Then move through production in a sequence the business can absorb.

Monitoring matters because the cryptographic landscape will keep changing. Standards mature. Software libraries add support. Suppliers publish or revise roadmaps. New assets are discovered. Threat assumptions change. A readiness programme must therefore feed execution findings back into discovery and assessment.

This is also where crypto-agility becomes practical. Crypto-agility means the ability to change cryptographic algorithms, parameters, libraries, certificates, or protocols without redesigning the whole system each time. A migration that only swaps one hard-coded algorithm for another has not solved the deeper operational problem.

✅

The mature pattern. Successful organisations treat quantum readiness like vulnerability management or identity governance: owned, measured, repeated, and improved.

The decisions leaders and practitioners actually face

For leaders, the readiness methodology turns a vague future threat into a set of management decisions. Who owns the programme? Which business units are in scope this year? How much supplier uncertainty can the organisation accept? Which data classes justify early investment? What risk is being carried by waiting?

For practitioners, the same methodology turns anxiety into work packages. Which repositories need inspection? Which certificates and protocols must be inventoried? Which applications depend on libraries that do not yet support PQC? Which test environments can prove a hybrid mode safely? Which owners must approve a production change?

The most important decision is to begin before every answer is known. Early discovery will be incomplete. Some vendors will not be ready. Some standards and implementation guidance will continue to evolve. That is exactly why the method is a loop. The first pass creates enough visibility to make the second pass better.

Key takeaways

Quantum readiness is a repeatable programme, not a one-off audit.
The five phases are govern, discover, assess risk, plan, and execute and monitor.
Governance comes first because ownership, scope, funding, and authority determine whether the work survives competing priorities.
Discovery produces the Cryptographic Bill of Materials, which connects cryptography to systems, data, owners, and suppliers.
Risk assessment should prioritise long-lived secrets, long-lived trust anchors, migration difficulty, and harvest-now-decrypt-later exposure.
The methodology is a loop because new standards, new threats, new assets, and new supplier information continually change the plan.

Glossary

Post-quantum cryptography: Cryptographic algorithms designed to resist attacks from both classical computers and cryptographically relevant quantum computers.
Cryptographic Bill of Materials: An inventory that records where cryptography is used, what it protects, who owns it, and what dependencies affect changing it.
Risk register: A tracked list of risks that includes owners, severity, decisions, deadlines, and treatment plans.
Mosca's inequality: A prioritisation rule of thumb that compares how long data must stay secret plus migration time against the expected time before a relevant quantum threat.
Harvest now, decrypt later: An attack strategy in which encrypted data is collected today with the intention of decrypting it in the future when better capabilities exist.
Crypto-agility: The ability to change cryptographic algorithms, parameters, keys, certificates, or libraries without redesigning an entire system.
Transport Layer Security: A widely used protocol that protects network communications, commonly used for secure web and application traffic.
Public key infrastructure: The system of certificates, certificate authorities, policies, and processes used to establish and manage digital trust.