A Post-Quantum Migration Roadmap: Moving Your Business Off Vulnerable Crypto

A post-quantum migration is the process of moving your systems from today’s cryptographic algorithms, which a sufficiently powerful quantum computer could eventually break, to post-quantum algorithms designed to resist quantum attacks. The destination now exists: NIST finalized its post-quantum standards, FIPS 203 for key encapsulation and FIPS 204 and 205 for digital signatures, in 2024, giving organizations concrete, approved algorithms to adopt. The migration matters even though large-scale quantum computers are not here yet, because of harvest-now-decrypt-later: an adversary can capture your encrypted data today and decrypt it later once the capability exists, so any data with a long secrecy lifetime is exposed the moment it is transmitted with vulnerable cryptography. A migration is not a single switch-flip; it is a staged program of discovering where you use cryptography, prioritizing by risk, deploying post-quantum algorithms alongside classical ones during a transition, cutting over, and building the agility to change algorithms again in future without another painful migration. The federal government has put a clock on it, with Executive Order 14412 setting deadlines that in turn set the pace for the broader ecosystem.

The concrete deadlines that exist today are federal, set by Executive Order 14412, which directs federal agencies to transition their most sensitive systems to post-quantum encryption by the end of 2030 and to post-quantum authentication by the end of 2031, and expects federal contractors to meet post-quantum standards on a similar timeline. If you sell to the government or are in that supply chain, those dates are your compliance dates. If you are not, there is no single law forcing a date on your business yet, but the federal timeline effectively sets the industry pace, because your vendors, platforms, and partners are all working toward it, and standards bodies and major providers are aligning to the same window. More important than any external deadline is your own harvest-now-decrypt-later exposure: if you transmit or store data that must stay secret for years, that data is already at risk today, so your practical deadline for protecting it is much sooner than 2030. The honest answer is that the finish line for full migration is late this decade, but the start line, taking inventory and protecting your longest-lived secrets, is now.

A cryptographic bill of materials, or CBOM, is a documented inventory of every place your systems use cryptography: which algorithms are in use, in which applications, protocols, and products, and what data each one protects. It is the post-quantum equivalent of knowing what is in your software supply chain, and it is the essential first step of any migration, because you cannot migrate cryptography you have not located. Building one is more involved than it sounds, because cryptography is embedded far more widely than most teams realize, not just in your website’s HTTPS, but in APIs, VPNs, databases and backups, code-signing and software updates, authentication and tokens, payment flows, and inside the third-party libraries and products you depend on, much of it invisible until you deliberately look. A good CBOM does more than list algorithms; it ties each use to the sensitivity and secrecy lifetime of the data it protects, which is exactly the information you need to prioritize the migration. NIST’s migration guidance treats this discovery as the foundation of the whole effort, because every later decision, what to migrate first, where hybrid is needed, how to sequence the work, depends on having an accurate picture of what you have.

Hybrid post-quantum cryptography means using a classical algorithm and a post-quantum algorithm together for the same protection, so that an attacker would have to break both to compromise it. You use it during the transition because it removes a single point of failure at a moment when the newer algorithms have less real-world attack history. If an unexpected weakness were found in one of the post-quantum algorithms, the classical algorithm still protects you against today’s adversaries; and if the classical algorithm is the one a future quantum computer breaks, the post-quantum algorithm holds. It is a deliberate belt-and-suspenders approach for a period when caution is warranted. Hybrid also makes the migration safer and more reversible in practice: by running both algorithms in production, you can confirm that your systems and your partners’ systems actually interoperate with post-quantum cryptography before you rely on it alone, and you can fall back if something breaks. Only once hybrid has proven stable in the field do you complete the cutover to post-quantum and retire the classical algorithm. This is why serious migration guidance frames hybrid as the standard transitional posture rather than jumping straight to post-quantum-only, which trades a manageable transition for avoidable risk.

No, and it is important to be precise about this, because the honest term is quantum-safe, not quantum-proof. Post-quantum algorithms are designed and standardized to resist attacks by quantum computers as we understand them, which is a meaningful and necessary protection, but no cryptographic algorithm is proven unbreakable forever. Cryptography advances, analysis improves, and an algorithm considered strong today can be weakened by future mathematical breakthroughs, which is exactly what is happening to the classical algorithms we are now migrating away from. Calling post-quantum cryptography quantum-proof overpromises a permanence that no algorithm can guarantee. The accurate claim is that a properly migrated system is quantum-safe: resistant to known quantum attacks. This is not a technicality; it directly shapes how you should build. Because no algorithm choice is permanent, the migration should leave you crypto-agile, able to swap algorithms without re-engineering, so that if a post-quantum algorithm ever needs to be replaced, it is a routine change rather than another full migration. Agility, not a promise of permanence, is what actually protects you over the long run, which is why we treat quantum-safe-with-agility as the real goal.

Start small and in the right order, because the roadmap is designed to be done incrementally rather than all at once. The single most valuable first step, and one that does not require replacing any cryptography yet, is inventory: build a cryptographic bill of materials so you can see where your systems use cryptography and what data each use protects. Even a partial inventory of your most important systems tells you where your risk concentrates. From there, prioritize by asking one question of each item: if this data were captured today, would it still matter when a quantum computer can decrypt it? That focuses your limited resources on the long-lived, sensitive data most exposed to harvest-now-decrypt-later, rather than trying to migrate everything at once. Much of the actual algorithm change will also come to you through vendors and platform updates, so tracking your key providers’ post-quantum timelines lets you inherit progress rather than build it all yourself. The mistake to avoid is waiting for a big, funded program before doing anything; the inventory and prioritization stages are low-cost, high-value, and they turn an overwhelming problem into a sequenced plan you can execute as resources allow.