Migrate off RSA
before it breaks.Post-quantum migration — deadlines, the Mosca test, CBOM, and crypto-agility.
Post-quantum migration is moving off RSA and elliptic-curve cryptography onto NIST's post-quantum standards before a quantum computer can break them. Because migrations take years and "harvest now, decrypt later" is already happening, the deadline to start is now. RankShield is post-quantum today — so you can see what migrated looks like.
The theft is
already happening.
Adversaries copy encrypted data today and store it until a quantum computer can open it. Anything that must stay secret for years is already exposed — even though the machine that breaks it doesn't exist yet. You don't need a date to be at risk; you need data that outlives one.
Secrecy + migration
vs. time to quantum.
The Mosca inequality: if your data's required secrecy plus your migration time exceeds the years to quantum, you're exposed today. Migrations take years — so the math almost always says start now. Model your own numbers just below.
2030. 2031.
2035.
The 2026 US executive order sets federal post-quantum deadlines — key establishment by 2030, signatures by 2031 — and calls for a Cryptographic Bill of Materials. NIST's draft timeline would disallow RSA/ECC after 2035. The direction is set; the runway is short.
Migrate once.
Then rotate freely.
PQC is young and standards will evolve, so the goal isn't a one-time swap — it's crypto-agility: algorithms in a swappable registry, composite signatures, central rotation. Migrate to agility, and the next change is a config, not a crisis.
Post-quantum,
and provable.
RankShield already runs the migrated world: composite ML-DSA-65 signatures, ML-KEM hybrid TLS, a crypto-agile registry, and quantum entropy — quantum-safe, never quantum-proof, and never weaker than classical. Ahead of the deadlines, not chasing them.
What is post-quantum migration?
Post-quantum migration is moving an organization's cryptography off algorithms a quantum computer could break — mainly RSA and elliptic-curve — onto NIST-standardized post-quantum algorithms, before a cryptographically-relevant quantum computer exists. Almost every secure system today relies on public-key cryptography that a sufficiently powerful quantum computer could defeat, and while no such machine exists yet, two facts make waiting dangerous. First, migrations are enormous: cryptography is embedded in protocols, products, certificates, and hardware across an entire organization, and replacing it safely takes years. Second, the threat is already active through "harvest now, decrypt later" — adversaries collecting encrypted data today to open once quantum computing matures. Together these mean the responsible move is to migrate ahead of the threat, not in response to it. The migration itself has a few pillars: discovering where vulnerable cryptography lives (a Cryptographic Bill of Materials), replacing it with post-quantum algorithms like ML-KEM and ML-DSA deployed in a hybrid way, and — most importantly — becoming crypto-agile so future changes are routine. RankShield is built as the destination: it is post-quantum today, signing with composite ML-DSA-65 and using ML-KEM via hybrid TLS in a crypto-agile registry, so it shows what a migrated posture looks like — quantum-safe, honestly described, and never weaker than classical.
Are you already exposed? Run the Mosca test.
The decision to migrate isn't about predicting Q-Day — it's a simple inequality. If the years your data must stay secret plus the years your migration takes reach the years until quantum, an adversary can harvest today and decrypt later, and you are exposed now. Drag the sliders to model your own exposure.
The Mosca exposure test
Secrecy (X) + migration (Y) vs. years to quantum (Z). If X + Y ≥ Z, you're exposed today.
Exposed today
What are the post-quantum migration deadlines — and what is a CBOM?
The policy timeline is concrete, and it starts with knowing what cryptography you actually run. On the deadline side, the direction is unambiguous: the 2026 U.S. executive order (EO 14412) directs federal agencies to move high-value assets to post-quantum key establishment by December 31, 2030 and signatures by December 31, 2031, and to define a Cryptographic Bill of Materials; NIST's draft transition timeline (IR 8547) would deprecate RSA and elliptic-curve cryptography after 2030 and disallow them after 2035 — still a draft direction rather than final policy; and the EU's coordinated roadmap targets national first steps by the end of 2026 and broad transition by 2035. Whether or not you're a federal agency, these dates set the market's expectations and the pace vendors and auditors will assume. The harder, less-discussed part is where migration actually begins: discovery. You cannot migrate cryptography you can't see, and in most organizations RSA and ECC are embedded in countless places — protocols, libraries, certificates, firmware, third-party products — with no single inventory of them. That's what a Cryptographic Bill of Materials solves: a living inventory of which algorithms are used, where, and in what form, analogous to a software bill of materials. New policy expects organizations to produce one, and it's only practical if your cryptography is agile enough to be inventoried and rotated in the first place. This is why crypto-agility isn't a nice-to-have but the foundation of the whole effort: RankShield keeps its algorithms in a swappable registry specifically so the crypto is visible, inventoried, and changeable — turning both the CBOM requirement and the migration deadlines from a scramble into a managed process.
What does a post-quantum migration actually involve?
Four phases, and the first is the one most organizations underestimate. Post-quantum migration sounds like "swap the algorithms," but in a real environment it's a program, and skipping the groundwork is how migrations stall. The first phase is discovery: building a Cryptographic Bill of Materials by finding everywhere RSA and elliptic-curve cryptography live — in protocols, libraries, certificates, tokens, firmware, and third-party products — because you cannot migrate what you cannot see, and cryptography is embedded in far more places than any team remembers. The second phase is prioritization: ranking those uses by risk, using the Mosca inequality as the guide, so that data with long secrecy requirements and systems facing "harvest now, decrypt later" get migrated first. The third phase is the migration itself, done the responsible way — deploying NIST post-quantum algorithms like ML-KEM and ML-DSA in hybrid mode, paired with the existing classical algorithms, so you gain quantum resistance without ever being weaker than you are today if a new post-quantum algorithm needs revisiting. The fourth and most important phase is becoming crypto-agile: putting algorithms behind a registry and an allowlist so future changes are configuration, not re-architecture, because PQC standards will keep evolving and a second forced migration would be as painful as the first. RankShield is built to be the end state of this journey — post-quantum, hybrid, and crypto-agile by design — so rather than architecting all four phases from scratch, the security fabric your agents and data run on is already migrated, and the agility to absorb the next standards change is built in. Migration becomes something you manage, not something that manages you.
How ready are you for post-quantum?
Five quick questions on your cryptography today — no email required, just an honest read on where you stand against the 2030/2031 clock.
Ask RankShield about post-quantum migration.
What is post-quantum migration?
Post-quantum migration is the process of moving an organization’s cryptography off algorithms a quantum computer could break — mainly RSA and elliptic-curve — onto NIST-standardized post-quantum algorithms like ML-KEM and ML-DSA, before a cryptographically-relevant quantum computer exists. Because migrations are large and slow, and because data stolen today can be decrypted later, the work has to start well ahead of any actual quantum threat. RankShield is already post-quantum: it signs with composite ML-DSA-65 and uses ML-KEM via hybrid TLS, in a crypto-agile registry, so it is built for the migrated world now.
Why migrate before quantum computers exist?
Because of "harvest now, decrypt later." Adversaries can copy encrypted data today and store it until a quantum computer can break the encryption — so anything that must stay secret for years is already at risk, even though the machine that opens it does not yet exist. There is no confirmed date for that machine, and honest estimates are probabilistic. The decision rule is the Mosca inequality: if your data’s required secrecy plus your migration time exceeds the time to quantum, you are already exposed. Since migrations take years, that math says start now.
What are the post-quantum migration deadlines?
The policy clock is concrete. The 2026 U.S. executive order (EO 14412) directs federal agencies to move high-value assets to post-quantum key establishment by December 31, 2030 and signatures by December 31, 2031, and to define a Cryptographic Bill of Materials (CBOM). NIST’s draft transition timeline (IR 8547) would deprecate RSA/ECC after 2030 and disallow them after 2035 — still a draft direction, not final policy. The EU’s coordinated roadmap targets national first steps by end-2026 and broad transition by 2035.
What is a Cryptographic Bill of Materials (CBOM)?
A CBOM is a living inventory of the cryptography your systems use — which algorithms, where, and in what form — analogous to a software bill of materials. It matters because you cannot migrate what you cannot see: the first hard step in post-quantum migration is discovering all the places RSA and ECC are embedded. New policy, including the 2026 executive order, expects organizations to produce a CBOM, and it is only practical if your crypto is agile enough to inventory and rotate. RankShield keeps algorithms in a swappable registry precisely so the crypto is visible and changeable.
What is crypto-agility, and why does it matter for migration?
Crypto-agility is the ability to change cryptographic algorithms quickly, without re-architecting your systems. It matters because post-quantum cryptography is young — standards will keep evolving, and an algorithm considered safe today may need replacing tomorrow. Organizations that hard-coded RSA decades ago know how painful a forced migration is. RankShield is crypto-agile by design: algorithms live in a registry with an allowlist, and signatures are composite (a classical and a post-quantum algorithm together), so crypto can be rotated centrally. Agility is what makes migration a manageable, repeatable process rather than a one-time crisis.
Is RankShield post-quantum today?
Yes, and honestly described. Every RankShield signature, key exchange, and connection is post-quantum now: composite ML-DSA-65 with Ed25519 for signatures, ML-KEM via hybrid post-quantum TLS for key exchange, a crypto-agile registry, and a quantum entropy source. It is quantum-safe, not quantum-proof — standards-based protection deployed in a hybrid way so you are never weaker than classical, ahead of the 2030/2031 deadlines rather than racing them. A cryptographically-relevant quantum computer does not yet exist; the point is to be ready before it does.
Become crypto-agile before the deadline.
Post-quantum, hybrid, and crypto-agile — the migrated posture, today. See how RankShield's quantum-safe fabric works.