Post-Quantum Migration for Business: A Practical Roadmap to 2035

Most technology migrations are driven by a product reaching end of life. The post-quantum migration is different. The systems still work perfectly; the mathematics under them is on a published retirement schedule. RSA and elliptic-curve cryptography are expected to be deprecated after 2030 and disallowed after 2035, and the information an organisation sends today may still need to be confidential long after both dates.

This article is a practical guide for leaders and security teams: what the deadlines are, where to start, why hybrid deployment is the sensible default, and how to build the crypto-agility that makes the next transition easier. It closes with how VOIDEX approached the same problem for private communication, where the migration could be done in one step.

Why the clock started early

A cryptographically relevant quantum computer does not exist today. So why act now? Two reasons.

Recorded data is already exposed. Adversaries can record encrypted traffic today and decrypt it later, once a capable machine exists. If your data must stay confidential for ten years and the machine arrives in eight, the damage is already done. This is the harvest now, decrypt later problem.

Migrations take years. Large organisations have cryptography in places nobody has looked at in a decade: embedded devices, vendor appliances, internal certificate authorities, archived backups, partner integrations. Previous transitions, such as retiring SHA-1, took many years even with far less at stake.

And the estimates keep falling. In May 2025, Craig Gidney of Google Quantum AI estimated that RSA-2048 could be factored with fewer than one million noisy qubits, down from about 20 million in 2019. In early 2026, further work reduced the estimates for both RSA and the elliptic curves used across the internet, summarised by The Quantum Insider.

The deadlines that matter

Three reference points shape most roadmaps.

• The standards exist. On 13 August 2024, NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). ML-KEM replaces key exchange; ML-DSA and SLH-DSA replace signatures. In March 2025 NIST also selected HQC as a backup key encapsulation mechanism based on different mathematics, with a final standard expected around 2027.
• The retirement plan. NIST's draft transition report, IR 8547, published in November 2024, proposes that quantum-vulnerable RSA and elliptic-curve algorithms be deprecated after 2030 and disallowed after 2035.
• The national security benchmark. The NSA's CNSA 2.0 guidance expects new US national security systems to be quantum-safe by January 2027. Even organisations outside that scope use it as a signal of where suppliers and regulators are heading.

We keep a closer eye on these dates in The PQC deadlines: 2030 and 2035.

Step 1: build a cryptographic inventory

You cannot migrate what you cannot see. The first deliverable is an inventory of where public-key cryptography is used and what it protects. For each system, record:

• Algorithms and key sizes in use for key exchange, signatures and certificates.
• Protocols carrying them: TLS, SSH, VPNs, S/MIME, code signing, document signing, messaging.
• Who controls the change: your own code, a library you can update, or a vendor you must wait for.
• The lifetime of the data each system protects.

Include the less visible places: hardware security modules, smart cards, IoT and building systems, firmware update chains, backup encryption, and third-party SaaS. Many teams find that automated discovery of TLS endpoints and certificates covers the easy half, and interviews with system owners cover the rest.

Step 2: prioritise by lifetime and exposure

Not everything moves at once. A useful ordering combines two questions: how long must this data stay secret, and how easily can an adversary record it?

1. Long-lived secrets on networks you do not control. Executive, legal and board communication, merger talks, health data, intellectual property, government and defence work. These are the prime targets for harvesting.
2. Signing roots with long validity. Root certificates, firmware signing keys and code signing keys often live for many years. Forged signatures would let an attacker impersonate you, so these need a planned path to ML-DSA or SLH-DSA well before 2035.
3. Short-lived sessions protecting low-value data. These can follow the natural upgrade cycle of vendors and libraries.

The Canadian cryptographer Michele Mosca's rule of thumb captures the logic: if the time your data must stay secret plus the time your migration takes exceeds the time until a quantum computer arrives, you are already late.

Step 3: deploy hybrid first

For key exchange, the consensus approach during the transition is hybrid: combine a classical algorithm such as X25519 with a post-quantum one such as ML-KEM, so the resulting key depends on both. An attacker must then break both.

Hybrid deployment is sensible for three reasons:

• Protection against quantum attack, from the post-quantum half.
• Protection against a surprise weakness in a young algorithm, from the classical half, which has decades of analysis behind it.
• Compliance continuity, because systems still use a well-understood classical component while standards and certifications mature.

