Preparing
Where migration actually starts
Why migration takes years, and a concrete sequence for starting one anyway.
8 min read · 8 min 44 sec film
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.
Lesson film
Watch: Where migration actually starts
Three variables, one of which you actually control — and the ordered sequence that follows from that fact.
8 min 44 sec · 10 scenes
8 min 44 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
Everything up to here has been understanding. This lesson is about what you do on Monday.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. The last lesson
2. Mosca's inequality
3. The term you control
4. Why it takes years
5. The regulatory floor
6. The sequence
7. One inventory finding
8. Ranking three findings
9. Keep the budgets apart
10. Takeaway
The written lesson
Mosca's inequality frames a planning question: if X (how long information must stay confidential) plus Y (how long migration takes) exceeds a hypothetical Z (time to a capable quantum computer), information exposed during the migration may still be sensitive when that capability arrives. It does not prove that a specific record captured today remains sensitive until Z. Nobody knows Z with confidence; teams can estimate and shorten parts of Y.
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 candidate flows using remaining secrecy, plausible capture path, protection mechanism, impact, evidence confidence, migration lead time, and dependencies. An internet-facing long-lived flow is a plausible early candidate, but an internal dependency may be the first engineering task. Document assumptions and keep expanding the inventory; do not require estate-wide completeness before a scoped pilot.
- 03
Track existing classical weaknesses
MD5, SHA-1, RC4, DES, and 3DES have important classical weaknesses or deprecation limits whose impact depends on use. Record their specific use and policy status. Classical remediation and PQC migration need distinct rationales, but they can share library upgrades, owners, and rollout windows.
- 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.
Discovery and migration can proceed in scoped iterations. Establish a sufficiently reliable inventory for one high-priority flow, map its upstream and downstream dependencies, pilot the replacement, verify negotiated behavior, then expand coverage. An organization-wide inventory is an ongoing control, not a prerequisite for every first pilot.
Work it through
Sequence a first migration tranche
An internet service has a classical TLS origin hop; its load balancer supports a published hybrid group, while one legacy client is untested. A separate internal batch job uses a classical signature for software updates.
About 8 min of unscored practice
Your task
- Select the first scope and state why.
- Name evidence needed before enabling the group.
- Name a compatibility test and a rollback trigger.
Type here or copy the template. Your response stays in this page and is not submitted or scored.
Reveal model response and self-check rubric
A different answer can be sound when it states its assumptions and follows the evidence.
Start with a sampled origin-hop pilot because long-lived traffic may be recorded there and the infrastructure has a supported hybrid option. Capture actual negotiated groups for relevant clients, test the legacy client, and record the share of traffic using hybrid exchange. Roll back or isolate the legacy path if connections fail or the agreed service threshold is breached. Track software-signature migration separately with its device-update dependencies.
Self-check
For each point: 0 = absent or incorrect, 1 = partly supported, 2 = well supported.
- Explain the selected scope using exposure and feasibility.
- Identify missing evidence and affected peers.
- Include validation and a concrete rollback condition.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
- IR 8547: Transition to Post-Quantum Cryptography StandardsNIST · Initial public draft; proposed dates are not final rules · Transition tables and introduction · checked 2026-09-26
- Commercial National Security Algorithm Suite 2.0 FAQNSA · Published guidance for National Security Systems and applicable vendors; December 2024 update · checked 2026-09-26
- Cybersecurity in an Era with Quantum Computers: Will We Be Ready?Michele Mosca · Research paper · checked 2026-09-26
- CSWP 39-upd1: Considerations for Achieving Crypto AgilityNIST · Updated guidance; supersedes CSWP 39 · checked 2026-09-26
Marking a lesson complete only updates this browser.