What are the signs that a post-quantum readiness programme is not working?

A readiness programme is failing when teams cannot identify where cryptography is used, cannot test candidate algorithms safely, or discover compatibility problems only during deployment. Other warning signs include no migration plan, no inventory of certificates and keys, and no way to trial quantum-safe approaches in a controlled environment before standards are finalised.

When readiness stalls at discovery instead of execution

The clearest sign of failure is that the programme cannot answer basic inventory questions quickly and consistently. If teams do not know where cryptography is used, which applications depend on it, or which certificates and keys need attention, the effort is still in assessment mode rather than migration mode. That usually means crypto agility has not been operationalised.

A second warning sign is that readiness outputs stay abstract. The team may have principles and slideware, but no working process for testing candidate algorithms, no safe lab or pilot path, and no way to compare operational impact before standards stabilise. At that point, the programme is not reducing uncertainty, it is preserving it.

Readiness also fails when ownership is unclear. If infrastructure, application, security, and platform teams each assume someone else will adapt the stack, cryptographic change gets deferred until deployment reveals the incompatibility. The programme is only working when discovery, impact analysis, and implementation sequencing are tied to named owners and visible dependencies.

What broken migration paths look like in practice

Compatibility surprises during deployment are a late symptom, not the root cause. They usually point to missing dependency mapping, weak certificate and key lifecycle control, or no controlled way to trial quantum-safe approaches against real systems. A healthy programme identifies breakpoints early, then proves that replacement algorithms, libraries, and certificate workflows can operate without outage or unacceptable regression.

Another failure mode is the absence of a migration plan that distinguishes near-term preparation from eventual cutover. Teams sometimes treat post-quantum readiness as a research topic instead of an engineering programme, so nothing is staged, nothing is prioritised, and no retirement path exists for legacy cryptography. That leaves the organisation exposed to schedule risk as well as technical debt.

The most reliable indicator that the programme is not working is when the organisation cannot explain how it will transition from current cryptography to approved alternatives without service disruption. If there is no sequence for inventory, testing, pilot, rollout, and validation, then “readiness” is just intent, not capability.

Signals that control, governance, and evidence are missing

Good readiness programmes produce evidence: a current cryptographic inventory, a list of systems using each algorithm or certificate type, test results from controlled trials, and a decision log for what to migrate first. When those artefacts are missing, outdated, or kept only in ad hoc documents, the programme has no durable control surface. That makes progress hard to measure and failures hard to prove.

Another sign of weakness is overreliance on a final standard being settled before any preparation begins. In practice, organisations need crypto-agile design choices, inventory discipline, and pilot capability long before every standard is finalised. Waiting for perfect certainty is usually a signal that governance has replaced execution.

A programme also struggles when it cannot show whether changes are happening in the right order. If teams are updating libraries, certificates, or application logic without understanding dependency chains, they may create outages while still failing to reduce cryptographic exposure. The work is only coherent when the transition path is observable and the evidence trail is strong enough for review.

Risk and Threat Considerations

Weak post-quantum readiness increases exposure in two directions: operationally, because unplanned cryptographic changes can break production services, and strategically, because legacy dependencies can remain in place long after the organisation believes it has prepared. The result is a longer period of uncertainty, more brittle deployments, and a higher chance that migration will happen under pressure rather than on schedule.

Failure mechanism: Teams lack a trustworthy inventory, safe testing path, and migration sequence, so cryptographic change is discovered late, implemented inconsistently, or delayed until an urgent cutover.

Impact: Certificate failures, application incompatibility, and stalled migration plans can leave systems unable to adopt quantum-safe approaches when needed, while also increasing the chance of service disruption during rollout.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-57, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-57	Key Management	Post-quantum readiness depends on key lifecycle, algorithm selection, and rotation planning.
Recommendation — Define key lifecycle policy and cryptoperiods that support future algorithm transition.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems within the organization are inventoried	A cryptographic inventory is central to seeing where migration work is needed.
	GV.RM-01 — Risk management strategy is established	Readiness requires a structured migration strategy and risk-based prioritisation.
Recommendation — Inventory systems and cryptographic dependencies before planning migration. Set a risk-based cryptographic transition strategy with owners and milestones.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Cryptographic control selection and transition planning sit within cryptography governance.
Recommendation — Review cryptographic controls and update them to support approved transition paths.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	A controlled baseline is needed to test and roll out crypto changes safely.
Recommendation — Establish and maintain secure baselines before changing cryptographic components.

Practitioner Guidance

What to verify: Confirm that the programme can produce a live cryptographic inventory, identify which services depend on each algorithm or certificate chain, and show at least one controlled pilot of a candidate quantum-safe approach. If any of those artefacts do not exist, the programme is not yet operationally ready.

What good looks like: The organisation can classify cryptographic dependencies by business criticality, test replacements in a non-production environment, and move from assessment to staged remediation without guessing at compatibility. The practical test is whether the next migration decision is evidence-based, not opinion-based.

Practitioner takeaway: Readiness is failing when cryptography is still a hidden dependency; the real goal is not “being aware of post-quantum risk,” but building a migration process that can safely change production cryptography before change is forced on you.