The first widely used post-quantum cryptography standards now exist, but replacing vulnerable cryptography is not a one-line software update. Encryption and digital signatures are embedded in browsers, cloud services, identity systems, firmware, industrial equipment, payment infrastructure, and products expected to operate for decades.
That makes migration a discovery and coordination problem before it becomes an algorithm deployment problem. An organization cannot replace cryptography it does not know it uses. The practical starting point is a cryptographic inventory: a map of algorithms, keys, certificates, protocols, libraries, hardware, data lifetimes, and supplier dependencies across the technology estate.
Post-quantum cryptography runs on ordinary computers
Post-quantum cryptography, usually shortened to PQC, uses mathematical problems believed to resist attacks from both classical and future quantum computers. It is implemented in software and conventional hardware. It should not be confused with quantum key distribution, which uses specialized physical links and quantum states.
The threat comes from sufficiently capable quantum computers potentially breaking public-key systems based on integer factorization or discrete logarithms. Those systems protect key exchange and digital signatures throughout modern networks. Symmetric encryption is affected differently and can generally respond with appropriate key sizes, but public-key infrastructure requires new algorithms and protocols.
NIST standards provide building blocks, not a finished migration
In 2024, the US National Institute of Standards and Technology finalized FIPS 203, FIPS 204, and FIPS 205. They specify ML-KEM for establishing shared secrets and ML-DSA and SLH-DSA for digital signatures. These standards give vendors and standards bodies stable algorithm definitions on which products can be built.
An algorithm standard does not automatically update TLS connections, certificate authorities, secure boot systems, code-signing services, hardware security modules, smart cards, or embedded controllers. Each surrounding protocol and implementation needs profiles, interoperability testing, operational tooling, and deployment support.
The timetable is uncertain, but data can have a long memory
No one can responsibly name the date when a cryptographically relevant quantum computer will exist. Progress in hardware, error correction, and system engineering has to be judged with complete resource estimates rather than raw qubit counts, as our guide to fault-tolerant quantum resource budgets explains.
Migration still starts before that date because some information must remain confidential for many years. An adversary could collect encrypted traffic now and attempt to decrypt it later. Long-lived secrets, medical records, intellectual property, government information, and infrastructure credentials may therefore need earlier protection than disposable data.
A cryptographic inventory connects code to consequences
A useful inventory records where public-key cryptography is used, which algorithm and parameter set is involved, who owns the system, what data it protects, how long that protection must last, and whether the component can be upgraded. It should cover data in transit, stored data, signatures, authentication, firmware updates, and machine identities.
Scanning source code for familiar algorithm names is not enough. Applications may inherit cryptography from operating systems, cloud platforms, network appliances, third-party libraries, certificates, service meshes, or managed identity providers. Dynamic discovery from traffic and configuration can complement software composition and asset inventories.
Hidden dependencies are often the hardest part
Many products expose a simple secure connection while hiding several cryptographic layers underneath. A mobile application may rely on a cloud API, a certificate authority, a content delivery network, an identity provider, and signed updates. Industrial equipment may contain bootloaders and chips that cannot support larger keys or signatures.
Procurement records and supplier conversations belong in the inventory. CISA, NSA, and NIST guidance urges organizations to engage vendors and include commercial technology dependencies in a quantum-readiness roadmap. A supplier’s delivery schedule can become the critical path for an otherwise well-managed migration.
Cryptographic agility is an engineering capability
Crypto agility means a system can change approved algorithms, parameters, certificates, and keys without being redesigned. It requires clean interfaces, configurable policies, version negotiation, observability, testing, and a reliable update channel. Simply adding a second algorithm identifier to a configuration file is not enough.
Agility also needs governance. Teams must know who can authorize a transition, how compatibility is measured, and how an emergency rollback works. The release process should preserve traceability through mechanisms such as authenticated software build provenance, because future firmware and library migrations will depend on trustworthy updates.
Hybrid deployment reduces some transition risks
During a transition, systems may combine a traditional key exchange with a post-quantum mechanism so that breaking one component does not immediately break the combined protection. Hybrid approaches can preserve compatibility while new implementations gain operational experience.
They also add complexity. Messages and certificates may grow, handshakes may take more processing or bandwidth, and implementations have more failure modes. A hybrid design should be specified by the relevant protocol ecosystem rather than improvised independently by every product team.
Performance tests must include the whole protocol
Algorithm benchmarks measured on a server CPU do not reveal how a migration behaves on a constrained sensor, smart card, phone, or high-volume service. Engineers need to test key generation, handshake latency, memory, message size, battery use, certificate chains, signing throughput, and recovery under real network conditions.
Compatibility failures deserve equal attention. A middlebox may reject an unfamiliar message size, an old client may not negotiate a new suite, or a hardware root of trust may be impossible to update. Laboratory success is only one step toward a resilient production rollout.
Signatures and encryption have different priorities
Confidentiality planning focuses on how long captured data must remain secret. Signature planning focuses on how long authenticity must remain verifiable and whether a forged update or identity could cause harm. Software signing, secure boot, document archives, certificates, and machine identities may therefore follow different schedules.
Post-quantum migration is also separate from building quantum networks and repeaters. The two technologies can coexist, but PQC is the broadly deployable response for today’s digital infrastructure because it uses existing computing and communication channels.
Milestones help turn an open-ended risk into a program
The UK’s National Cyber Security Centre recommends completing discovery and an initial migration plan by 2028, protecting the highest-priority services and refining the plan by 2031, and aiming to complete migration by 2035. Those dates are guidance, not a prediction of when a quantum computer will break current systems.
Different organizations will have different priorities. Long-lived data, critical services, hard-to-replace hardware, and products with slow certification cycles should usually appear early in planning. Systems near retirement may be replaced rather than modified.
Limitations
PQC standards and implementation guidance continue to evolve. Some internet protocols, certificate ecosystems, and hardware platforms do not yet have settled deployment profiles. New code can also introduce conventional bugs, side-channel leakage, weak randomness, or configuration errors even when the underlying algorithm is sound.
An inventory can become stale if it is treated as a one-time spreadsheet. It needs owners, automated evidence where practical, links to asset and software records, and updates when products or suppliers change.
What to watch next
Watch for interoperable PQC profiles in TLS, public-key infrastructure, secure boot, identity, and industrial protocols; validated hardware and software modules; vendor roadmaps with specific upgrade paths; and tools that can discover cryptography without exposing sensitive key material.
The mathematical standards are a major milestone. The next challenge is less dramatic but more consequential: finding every place old cryptography lives and moving each dependency without breaking the systems that rely on it.
Sources: NIST approval of FIPS 203, 204, and 205; CISA, NSA, and NIST quantum-readiness roadmap; CISA strategy for automated PQC discovery and inventory tools; UK NCSC timelines for post-quantum migration.
Leave a Reply