Post-Quantum Migration Starts With Knowing Where Cryptography Is Hiding

NIST’s October transition roadmap makes cryptographic discovery a practical planning task, without requiring a prediction of when a powerful quantum computer arrives.

The first problem is visibility

An organisation cannot replace a cryptographic dependency it has not identified. Encryption and digital signatures can appear in applications, certificates, devices, supplier services and archived information. A transition programme therefore begins with an inventory of functions and dependencies, not merely a procurement decision to buy something labelled quantum-safe.

NIST’s 27 October 2026 announcement describes its final Transition to Post-Quantum Cryptography Standards report, NISTIR 8547. The agency says it identifies quantum-vulnerable standards and their replacements, and describes migration activities and timelines for federal agencies. NIST also highlights supply-chain complexity. This is analysis of that published roadmap, not a claim that a cryptographically relevant quantum computer already exists or that federal requirements automatically bind every private organisation.

Record what the cryptography is doing

A useful inventory distinguishes protection of stored information, establishment of secure connections and verification of signatures. These functions can have different dependencies and replacement paths. Recording only an algorithm name may leave the organisation unable to tell which business process would fail if that component changed.

For each important use, identify an accountable service owner, the supplier or implementation, the protected information and the likely lifetime of the dependency. Some details will require specialist discovery tools or supplier cooperation. Mark unknowns explicitly. An incomplete but honest inventory supports a plan to investigate; an apparently complete spreadsheet built from guesses can give a programme confidence it has not earned.

Information has a protection lifetime

NIST identifies the concern commonly described as harvesting encrypted information now for potential decryption later. The relevant planning question is therefore not only whether an attack can occur today. It also includes how long the information must remain confidential and how long migration is likely to take.

That does not justify a universal deadline invented by a commentator. A record with a short useful life differs from information intended to remain sensitive for decades. An organisation needs to classify its own requirements, understand the applicable guidance and obtain qualified security advice. The risk assessment should state its assumptions rather than disguising uncertainty about future technology as a precise forecast.

The supplier’s promise needs an implementation path

A supplier may describe a future capability without specifying which product version supports it, how interoperability is tested or what customers must change. Procurement teams should ask for a roadmap tied to the service they actually use. A corporate research announcement is not equivalent to a supported migration option for a deployed system.

Useful questions concern dependencies, upgrade conditions, customer responsibilities and support for testing. The answers should become part of service planning rather than remain in a presentation. Where the supplier cannot yet provide a firm commitment, record that limitation. The purpose is to understand exposure and alternatives, not force a confident date from someone who lacks the evidence to give one.

Test the change as an operating change

Replacing cryptographic components can affect the surrounding system. A technically valid implementation still needs to work with the applications, devices and partners that rely on it. Testing should therefore examine real workflows and failure handling as well as conformance with the relevant technical standard.

A hypothetical organisation changing certificate infrastructure might need to verify older clients, monitoring tools and recovery procedures. The exact tests depend on architecture and should be designed by qualified practitioners. The broader management point is straightforward: cryptographic modernisation belongs in change control. It needs a test environment, responsible owners, a deployment sequence and a way to detect whether expected connections or signatures stop working.

Agility requires a maintained capability

An organisation gains little long-term flexibility if it replaces one opaque dependency with another. Cryptographic agility means being able to understand and change implementations as requirements evolve. That involves architecture, contracts, documentation and people capable of carrying out the transition. It cannot be proved by a single product label.

The inventory should therefore remain current after the initial programme. New services should enter it, retired systems should leave it and material supplier changes should trigger review. This is ordinary operational ownership applied to a specialised dependency. It reduces the chance that the next transition begins with the same expensive rediscovery of forgotten certificates, unsupported devices and undocumented service relationships.

Retirement also deserves scrutiny. Before removing an old verification service, establish whether retained records still depend on it. A system can leave daily operation while remaining necessary to interpret or validate information kept for a longer period.

A useful plan can proceed without a countdown

The uncertain arrival date of a powerful quantum computer is not a reason to pretend every task must wait. Discovery, classification and supplier engagement are preparatory activities that can be sequenced according to their cost and relevance. Equally, uncertainty is not permission to present every system as an immediate emergency.

NIST’s roadmap gives organisations a concrete reference for the technical transition. Their own next step is to connect that reference to an accurate map of what they operate and which obligations apply. Progress should be reported through known dependencies, tested options and resolved migration obstacles. The most credible programme can explain what it knows, what remains uncertain and which practical action comes next, without selling a prediction it cannot substantiate.

Gabriel Nicolaev — CyGuru

Sources & further reading

NIST: Guidelines for Transition to Post-Quantum Cryptography Standards, 27 October 2026 ↗

Editorial photograph for illustration.

FOLLOW THE CONNECTION

Another angle on this subject

Continue through related ideas, decisions and consequences.

Technology & AI

For a Solo Business, Cybersecurity Begins With the Ability to Recover

NIST’s new guide for solo business owners offers a starting point. Our analysis asks which accounts and files the business cannot operate without.

Technology & AI

When intelligence becomes cheap, judgment becomes expensive

As AI makes competent-looking output easier to produce, the scarce business capability shifts toward defining the problem, checking the answer and owning the consequence.

Culture & Ideas

Translation Preserves Meaning When It Makes Difficult Choices Visible

A fluent translation can conceal uncertainty about tone, context and concepts that do not fit neatly into the receiving language.