The difficult part of preparing for a future quantum threat is finding every business process that depends on vulnerable cryptography. Banks and companies may know which applications hold sensitive information, yet have a much weaker picture of the certificates, software libraries, devices and external services that protect it. That gap makes post-quantum security a management issue as well as an engineering project.
A useful programme therefore begins with discovery, ownership and realistic replacement plans. Buying a product labelled quantum safe cannot establish that an entire organisation is ready. The relevant question is whether critical information and transactions remain protected across all the systems and suppliers involved in delivering a service.
The technical foundations are becoming clearer. In August 2024, the US National Institute of Standards and Technology released its first three finalised post-quantum cryptography standards. They address key establishment and digital signatures, providing tools for replacing important forms of public-key cryptography. Their availability turns an abstract concern into a planning task, although implementation still depends on products, protocols and operating environments.
A future threat with present planning consequences
Public-key cryptography helps systems establish secure connections and verify identities or software. A sufficiently capable quantum computer could undermine widely used approaches such as RSA and elliptic-curve cryptography. This does not mean that every type of encryption is equally exposed, or that a company can predict the arrival date of such a computer.
The business concern is the relationship between uncertainty and replacement time. An organisation with long-lived equipment or complicated transaction systems may need years to discover dependencies, obtain upgrades and complete testing. Waiting for a precise forecast of quantum capability would leave that implementation work untouched.
Some information also needs to remain confidential long after it is transmitted. The joint CISA NSA and NIST quantum readiness guidance warns about the possibility of collecting encrypted information now for decryption later. This makes the required secrecy lifetime of data relevant to prioritisation.
For example, a hypothetical company holding long-term contractual records faces a different exposure from one transmitting information that loses commercial sensitivity within days. The example does not establish a universal deadline. It illustrates why information owners should help security teams decide which communications and records deserve early attention.
The inventory needs business context
A list of algorithms is a technical starting point. A migration inventory becomes useful when it connects each dependency to an application owner, business service, supplier, upgrade route and expected retirement date. Without those connections, management cannot judge whether a discovery finding represents a minor maintenance task or a major replacement programme.
An externally managed application may rely on a certificate service outside the customer's direct control. A device may accept only a particular form of signed software update. A customer connection may work only when both ends support compatible security settings. Each situation creates a different coordination problem.
The NIST National Cybersecurity Center of Excellence migration project focuses on understanding cryptographic use across hardware, software and services, alongside migration practices. For business leaders, the practical implication is that application lists and procurement records should be reconciled with technical discovery rather than treated as complete evidence on their own.
Discovery will also have limitations. Automated scanning can find some visible dependencies, while others may sit inside packaged software or outsourced infrastructure. An inventory should record uncertainty and missing supplier evidence. Treating an unknown dependency as resolved would create a misleading impression of progress.
Guidance provides milestones rather than certainty
The UK's National Cyber Security Centre offers a useful planning reference in its post-quantum migration timeline. Its guidance sets out discovery and initial planning by 2028, high-priority migration activities by 2031, and completion across systems, services and products by 2035.
Those are UK guidance milestones, not a universal legal deadline for every business. Organisations must consider their own jurisdiction, sector and contractual obligations. The dates are nevertheless useful because they separate preparation from deployment and show that migration is expected to take several stages.
Management should translate external milestones into internal decisions. A plan needs funding assumptions, ownership and dependencies, including products that cannot be upgraded on the required schedule. A long-dated final target is of limited value if the next procurement cycle adds equipment that will be difficult to replace.
Progress should be assessed against evidence. An approved roadmap is one result; tested protection for a priority service is another. Reporting them separately helps boards understand whether the programme is still identifying work or has started reducing exposure.
Procurement can create or remove future costs
Supplier discussions need to move beyond whether a vendor intends to support post-quantum cryptography. Buyers need to understand which products are covered, how support will be delivered, which dependencies remain unresolved and whether implementation requires new hardware or additional licences.
Contract renewal is a practical opportunity to address these questions. A company can request migration information, support commitments and access to relevant testing evidence. The appropriate terms depend on the service and bargaining position, but the commercial objective is consistent: reduce uncertainty before the organisation becomes dependent on a replacement timetable it cannot influence.
Supplier claims require careful interpretation. Supporting an algorithm in one component does not demonstrate that a complete customer workflow uses it. Similarly, a successful demonstration may show feasibility without establishing production capacity, compatibility with all partners or independent validation of the implementation.
There is also a risk of unnecessary early spending. Replacing a system immediately may be wasteful if a supported upgrade will arrive during its normal lifecycle. The stronger business case compares phased upgrading, planned replacement and retirement, including the risks and costs of each route.
Payments show why testing matters
Financial infrastructure illustrates the difficulty of changing security without interrupting service. A payment process depends on several participants, strict message handling and reliable processing under load. A change that works inside one laboratory may encounter different constraints when connected to production-like components.
The BIS Innovation Hub's Project Leap phase two, published in December 2025, tested post-quantum digital signatures in an operational payment system while sending liquidity transfers. The project reported important performance differences and the need to modify multiple components for compatibility.
The finding supports preparation and testing rather than a claim that all payment systems can be converted immediately. An experiment has a defined environment and scope. Its results cannot establish the cost or implementation schedule of a different institution with other software, volumes and counterparties.
For companies outside banking, the same analytical lesson applies to order processing, customer authentication and software delivery. Migration testing should assess the service users receive, including response times, failure handling and partner connections. An algorithm benchmark alone cannot show whether that service remains dependable.
Flexibility needs disciplined control
Cryptographic agility means being able to change cryptographic mechanisms without redesigning an entire service. It is a useful design goal because standards, implementations and threat assessments can develop over time. The benefit comes from reducing future replacement friction, rather than promising permanent security.
Flexibility also creates a control challenge. If too many settings are available without clear ownership, inconsistent configurations can spread. A company may then struggle to explain which protection applies to which connection. A manageable architecture needs approved configurations, version control, change records and a method for withdrawing obsolete options.
Transition arrangements deserve particular scrutiny. Systems may need to interact with partners at different stages of readiness. Engineers should establish what happens when a preferred configuration is unavailable and whether fallback behaviour weakens the intended protection. These choices should be tested and documented rather than left to unnoticed defaults.
Business owners have a role here. They can explain the operational consequences of rejecting a connection, delaying a transaction or taking a system offline. That input helps technical teams design a controlled transition with explicit service trade-offs.
Budgeting for the whole programme
The visible purchase cost may be only part of the migration budget. Discovery, integration, testing, staff training and support can require substantial effort even when an upgrade is included in an existing contract. Legacy applications may also need specialist attention because the people who originally built them are no longer available.
Finance teams can make estimates more useful by separating work that is understood from work that remains uncertain. A funded discovery phase can improve later estimates. Pretending that every dependency is already known may produce a neat budget while increasing the chance of disruption and unplanned spending.
Priorities should reflect potential harm, data lifetime, implementation complexity and available migration routes. These factors will not always point in the same direction. A sensitive service might also be the hardest to change, requiring early preparation even if deployment happens later.
Smaller organisations may have limited influence over underlying technology. Their practical contribution can still be meaningful: identify critical services, request supplier plans, keep supported systems current and avoid contracts that obscure responsibility. A proportionate programme does not require every company to build a cryptography research team.
What useful management reporting looks like
A board report should show which important services have been assessed, where exposure remains uncertain and which decisions need executive intervention. It should distinguish supplier promises from tested capabilities and make overdue dependencies visible.
Counting upgraded devices can be informative but incomplete. A large number of low-risk upgrades could conceal one unresolved dependency in a critical process. Reporting by service, alongside technical coverage, helps connect activity to the consequences for customers and the organisation.
Internal assurance should also consider the quality of evidence. A migration marked complete needs a clear scope, a record of testing and an accountable owner. Residual risks should remain visible where third parties or older systems prevent full implementation.
The business value of this work extends beyond a single technology transition. Understanding cryptographic dependencies can improve procurement, incident response and lifecycle planning. Those benefits do not remove the expense of migration, but they help explain why discovery work is useful even when the timing of the quantum threat remains uncertain.
Retirement can be a migration decision
Some systems may be scheduled for retirement before a full cryptographic upgrade would be economical. That can be a reasonable route if the retirement plan is credible and the organisation understands the exposure until the service closes. A hoped-for replacement with no approved budget is a weaker basis for deferring work.
Retirement also needs to address the information and connections left behind. Removing an application does not necessarily remove archived records, signed files or integrations that other services still use. The responsible teams need to identify what remains and how it will be protected or verified afterwards.
Mergers and acquisitions can complicate this assessment. A business may inherit unfamiliar technology, contracts and suppliers. Including cryptographic dependencies in technology due diligence can help distinguish routine integration work from an unresolved migration liability. Any estimate should reflect the quality of the available evidence rather than imply complete knowledge of the acquired environment.
These decisions are easier to manage when security planning is connected to the ordinary technology investment process. Each renewal, acquisition and retirement then becomes an opportunity to reduce future dependency. The programme can advance through existing decisions while retaining a clear view of work that requires dedicated funding.
Common questions about post quantum migration
Does every company need to replace its systems immediately
No single replacement schedule suits every organisation. The practical first step is to understand exposure and supplier readiness, then prioritise changes according to risk, service requirements and applicable guidance. Unplanned replacement can introduce operational problems of its own.
Can a supplier make an organisation fully quantum safe
A supplier can improve protection within the scope of its product or service. The organisation must still assess connections, other applications, retained data and external dependencies. Readiness is a property of the relevant end-to-end process, not simply a purchasing description.
Post-quantum security is becoming a test of whether organisations understand the infrastructure beneath their services. The most credible programmes will be those that can show what needs to change, who controls the change and how the resulting protection has been tested. That evidence matters more than a distant completion date or an ambitious label.
Reference links
NIST — First three finalised post quantum cryptography standards — 13 August 2024
CISA NSA and NIST — Quantum Readiness Migration to Post Quantum Cryptography Fact Sheet — August 2023
NIST NCCoE — Migration to Post Quantum Cryptography project
https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc
UK NCSC — Timelines for migration to post quantum cryptography — 20 March 2025
https://www.ncsc.gov.uk/guidance/pqc-migration-timelines
BIS Innovation Hub — Project Leap phase two quantum proofing payment systems — 11 December 2025
https://www.bis.org/publications/project-leap-phase-2-quantum-proofing-payment-systems