For a decade, post-quantum cryptography was a research topic that security teams could safely park. That window has closed. In late October 2026 NIST published the final version of NIST IR 8547, Transition to Post-Quantum Cryptography Standards, and it is stricter than the draft many organizations based their plans on. Every approved quantum-vulnerable public-key algorithm, whatever its key size, is now scheduled to be deprecated after 2030 and disallowed after 2035. RSA-3072, P-256 and Ed25519 no longer get a five-year grace period.
At the same time, the U.S. federal government, the NSA, the European Union and the UK National Cyber Security Centre have each published migration timelines that converge on the same two dates. For any company that sells software, hardware or services to regulated buyers, or that holds data that must stay confidential into the 2030s, those dates are now procurement requirements, not distant guidance. This article explains what changed, why it matters even if a cryptographically relevant quantum computer is years away, and how to run a migration program that is realistic for an enterprise estate.
Why Post-Quantum Migration Became Urgent in 2026
Shor’s algorithm, run on a sufficiently large fault-tolerant quantum computer, would break the mathematical problems behind RSA, Diffie-Hellman and elliptic-curve cryptography. Nobody can say with confidence when such a machine will exist, and that uncertainty is precisely the problem. Three forces turned an uncertain threat into a planning deadline.
Harvest Now, Decrypt Later
Encrypted traffic captured today can be stored and decrypted later. If your organization exchanges data that must stay confidential for ten or fifteen years, such as health records, intellectual property, M&A material, government contracts or long-lived customer identity data, then the effective deadline for protecting key exchange is already behind you. This is why every major roadmap prioritizes key establishment before signatures: signatures only need to be trustworthy at the moment they are verified, while confidentiality must survive the entire life of the data.
The Standards Are Final
In August 2024 NIST published three Federal Information Processing Standards: FIPS 203 (ML-KEM, a lattice-based key-encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a lattice-based signature scheme from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme from SPHINCS+). In March 2025 NIST selected HQC, a code-based KEM, as a backup to ML-KEM built on different mathematics, and a FIPS for it is under development. FN-DSA, derived from Falcon and expected as FIPS 206, is still being finalized. The final IR 8547 recommends ML-KEM-768 as the default parameter set and states that NIST has no current plans to standardize further KEMs beyond HQC. In other words, the algorithm question is largely settled; the remaining work is engineering.
Deadlines Are Moving Into Contracts
According to analyses of the final IR 8547 by the Cloud Security Alliance and PostQuantum.com, a June 2026 U.S. executive order and the accompanying OMB memorandum M-26-15 require post-quantum key establishment for federal high-value assets and high-impact systems by the end of 2030, post-quantum signatures by the end of 2031, and TLS 1.3 support by January 2030. A proposed FAR rule and CISA minimum elements for a cryptographic bill of materials (CBOM) are expected to follow. When the government buys, vendors comply, and those requirements ripple through the supply chain.
The Global Timeline at a Glance
The headline is convergence. Different authorities use different language, but the milestones line up closely enough to plan against a single internal schedule.
- NIST IR 8547 (final, October 2026): quantum-vulnerable public-key algorithms deprecated after 2030 and disallowed after 2035, regardless of key size. Deprecated means use is still possible, but the data owner must accept and document the risk.
- NSA CNSA 2.0: from January 1, 2027, new acquisitions for National Security Systems are expected to be CNSA 2.0 compliant. Software and firmware signing and traditional networking equipment such as VPNs and routers should use CNSA 2.0 algorithms exclusively by 2030; web browsers, servers, cloud services and operating systems by 2033. The suite specifies ML-KEM-1024, ML-DSA-87, AES-256, SHA-384 or SHA-512, and LMS or XMSS for firmware signing.
- European Union coordinated roadmap (June 2025): member states should start the transition and complete cryptographic inventories by the end of 2026, migrate high-risk use cases by the end of 2030, and migrate medium-risk use cases by the end of 2035. Quantum-vulnerable public-key mechanisms should not be used stand-alone after 2030.
- UK NCSC: define migration objectives, complete discovery and draft an initial plan by 2028; complete the highest-priority migrations by 2031; and finish migrating systems, services and products by 2035.
For a commercial organization, the pragmatic reading is simple: treat 2030 as the date by which critical systems and anything protecting long-lived data must run quantum-safe key exchange, and treat 2035 as the date by which classical public-key cryptography is gone. If you sell into U.S. national security, regulated EU sectors or critical infrastructure, your customers will expect evidence well before those dates.
Step One: Build a Cryptographic Inventory You Can Trust
Every serious PQC program starts with discovery, and almost every team underestimates it. Cryptography is not only in TLS certificates. It lives in code libraries, Java keystores, SSH configurations, VPN concentrators, HSMs, smart cards, firmware signing pipelines, database encryption, message queues, SaaS integrations, IoT devices and partner APIs. Much of it is invisible because it was chosen by a vendor or a framework default.
An inventory that supports migration decisions needs more than a list of certificates. For each cryptographic asset, capture:
- Algorithm and parameters: RSA-2048, ECDSA P-256, X25519, AES-128 and so on, plus the protocol in which they are used.
- Location and owner: application, service, device class or vendor product, and the team accountable for changing it.
- Data sensitivity and shelf life: how long the protected data must remain confidential or the signature must remain trusted.
- Change mechanism: configuration switch, library upgrade, code change, vendor firmware release, or hardware replacement.
- External dependencies: partners, certificate authorities, cloud KMS services and clients that must also support new algorithms.
Combine three discovery techniques rather than relying on one. Network scanning and passive traffic analysis reveal what is negotiated on the wire. Static analysis of source code, binaries and container images finds the libraries and hard-coded algorithms. Configuration and asset data from your CMDB, cloud accounts, PKI and HSMs fills in the managed infrastructure. The output should be machine-readable, because CISA’s forthcoming CBOM minimum elements and customer questionnaires will ask you to produce it on demand. The CycloneDX specification already supports a cryptography bill of materials format, which is a sensible target if you are starting today.
Step Two: Prioritize by Exposure, Shelf Life and Effort
Once you can see your cryptography, you will discover thousands of findings. A risk-based ordering keeps the program from stalling. A useful heuristic, sometimes called Mosca’s inequality, compares three numbers: how long the data must stay secure, how long migration will take, and how long until a quantum attack is practical. If the first two add up to more than the third, you are already late for that system.
In practice, score each system on four factors and migrate from the top down:
- Confidentiality shelf life: systems carrying data that must remain secret past 2035 move first, starting with key exchange on external and inter-data-center links.
- Exposure: internet-facing endpoints, partner connections and traffic crossing untrusted networks are the most likely to be harvested.
- Trust anchors with long lifetimes: root certificates, firmware and secure-boot signing keys and code-signing keys can take years to rotate across a device fleet, so they need early planning even though signature attacks are not retroactive.
- Migration effort and vendor readiness: quick wins where a library or configuration change is enough build momentum and free budget for the hard cases.
Step Three: Start With Hybrid Key Exchange
The fastest, lowest-risk move for most organizations is hybrid key establishment in TLS 1.3, combining a classical exchange such as X25519 with ML-KEM. If either component holds, the session key stays secure, which protects against both an undiscovered weakness in the new algorithm and a future quantum attack on the old one. Major browsers, CDNs and recent releases of mainstream cryptographic libraries such as OpenSSL 3.5 already support hybrid ML-KEM groups, so much of the public web is quietly negotiating them today.
The final IR 8547 makes hybrid deployment easier for regulated environments: hybrid key establishment can be FIPS 140-validated as long as at least one component is NIST-approved, and NIST has signaled updated TLS guidance in the next revision of SP 800-52. Practical steps for this phase include:
- Upgrade load balancers, API gateways, ingress controllers and service meshes to versions that support hybrid ML-KEM groups, and enable them deliberately rather than assuming they are on.
- Test for larger handshake sizes. ML-KEM public keys and ciphertexts are roughly a kilobyte each, which can break middleboxes, legacy proxies or clients with fixed buffer sizes.
- Retire TLS 1.2-only endpoints, since post-quantum groups are defined for TLS 1.3.
- Prioritize VPNs and site-to-site tunnels, which CNSA 2.0 expects to complete by 2030 and which often carry the most sensitive internal traffic.
Step Four: Plan the Harder Signature Transition
Key exchange is mostly a configuration exercise. Signatures are a re-engineering exercise. Moving to ML-DSA or SLH-DSA touches certificate authorities and PKI hierarchies, HSM firmware, code-signing pipelines, document signing, identity cards and secure boot chains. ML-DSA signatures and public keys are significantly larger than ECDSA equivalents, which affects certificate chains, constrained devices, bandwidth-sensitive protocols and anything that stores signatures at scale.
Start with the trust anchors that have the longest lead times. Devices shipped in 2027 with classical-only secure boot may still be in the field in 2037. For firmware and software signing, CNSA 2.0 points to stateful hash-based schemes (LMS and XMSS), which are mature and conservative but require careful state management in the signing infrastructure. For general-purpose PKI, track the IETF work on post-quantum and composite certificates, and run a parallel test hierarchy so that you can issue and validate ML-DSA certificates internally before your public CA offers them.
HSMs deserve special attention. Ask vendors for firm dates for FIPS-validated firmware supporting ML-KEM, ML-DSA and LMS, and check whether your current models can be upgraded or must be replaced. Hardware refresh cycles of five to seven years mean that purchases made in 2026 and 2027 will still be in service when classical algorithms are disallowed.
Crypto-Agility: Design So You Never Do This Again
The deepest lesson of the PQC transition is that cryptography was hard-wired into systems that were never designed to change it. Crypto-agility is the architectural property that lets you swap algorithms, parameters and keys through configuration and policy rather than code rewrites. It matters now because the standards themselves will keep evolving: HQC and FN-DSA are still arriving, hybrid guidance is being refined, and cryptanalysis of new schemes will continue.
- Centralize cryptographic services. Route encryption, signing and key management through a small number of well-governed services or libraries instead of letting each team call primitives directly.
- Externalize algorithm choices. Algorithm identifiers, key sizes and allowed protocol groups should live in policy and configuration, versioned and auditable.
- Automate certificate and key lifecycle. Short-lived certificates and automated rotation, already pushed by shrinking public TLS certificate lifetimes, make an algorithm change just another rotation.
- Bake checks into CI/CD. Scan new code and container images for deprecated algorithms so the inventory stays current and new debt is not added.
- Write it into contracts. Require suppliers to document their PQC roadmap, provide a CBOM and show PQC enabled in production configurations, not merely supported in a datasheet.
The algorithms are settled and the deadlines are converging on 2030 and 2035. What separates organizations now is whether they know where their cryptography lives and can change it through configuration instead of code.
A Worked Example: A Mid-Size SaaS Provider
Consider a hypothetical SaaS company serving financial and healthcare customers across North America and Europe, running microservices on two public clouds, with a customer-facing API, a mobile app, a VPN for administrators and an on-premises appliance sold to large clients.
In the first quarter, the security architecture team combines cloud configuration exports, a scan of public endpoints and a static scan of its repositories and container images. It discovers more than it expected: an old Java service that pins RSA key exchange, a partner SFTP integration using legacy Diffie-Hellman groups, and an appliance whose secure boot chain relies on an RSA-2048 key embedded at manufacture.
Prioritization puts customer data in transit first, because some customers retain records for a decade or longer. In the second and third quarters the team upgrades its CDN configuration, API gateway and service mesh to negotiate hybrid X25519 with ML-KEM-768, tests the mobile app against the larger handshakes and retires two TLS 1.2-only endpoints. The administrator VPN is replaced with a version supporting post-quantum key exchange. The partner integration goes onto a joint roadmap with a contractual date.
The appliance is the long pole. The team works with its hardware supplier on an HSM-backed LMS signing pipeline and a dual-signed firmware release so that new units ship quantum-safe while older units receive a transitional update. In parallel, the company publishes a short PQC statement for customers, generates a CBOM from its inventory tooling, and adds crypto-policy checks to its build pipeline. By the end of year one it has not finished, but it can show auditors and customers a credible, evidence-backed plan aligned to the 2030 and 2035 milestones.
Common Pitfalls to Avoid
- Waiting for a quantum computer headline. Harvest-now-decrypt-later means the risk to confidentiality exists today, and migration of large estates takes many years.
- Treating it as a PKI project only. Certificates are the visible tip; libraries, protocols, firmware and third-party products hold most of the work.
- Assuming vendors have it covered. Supported is not the same as enabled. Verify configurations and get dates in writing.
- Skipping performance and interoperability testing. Larger keys and signatures can break constrained devices, embedded clients and network appliances in surprising ways.
- Rolling your own. Use validated implementations from mainstream libraries and providers; side-channel resistance in new algorithms is subtle.
- Ignoring governance. Without a named owner, a budget line and executive reporting, PQC programs dissolve into scattered tickets.
Outlook: What to Watch Through 2027
Expect the next twelve to eighteen months to bring the final FN-DSA standard, a draft FIPS for HQC, NIST guidance on hybrid TLS, CISA’s CBOM minimum elements and the U.S. FAR rule that will turn federal requirements into contract clauses. CNSA 2.0 compliance expectations for new national security acquisitions begin on January 1, 2027, and EU member states are working toward their end-of-2026 inventory milestone. Cloud providers and certificate authorities will continue rolling out post-quantum options in managed key services and certificates, which will make the platform layer easier and push the remaining difficulty into custom applications and embedded devices.
Conclusion
Post-quantum migration is no longer a question of whether or which algorithms; it is a multi-year engineering and governance program with dates attached. Organizations that start now can sequence the work sensibly: inventory and CBOM first, hybrid key exchange for exposed and long-lived data next, a deliberate signature and hardware plan in parallel, and crypto-agility as the architectural goal that makes future transitions routine. Those that wait will face the same work compressed into fewer years, with customers and regulators asking for evidence. The best time to begin was yesterday; the second-best time is this quarter.
How Hanoi Technology Can Help
Hanoi Technology helps teams run cryptographic discovery, build CBOMs and roll out hybrid post-quantum TLS and crypto-agile architectures through projects, dedicated teams or managed services.
Further Reading
- NIST IR 8547 Final: Post-Quantum Deadlines Become Vendor Requirements – Cloud Security Alliance
- NIST IR 8547 Final analysis – PostQuantum.com
- Timelines for migration to post-quantum cryptography – UK NCSC
- EU PQC Workstream publishes a Coordinated Implementation Roadmap – PQShield
- CNSA 2.0 and January 1, 2027: What Contractors Must Know – Training Camp