Preparing
Where migration actually starts
Why migration takes years, and a concrete sequence for starting one anyway.
7 min read
What you'll be able to do
- Explain, using Mosca's inequality, why migration time is a variable an organization actually controls.
- List the categories of constraint — inventory, dependencies, protocol limits, third parties — that make migration slow.
- Describe a concrete, ordered starting sequence for a migration program.
Mosca's inequality frames the urgency: if X (how long data must stay confidential) plus Y (how long migration takes) exceeds Z (the time until a capable quantum computer exists), data harvested today will still be sensitive when a capable machine eventually decrypts it. Nobody knows Z with confidence, and this course will not pretend otherwise. But Y is the term an organization actually controls, and for most organizations Y is measured in years, not months.
Migration takes years for reasons that have little to do with the cryptography itself.
| Constraint | Why it slows migration |
|---|---|
| Inventory | Cryptography cannot be migrated if it is not known to exist — it hides in libraries, vendored dependencies, hardware, and legacy protocols that predate anyone currently on the team. |
| Dependencies | A library, SDK, or hardware security module has to support the new algorithm before application code can use it, and some of that upgrade work is outside the team's control. |
| Protocol and size constraints | Larger post-quantum keys and signatures can exceed message-size limits in older protocols, embedded buffers, or certificate-chain limits, forcing protocol-level changes rather than a simple library swap. |
| Third parties | Partners, vendors, and customers integrating with a system have to move too — a migration that only one side completes is still exposed at every interface it does not control. |
- 01
Inventory before migrating anything
Find every place cryptography is used — in code, in dependencies, in certificates, and in hardware — before committing to a sequence. A tool that discovers and inventories cryptography across code and dependencies (sometimes called a cryptographic bill of materials, or CBOM) shortens this step considerably; RelixQ is one example built specifically for it.
- 02
Prioritize by exposure, not by convenience
Rank findings by how reachable and long-lived the exposure is. An internet-facing service protecting data with a decade-long confidentiality requirement outranks an internal batch job, regardless of which is easier to touch first. Modeling harvest-now-decrypt-later exposure using data lifetime, harvestability, reachability, and evidence confidence — the approach behind QAST in RelixQ — turns that ranking into something more rigorous than intuition.
- 03
Fix what is classically broken first
MD5, SHA-1, RC4, DES, and 3DES are broken today, with no quantum computer required. Clearing those out is real security work, but keep it out of the post-quantum migration budget and timeline — conflating the two inflates the PQC estimate.
- 04
Pilot hybrid key exchange where it's already supported
Where a TLS stack, load balancer, or CDN already offers
X25519MLKEM768or a similar hybrid mechanism, enabling it addresses harvest-now-decrypt-later for that traffic today, at limited engineering cost. - 05
Build agility into the plan itself
Track ownership and deadlines the way any other multi-year program would be tracked, and revisit exceptions on a schedule rather than granting them once and forgetting them.
None of these steps require a finished FN-DSA standard, or a resolved timeline for a capable quantum computer. They require an accurate inventory, an honest priority order, and a schedule that treats Y — migration time — as the thing actually being managed.
Marking a lesson complete only updates this browser.