Quantum computing is not yet known to pose an immediate, practical threat to widely deployed public-key cryptography. Nevertheless, businesses whose information must remain confidential for years face a planning problem today: they may have little visibility into where their networks, applications and suppliers use the cryptographic tools that future quantum computers could undermine. The near-term task is less about purchasing a new security product than understanding what must eventually change.
The standards are here; deployment is the difficult part
The US National Institute of Standards and Technology (NIST) published its first three principal post-quantum cryptography standards in August 2024. FIPS 203 specifies a mechanism for establishing shared secrets; FIPS 204 and FIPS 205 concern digital signatures. These standards offer a technical foundation for updating products and protocols, but they do not automatically secure existing systems.
This distinction matters because public-key cryptography is woven into ordinary operations. Secure web connections, remote access, digital certificates, software updates, signed documents and machine-to-machine communication can all depend on vulnerable algorithms. Replacing them may involve several vendors, different equipment refresh cycles and systems that were never designed for rapid cryptographic change.
In guidance published in October 2026, NIST described a transition roadmap that identifies quantum-vulnerable standards and replacement options. The US roadmap has federal requirements and timelines; private companies should treat it as an important technical reference, not assume every federal deadline applies to them.
Start with systems and data, not a vendor shortlist
A useful inventory records where cryptography is used, what data or transaction it protects, who owns the system, which external providers are involved and how long the protected information needs to remain sensitive. Payment operations may involve certificates, transaction interfaces, identity services and outsourced infrastructure. A professional-services firm may rely heavily on document signing, secure client portals and archives. Those environments demand different priorities.
NIST's migration resources point to discovery and inventory as practical starting points and describe tools for identifying cryptographic services. Automated scanning is useful, but it cannot reveal every dependency inside legacy software, supplier services or embedded hardware. Asset owners and procurement teams need to contribute alongside security specialists.
The inventory should also identify material that could be collected today and decrypted later if a sufficiently capable quantum computer becomes available. This so-called harvest-now, decrypt-later concern is especially relevant where confidentiality obligations last many years. It does not imply that all encrypted traffic is currently being compromised; it changes how organisations prioritise long-lived secrets.
Migration is an operating-model question
The UK's National Cyber Security Centre (NCSC) recommends that larger organisations identify affected services and establish a plan by 2028, perform high-priority migration by 2031 and work towards completing migration by 2035. These are guidance milestones, not a universal legal deadline for every business in every jurisdiction.
A board-level plan can translate that sequence into manageable phases. First, classify affected assets by criticality and data lifespan. Next, ask technology suppliers for supported algorithms, update paths and testing commitments. Then run controlled trials covering certificate management, network performance, backup procedures and compatibility with counterparties. Finally, build crypto-agility into procurement standards so future algorithm changes do not require rebuilding an entire platform.
Financial institutions face additional coordination challenges: an upgraded bank cannot unilaterally change every certificate, API or message format used by its customers and partners. Migration could require parallel support for conventional and post-quantum methods while standards and interoperability practices mature. Security teams should monitor the operational risks of that transition rather than assuming newer cryptography is automatically safer in every deployment.
What directors and procurement teams should ask
Good governance begins with a few measurable questions: Which business-critical services still depend on vulnerable public-key algorithms? What proportion is managed by third parties? Which records must remain confidential well into the next decade? Can contracts require suppliers to disclose upgrade plans and report compatibility risks? Are fallback procedures independently tested?
The answers will vary by sector, and smaller businesses may obtain much of the protection through routine vendor upgrades. But waiting until a replacement product is urgently required can leave organisations dependent on undocumented systems and supplier timetables. The commercial advantage of early preparation is not a promised cybersecurity outcome; it is better visibility into cost, sequencing and operational exposure.
A transition measured in years
Post-quantum readiness is an example of security planning under uncertainty. The timing of a cryptographically relevant quantum computer remains unknown, and the adoption of replacement standards will not eliminate phishing, configuration errors or other routine cyber threats. The immediate priority is a reliable inventory and a practical migration plan. Organisations that understand their cryptographic dependencies can make more disciplined technology and budget decisions as the market develops.
References
NIST — Post-Quantum Cryptography project. Source
NIST — Transition to Post-Quantum Cryptography Standards, October 2026. Source
NIST NCCoE — Migration to Post-Quantum Cryptography — FAQ and inventory resources. Source
UK NCSC — Post-quantum cryptography migration roadmap. Source