Much of this is arriving through ordinary updates. Major browsers and content delivery networks now support hybrid key exchange for TLS, and messaging platforms such as Signal and Apple's iMessage have added post-quantum layers. We explain the design in depth in Why hybrid post-quantum encryption wins.

Step 4: engineer for crypto-agility

The deepest lesson of this migration is that it should be the last painful one. Crypto-agility means being able to change algorithms without rewriting systems. In practice:

• Centralise cryptography in a small number of well-maintained libraries and services instead of scattered hand-written calls.
• Negotiate, do not hard-code. Protocols should carry algorithm identifiers and support more than one option.
• Plan for bigger keys and signatures. ML-KEM ciphertexts and ML-DSA signatures are considerably larger than their elliptic-curve predecessors. Check message size limits, database columns, packet sizes and certificate chains.
• Test rollback and dual running. Old and new algorithms will coexist for years.
• Make it contractual. Ask vendors for their post-quantum roadmap and dates, and write them into procurement.

Step 5: do not forget the people channel

Security programmes tend to focus on servers, certificates and data at rest. Yet some of the most sensitive information in any organisation moves through everyday conversation: a message to the chief financial officer, a board discussion, a call with outside counsel. If that traffic runs over tools that rely on classical key exchange alone, it is exactly what a harvesting adversary wants.

This is also the easiest part to fix, because the migration can be a choice of tool rather than a multi-year engineering programme.

How VOIDEX did the migration in one step

VOIDEX did not have legacy cryptography to retire. It was designed from the start around the endpoint of the roadmap above.

• Hybrid key agreement. Every direct conversation in VOIDEX Messenger opens with a PQXDH-style handshake that combines X25519 with ML-KEM-768.
• A key per message. A double ratchet with post-quantum re-keying provides forward secrecy and post-compromise security.
• Post-quantum identity. Device identities are signed with hybrid Ed25519 plus ML-DSA-65.
• Standards for groups. Groups and private VOIDEX Channels use MLS, RFC 9420.
• Verifiable keys. Every device key change is appended to a public, append-only Merkle log whose tree heads carry Ed25519 plus ML-DSA-65 signatures; clients refuse keys that are not in it, and an independent witness watches it.
• Keys stay with members. Keys are created on members' devices, and VOIDEX servers store only public keys and ciphertext.

The cryptographic core is open source and the full design is published in the VOIDEX security report, because a migration plan should be something your security team can verify, not merely believe. VOIDEX is free, carries no ads and no third-party trackers, and does not sell data.

One trade-off is stated openly: each member's recovery code can open an encrypted history copy on a new device, and that copy is deliberately not forward-secret. VOIDEX never holds the code, and members can switch the copy off.

A one-page summary for the board

• The standards are final (FIPS 203, 204, 205) and the retirement dates are proposed: 2030 deprecation, 2035 disallowed.
• Data recorded today can be decrypted later, so long-lived secrets are already at risk.
• Start with an inventory, prioritise by data lifetime, deploy hybrid key exchange, then migrate signatures.
• Build crypto-agility so this is the last forced migration.
• Move sensitive human communication to post-quantum tools now, because that step is fast.

VOIDEX is invite-only. Request access for your team, or share the VOIDEX security report with your security lead.

Sources

• NIST Post-Quantum Cryptography Standardization (FIPS 203, 204, 205; HQC selection): https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization
• NIST IR 8547 (initial public draft, November 2024): https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
• NSA, "Announcing the Commercial National Security Algorithm Suite 2.0" (2022): https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
• Gidney, C. "How to factor 2048 bit RSA integers with less than a million noisy qubits" (2025): https://arxiv.org/abs/2505.15917
• The Quantum Insider, "Q-Day just got closer" (31 March 2026): https://thequantuminsider.com/2026/03/31/q-day-just-got-closer-three-papers-in-three-months-are-rewriting-the-quantum-threat-timeline/
• Mosca, M. "Cybersecurity in an era with quantum computers: will we be ready?" (2015): https://eprint.iacr.org/2015/1075
• RFC 9420, The Messaging Layer Security Protocol: https://www.rfc-editor.org/rfc/rfc9420