up:: 00 Field Guide Map
Start a Migration
Starting a post-quantum migration means turning an enormous, jargon-heavy mandate into a short, ordered set of concrete moves you can begin at your desk this week: find where your cryptography actually lives, rank it by real risk, and hand up a one-page plan. The goal this quarter is a first defensible plan, which is a few weeks of work, rather than a finished migration, which takes years.
This page is written for the person who got handed the task and froze in front of it. You’re the practitioner, the architect, or the team lead, and somebody upstream said “we need to be quantum-safe” and walked away. Read it top to bottom for the order of operations, or jump to the move you’re stuck on. Every term links to its own deep note, so you can go as far down as you want and come back up. Everything here is yours to use.
The short version:
- It’s a multi-year program, and your first defensible plan is a few weeks of work. You’re producing a prioritized shortlist, not finishing the migration this quarter.
- Do discovery before you spend a dollar. Build a scoped inventory of your crown-jewel systems first, then rank it, then talk to vendors, then buy anything.
- Rank by two lenses: harvesting exposure (long-lived confidential data an adversary can grab today) and blast radius (how far a failure spreads). Sequence key establishment ahead of signatures, because the harvesting clock is already running.
- What you’re moving to is short: ML-KEM for key exchange, ML-DSA for signatures, hybrid during the transition. You don’t have to become a cryptographer.
- Nobody has finished this yet, so you’re not behind. You’re early, and early is the good place to be.
Think of it like re-keying every lock in a very large building. You don’t start by ordering locks. You start with the master list: which doors exist, what lock each one has, who installed it, which rooms it guards. Get that list for your crypto, rank the doors by which ones matter, and the rest of the work sequences itself.
The 60-second brief
If you read one section, read this. It’s the whole starter arc:
- The threat. A large enough quantum computer breaks the public-key cryptography behind your certificates, connections, and signatures (RSA, ECDH, ECDSA). Symmetric encryption like AES-256 survives. If you need the case that this is real, Why This Exists settles it in five minutes.
- The clock. You don’t get until the machine exists. Adversaries harvest encrypted data now to read it later, so any secret with a long shelf life is exposed today. Mosca’s theorem turns that into your own deadline.
- Your first job is discovery. Build a cryptographic inventory of your crown-jewel systems. Most teams find their real exposure only after they look, because the vulnerable algorithm hides inside vendor products and systems nobody mapped.
- Then prioritize. Rank the inventory by harvesting exposure and blast radius so a ranked queue falls out instead of an overwhelming pile.
- The deliverable. A one-page prioritized plan for your CISO: what’s most at risk, what to fix first, and one small reversible first move. That’s Phase 1, and it’s a few weeks of work.
What’s the whole path, in order?
Here’s the guide sequenced into the order you’d actually do the work. Each step routes to the section of the Field Guide that carries the depth, and hands you the first move.
- Know what’s at risk, and get your own deadline. Route to The Threat. Start with Mosca’s theorem: it turns the abstract industry timeline into a calculation for your data, how long it must stay secret plus how long you’ll take to migrate, versus how long until quantum breaks it. Harvest Now, Decrypt Later is why some of it is urgent today.
- Pin the deadline that binds you. Route to The Mandates. Find the regulation or contract requirement that names your sector, because that date sizes the whole program and it’s what a budget conversation runs on.
- Find your cryptography. Route to Migration Architecture. Name an owner and your stakeholders, then build a CBOM scoped to your crown-jewel systems. This is your first real action, and the section below walks it in depth.
- Decide what to fix first. Route to Quantum Risk Models, the prioritization engine. It sorts your inventory by risk type and by how far each failure spreads, so a ranked queue falls out.
- Learn what you’re moving to. Route to The New Standards: ML-KEM replaces key exchange, ML-DSA replaces signatures. Just enough to know the replacements and what each is for.
- Make it swappable, and bridge safely. Back to Migration Architecture, this time for crypto-agility and hybrid cryptography. This is how you move without breaking a live system.
- Bring your people along. Route to The Human and Organizational Side. Migrations stall on people and ownership long before they stall on the math, and you’ll get the three small, completely reversible moves that acclimate a team.
The single most common mistake is starting at step 5, picking algorithms, before steps 1 through 4 exist. A team can choose ML-KEM and design a beautiful rollout in a week, then watch it go nowhere, because nobody owned it and nobody knew where the cryptography actually lived.
What do I do first, today?
Two moves, both small enough to start this afternoon. Name an owner (or get yourself named, in writing), and identify the single regulation or contract clause that binds your sector. Ambiguous ownership is the most common reason a program never starts, and the binding date is what every later conversation runs on.
After that, work the first 90 days as a sequence. Each row produces an artifact the next row needs, so you’re always holding something concrete.
| When | What you actually do | What you walk out with |
|---|---|---|
| Days 1 to 10 | Get named as owner or name one; find the one mandate that binds you; write down each crown-jewel system’s data secrecy lifetime | An ownership line and your binding deadline |
| Days 10 to 25 | Pick 3 to 5 crown-jewel systems; pull their certificate inventories and configuration files; open the CBOM on just those | A scoped inventory target and first findings |
| Days 25 to 45 | Finish the crown-jewel CBOM; grade every finding by evidence; send vendor questionnaires on the surfaces you don’t control | A graded cryptographic inventory |
| Days 45 to 65 | Rank the inventory by harvesting exposure and blast radius; sequence key establishment ahead of signatures | A risk-ranked migration queue |
| Days 65 to 90 | Draft the target-state note (ML-KEM, ML-DSA, hybrid); write the one-page plan; propose one reversible pilot | The Phase 1 deliverable, ready to hand up |
By day 90 you hold a named owner, the binding deadline, a crown-jewel inventory, a risk-ranked queue, and a one-page plan with a first move on it. That’s a defensible position, built in a quarter, and it’s what funds the rest.
How do I find all my cryptography?
You build a Cryptographic Bill of Materials, a structured record of every algorithm, key, certificate, and protocol configuration, plus the data class each one protects and the control boundary it sits behind. Scope it to your crown-jewel systems first. A full-estate inventory is how a first pass stalls before it ships, and the crown jewels are where the answer matters most anyway.
Where cryptography hides. The vulnerable algorithm rarely announces itself. Look in all of these, roughly in the order teams tend to miss them:
- Application code and dependencies. Hardcoded library calls, pinned parameters, key-management patterns that never show up in a live handshake.
- Server and service configuration. What each service permits, which is often broader and older than what it happens to negotiate when you probe it.
- TLS termination points. Load balancers, reverse proxies, CDNs, and API gateways terminate TLS and hold the real cipher policy. A single un-inventoried terminator is a hole.
- Vendor and SaaS products. Cryptography inside a product you don’t control. Invisible to internal scans, and usually the majority of your footprint by surface count.
- Firmware and embedded or OT devices. Often hardcoded, often on long replacement cycles, often the hardest to change later.
- Key stores and HSMs. The keys themselves, their algorithms, and which systems reach them.
- Certificates and the CA hierarchy. Every leaf, intermediate, and root, and critically the signing keys of your certificate authorities.
- CI/CD and code or artifact signing. Build pipelines, package signing, container image signing, release signing keys.
- VPN and network gear. IPsec tunnels and remote-access VPNs, much of it vendor firmware with legacy key-exchange groups lingering for years.
- Identity infrastructure. SAML, JWT, and SSO token-signing keys, frequently owned by a different team than PKI and therefore left out of the first inventory.
How to find it. Four discovery methods, always combined, because no single one sees the whole estate:
- Configuration extraction (your primary layer). Parse the actual config files of each termination point, normalize into one schema, and classify every cipher suite by its constituent algorithms. This captures what a server permits, which scanning misses.
- Active scanning (a cross-check, not the source of truth). Network scans, TLS handshake inspection, certificate enumeration, and SSH key scanning against live endpoints. Tools like sslyze and testssl.sh see what a server negotiates when probed.
- Static and dependency analysis. Code and binary analysis plus dependency manifests, to surface library calls and hardcoded parameters that never appear on the wire.
- Vendor inquiry. Structured questionnaires for the surfaces you don’t control. The answers are documented evidence, weaker than a verified capture, and essential anyway.
Why configuration beats a scan alone: a 2026 corpus study of real-world TLS found that 21.8% of contexts permitted TLS 1.0 or 1.1 as configured even while negotiating newer versions in practice, and 53.3% carried leaf-only certificate references that pass permissive clients but fail strict ones. A scan sees the negotiated version and misses the permitted one.
Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).
What to record per finding. Make every entry granular enough to prioritize. Not “we use RSA,” but the full context:
| Field | What you record | Why it earns its place |
|---|---|---|
| Algorithm and parameters | RSA-2048, ECDSA P-256, AES-256, at parameter-set granularity | Tells you what’s vulnerable and what survives |
| Purpose | Key establishment, signature, encryption, integrity, or hashing | Key establishment carries the live harvesting clock |
| System and layer | The app or device, and where in the stack: transport, application, firmware, at-rest, or PKI | Locates the work and its owner |
| Control boundary | Customer-managed, vendor-configurable, vendor-opaque, or hardcoded | Whether you or a vendor sets the timeline |
| Data class | The sensitivity and secrecy lifetime of what it protects | Drives HNDL exposure |
| Evidence grade | Verified (proven from an artifact) or documented (asserted only) | Documentation can be wrong; high-risk entries need proof |
| Provenance and last verified | The exact source file or capture, and the date confirmed | Makes the entry auditable and re-checkable |
The two fields teams most often skip are data class and control boundary. Without data class you can’t assess harvesting exposure. Without control boundary you can’t estimate the timeline, because vendor-controlled surfaces move on a schedule you don’t own.
Source: Balaji et al., arXiv:2605.17955 (2026); OMB M-23-02, which mandates a cryptographic inventory for U.S. federal agencies.
What do I migrate first?
Once you can see your cryptography, you rank by real risk instead of by system name. Two lenses do the sorting, and a ranked queue falls out of them.
- Harvesting exposure. Which findings carry long-lived confidential data over a vulnerable key-exchange path (RSA key transport, ECDH, legacy Diffie-Hellman). That data is under attack today because an adversary can record it now and read it later, so it moves up.
- Blast radius. How far the damage spreads if a finding’s cryptography fails. Rank it on how many systems depend on it, how much privilege it carries, how reachable it is, how far a failure cascades, and how hard recovery is. A root CA or an identity token-signing key outranks an isolated app regardless of which algorithm each runs.
The default sequencing rule is key establishment ahead of signatures, because key establishment is the half exposed to harvesting, and that clock is already running. The one thing that overrides it is a trust anchor whose blast radius is estate-wide: a root CA or a central identity provider tops the queue even though it’s a signature exposure, because its failure forges trust for everything beneath it.
A worked example. Take five findings out of a crown-jewel CBOM, score each lens High, Medium, or Low, and the queue writes itself:
| Finding | Harvesting exposure | Blast radius | Where it lands |
|---|---|---|---|
| Internal root CA signing key (RSA-2048) | Low (it signs, it doesn’t carry confidential data) | Very high (every certificate under it) | 1st, blast radius overrides |
| Customer API TLS (ECDHE, 10-year regulated records) | High (long-lived data, harvestable now) | High (public-facing, many users) | 2nd |
| SSO token-signing key (SAML, RSA-2048) | Low | High (every federated app trusts it) | 3rd |
| Site-to-site VPN (IPsec, legacy DH, financial data) | High | Medium | 4th |
| Internal wiki TLS (ECDHE, low-value content) | Low | Low | 5th (monitor, revisit) |
The reasoning reads cleanly upward: the root CA leads because its blast radius is catastrophic and estate-wide, then the harvestable long-lived confidentiality paths because their clock runs today, then the remaining trust and lower-consequence systems. A reachability trap catches teams here: the internal root CA is hard for an outsider to reach and still ranks first, so low reachability is not low blast radius.
Source: NIST IR 8547, §4.2 (an Initial Public Draft; treat its guidance as NIST’s stated direction).
What am I moving to?
Short answer, so you can hold it in your head. The full depth lives in The New Standards, and NIST finalized the first three standards on August 13, 2024.
| The job | Move to | Note |
|---|---|---|
| Establish keys and exchange secrets | ML-KEM (FIPS 203) | Replaces RSA and ECDH key exchange; closes the harvesting exposure. NIST default is ML-KEM-768; CNSA 2.0 requires ML-KEM-1024 |
| Sign, general purpose | ML-DSA (FIPS 204) | The default signature; replaces ECDSA and RSA signing |
| Sign long-lived roots of trust and firmware | SLH-DSA (FIPS 205) | Hash-based and conservative; larger, slower signatures, so reserve it for low-volume, high-assurance signing |
Sources: NIST FIPS 203, FIPS 204, FIPS 205, August 2024.
You don’t jump straight to these on a live system. During the transition, key exchange runs hybrid, a classical algorithm and ML-KEM together, so the connection stays safe as long as either half holds. And you build for crypto-agility on everything new, so the next algorithm change is a configuration update instead of a rebuild. There will always be a next one.
How do I avoid the traps?
These are the footguns that sink first-time migrators. Every one of them looks like progress and quietly leaves the real exposure open.
| The trap | Why it sinks migrators | Do this instead |
|---|---|---|
| Reissuing leaf certificates without migrating the CA key | The real exposure is the CA’s own signing key; new leaves under an old CA key change nothing | Migrate the issuing CA’s key first, then plan reissuance and trust-store distribution |
| Forgetting identity token-signing keys | SAML and JWT signing keys are high blast radius and usually owned by a different team than PKI, so they fall out of the inventory | Put identity token-signing explicitly in scope and name its owner on day one |
| Buying a vendor “PQC solution” before discovery | You can’t scope or trust a purchase before you know what cryptography you actually have | Finish crown-jewel discovery, then buy against known gaps |
| Boiling the ocean | A full-estate inventory stalls before it ever ships | Scope to crown-jewel systems, ship the inventory, then widen |
| Leaving one un-migrated load balancer or gateway | A protocol is only as safe as its weakest endpoint on the path, so one classical terminator reopens harvesting | Inventory every termination point, including the ones sitting in front of your application servers |
| Bumping RSA to 4096 bits or pinning the certificate | Neither helps against Shor’s algorithm; RSA-4096 still falls, and pinning just pins a still-vulnerable certificate | Plan the real move to ML-KEM and ML-DSA, hybrid first |
The load-balancer trap deserves its own line, because it’s the subtle one. Two perfectly migrated endpoints still leave the door open if a legacy device between them terminates the connection on classical cryptography. Inventory the whole path, including the boxes sitting in the middle.
What does a finished first plan look like?
Phase 1 is done when you can put a single page in front of your CISO that answers three questions and nothing else. Keep it to one page on purpose, because a scoped, reversible ask is what a busy executive approves.
The one-page plan carries:
- What’s most at risk. Your top 3 to 5 findings from the ranked queue, each with a one-line reason (“customer API carries 10-year regulated records over harvestable key exchange”).
- What to fix first. The risk-ranked sequence, key establishment ahead of signatures, with the estate-wide trust anchors called out at the top.
- The small first move. One completely reversible pilot, a hybrid handshake on a single internal service, or a discovery pass on one more system, so the team builds confidence without a one-way door.
Above those three, put the two facts that frame it: the named owner, and the binding deadline with its source. That’s the whole deliverable. It’s a few weeks of work, it’s defensible to an auditor because every line traces to your inventory, and it’s exactly what a funding conversation needs. If funding is your next problem, Brief Your Board walks the board narrative, and Own Your Quantum Risk is the same program seen from the executive owner’s altitude.
What do practitioners get wrong about this?
- “I have to become a cryptographer.” No. The work is inventory, prioritization, and sequencing, which are project and architecture skills. The deep math stays in the reference notes for the day you want it, and you can run this whole starter without it.
- “I have to migrate everything.” No. Most systems can wait, and a handful are urgent. The prioritization step exists precisely so you don’t spend your first, most valuable phase on low-consequence cleanup.
- “It’s just swapping a crypto library.” For a well-built application, sometimes. Across a real estate it’s discovery, vendor leverage, agility gaps, PKI and identity keys, and firmware you can’t reconfigure. The library swap is the easy 20%.
- “A scan will find it all.” A scan sees what a server negotiates when probed and misses what it permits, plus everything hardcoded, vendor-opaque, or never exercised in a probed handshake. Configuration extraction is the primary layer; the scan is a cross-check.
- “We’ll wait for our vendors to handle it.” Vendor-controlled surfaces are usually the majority of your footprint, and a vendor won’t volunteer its exposure. A roadmap statement is a promise about the future; shipped protection is what you have today. Verify it. (vendor surfaces)
Questions you’re probably asking
Is this real, or is my boss overreacting to a headline? It’s real, and the threat is already live because adversaries can harvest your encrypted data now and decrypt it later. Why This Exists lays out the case in five minutes.
What do I actually do first, today? Get named as owner (or name one), and identify the single mandate that binds your sector. Then scope a small inventory of your crown-jewel systems. Those are the first real moves.
How long is this going to take? The full migration is a multi-year program. Your first prioritized plan is a few weeks of work, and nobody expects you to finish the migration this quarter.
Do I have to migrate everything? No. Most systems can wait and only a few are urgent. The prioritization step is how you tell them apart, so you fix the estate-wide trust anchors and the harvestable long-lived data first.
Do I need to become a cryptographer? No. You need to inventory, prioritize, and sequence. Knowing that ML-KEM replaces key exchange and ML-DSA replaces signatures is enough to run Phase 1.
Should I buy a vendor “PQC solution” now? Not before discovery. You can’t scope or trust a purchase until you know what cryptography you actually have, so finish the crown-jewel inventory first.
How do I know I found all the cryptography? You don’t, on the first pass, and that’s expected. Layer configuration extraction, static analysis, and vendor inquiry on top of scanning, grade every finding by evidence, and treat the CBOM as a living document rather than a one-time snapshot.
What if a system genuinely can’t be upgraded? Some legacy OT controllers, vendor-locked middleware, and old appliances can’t change their own cryptography. A gateway or proxy can establish quantum-resistant keys on the endpoint’s behalf as a compensating control, so one device’s limits don’t cap the whole estate.
Who should own this? One accountable person with cross-team reach, named in writing. Ask five people who owns the migration; a healthy program gives you one name. Ambiguous ownership is the single most common reason a migration never starts. (who owns it)
Everything you need to build that first plan yourself is right here, given freely: the order of operations, how to build the inventory, how to rank it, and what you’re moving to. When you’d rather have the whole thing built and quantified against your actual environment, defensible to your own regulator, that’s the part I do, and there’s an alignment briefing for it.
Last verified 2026-07-10 · Maintained by Addie LaMarr, LaMarr Labs.