up:: 00 Field Guide Map

Own Your Quantum Risk

Owning quantum risk is the executive decision to treat the coming collapse of your public-key cryptography as a business risk you govern on a schedule, rather than a technical problem you delegate and forget.

This page is the whole playbook, written for the person accountable for it: the strategic frame, the full transition roadmap, the algorithms and the deadlines, the governance and vendor and board plays, the first 90 days, and the numbers you report upward.

Read it top to bottom for the entire arc, or jump to the phase you’re in. Every term links to its own note, so you can hover to preview it or open it in a new tab and go as deep as you want. Everything here is yours to use.

The 60-second brief

If you read nothing else, here’s the whole thing:

1. 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. This breaks the key exchange and the trust layer, not the bulk encryption itself.
2. The clock. You don’t get until the machine exists. Adversaries harvest encrypted data today to read later, so any secret with a long shelf life is exposed now, and U.S. rules disallow classical public-key after 2035, with harder gates at 2027 and 2030.
3. Your real deadline is how long your data must stay secret plus how long migration takes, measured against the machine’s arrival (Mosca’s theorem). For regulated records, that math is usually already underwater.
4. The work is 20% cryptography and 80% organization: finding where cryptography hides, owning it, and moving people. It’s a governance program, and it’s yours.
5. This quarter: name one accountable owner, fund a scoped inventory of your crown-jewel systems, and put a return date on the board’s calendar. Everything else builds on those three.

Why quantum risk belongs at the executive level

Cryptography is the trust infrastructure your business runs on, and its scheduled expiry is a governance risk with a legal deadline attached. Three properties make it unlike an ordinary IT problem, and each one is why it lands on your desk rather than a team lead’s:

1. It’s silent. No breach alert announces it. The failure is either retroactive, when data harvested years ago becomes readable, or instantaneous and system-wide, when a trust anchor is forged. By the time it’s visible, the loss has already happened.
2. It’s dated. Unlike most cyber risk, this one has published deadlines you can plan against: 2030 and 2035 in U.S. guidance, with procurement gates sooner. A dated risk is a risk you can be measured on for missing.
3. It’s cross-cutting. The vulnerable algorithm hides in vendor products, firmware, protocols, and systems nobody mapped. No single team’s boundary contains it, which is exactly why it needs someone with budget authority, cross-team mandate, and vendor leverage. That’s you.

The organizations that cross the deadline clean treat this as a program with an owner and a schedule. The ones that stall treat it as a technical task and hand it down, where it competes with feature work and quietly loses. The frame you choose here decides the outcome long before any algorithm does.

What you’re actually exposed to

At decision altitude, your exposure comes down to what breaks, on what clock, and to which of your data.

What breaks, and what survives. Shor’s algorithm dismantles the public-key cryptography that secures key exchange and signatures. Grover’s algorithm only dents symmetric encryption, which you fix by using larger keys. The split is clean:

Cryptography	Quantum attack	Verdict	Replace with
RSA (key transport and signatures)	Shor’s	Broken	ML-KEM for keys; ML-DSA or SLH-DSA for signatures
Diffie-Hellman, ECDH, X25519	Shor’s	Broken	ML-KEM
ECDSA, Ed25519	Shor’s	Broken	ML-DSA or SLH-DSA
AES-128	Grover’s	Weakened	AES-256
AES-256, SHA-256, SHA-3	Grover’s	Safe	Keep

Elliptic-curve algorithms fall to a smaller quantum computer than RSA of comparable strength, so ECC is not the safer place to wait. The full breakdown is in quantum-vulnerable algorithms.

Source: NIST IR 8547.

The two clocks. Your exposure runs on two different timers, and they demand different urgency:

	HNDL (confidentiality)	Trust forgery (authentication)
What’s attacked	Secrets you want to stay private	Signatures, certificates, identity
When it bites	The clock runs today; data harvested now, read later	When the machine arrives; forgery needs a live quantum computer
Worst case	Years of archived records become readable	A forged root CA key, and every certificate under it is untrustworthy at once (PKI collapse)
Fix	Move key establishment to ML-KEM	Move signing to ML-DSA or SLH-DSA

HNDL is why waiting is already expensive. An adversary records your encrypted traffic now and reads it once a machine exists, so any data with a long secrecy lifetime is under attack today even though the machine is years out. Cloud cold storage costs a fraction of a cent per gigabyte per month, so harvesting is within reach of ordinary commercial actors, well beyond nation-states. Source: NSA Venona historical release; Simon Singh, The Code Book.

Your number. Mosca’s theorem turns the industry timeline into your own deadline: X + Y > Z, where X is how long your data must stay secret, Y is how long your migration takes, and Z is the time until a capable machine (a CRQC) exists. When X plus Y exceeds Z, you’re already late. Because Z is genuinely uncertain, you run it three ways, a conservative early arrival, a moderate midpoint, and an optimistic late one, and the assets that come out urgent under all three are the ones you move now, no resolved timeline required.

The move: classify your data by how long it has to stay secret. That single sort feeds every decision after it, and it’s the input only you can commission. The models sit in the risk models.

Isn’t a quantum computer still a decade away?

This is the objection you’ll hear in the room, and it rests on a shaky assumption: that a capability isn’t real until it’s publicly announced. History says otherwise, and the sharpest example is a chip that was flying combat missions while the history books had the timeline wrong.

Historic precedent: the chip that flew in secret for 28 years

In 1968, a small team at Garrett AiResearch, led by Steve Geller and Ray Holt, took on a problem the Navy considered barely possible. The new F-14 Tomcat had wings that swept back and forward in flight, and something had to compute the geometry of those moving surfaces continuously, in real time, from raw air data, inside a fighter pulling hard turns. The expected answer was a heavy analog computer. Holt’s team built a 20-bit chipset instead, the MP944, and made it the brain of the jet’s Central Air Data Computer.

The Tomcat first flew in December 1970 with that chip already doing its job: a working microprocessor running in a frontline weapons system, by some accounts earlier than the Intel 4004 that history usually credits as the first. And then it went dark. The Navy classified the design, and it stayed classified for 28 years. Ray Holt couldn’t publish the full account until 1998.

So for nearly three decades, the public history of computing was wrong about when the microprocessor arrived, because the earliest one was flying under a security stamp. The capability was real, deployed, and decisive years before the world was permitted to know it existed.

That’s the exact shape of the quantum question. A cryptographically relevant machine is a strategic capability, the kind that gets built inside a classified program and announced, if ever, long after it’s operational. So the honest planning question is simple: how long can you afford to assume it doesn’t exist yet? For the F-14, the answer turned out to be 28 years.

Source: recounted in Chris Miller, Chip War (2022); the F-14 MP944 Central Air Data Computer (Garrett AiResearch; Steve Geller, Ray Holt), declassified 1998.

A cryptographically relevant quantum computer would most plausibly arrive the same way, inside a classified program, years ahead of any announcement. The best public evidence for its timing is the Quantum Threat Timeline, an annual expert-survey report from the Global Risk Institute and evolutionQ, lead-authored by Michele Mosca, which aggregates expert probability estimates for a machine that can break RSA-2048. Credible estimates span roughly 2030 to 2040 and beyond. Source: Mosca, M. and Piani, M., Quantum Threat Timeline Report, Global Risk Institute / evolutionQ, globalriskinstitute.org.

So plan against the equation rather than the announcement date. When your data’s secrecy lifetime plus your migration time exceeds the earliest plausible arrival, you’re already late, whatever year the machine is unveiled. And because harvesting is live today, the clock on your long-lived records is running now.

What am I accountable for, and by when?

The regulation that binds your sector sets two things at once, your deadline and your defensibility bar, and it increasingly names a specific executive as the accountable owner. Find the one mandate that names you, and its dates become your program’s spine:

If you…	The mandate that binds you	The dates that matter
Run or sell into U.S. national-security systems	NSA CNSA 2.0	New NSS acquisitions support CNSA 2.0 by Jan 1, 2027; networking and firmware/software signing exclusive by 2030; full transition by 2035
Run U.S. federal civilian systems, or contract to them	NSM-10 + OMB M-23-02 + NIST IR 8547	A prioritized cryptographic inventory has gone to CISA annually since 2023 (first due May 2023 under the Nov 2022 memo); 112-bit public-key deprecated after 2030, all classical disallowed after 2035; 2035 federal goal
Run U.S. federal systems that use TLS	Executive Order 14306	Support TLS 1.3 or a successor no later than Jan 2, 2030; buy from CISA’s published PQC product-category list
Sell into the EU market	EU Cyber Resilience Act and the EU PQC roadmap	CRA reporting obligations (actively exploited vulnerabilities, severe incidents) from Sept 11, 2026, main obligations Dec 11, 2027; the EU roadmap sets transition start by end 2026, high-risk use cases by 2030, broad completion 2035
Operate in the UK	UK NCSC guidance	Discovery by 2028, high-priority migration by 2031, completion 2035
Operate in Germany or France	BSI TR-02102 / ANSSI	Germany: replace RSA-2048 before 2030, binding for federal and critical infrastructure; France: hybrid-by-default, binding for government and vital operators
Run a mobile or telco network	GSMA PQ.1	Industry guidance (2023): cryptographic inventory and risk assessment first, then a five-phase migration
Sell to any organization above	Procurement inheritance	Your customers’ earliest gate, often the 2027 CNSA acquisition date, becomes your effective deadline

Even where no regulation names you directly, the tri-agency NIST Quantum-Readiness guidance (August 2023) is the reference a sector regulator or an insurer will hold you to: stand up a project team, engage your vendors on their PQC roadmaps, inventory your cryptography, prioritize by harvesting exposure, and pilot. NIST’s SP 1800-38 practice guide is the worked how-to.

Sources: NSA CNSA 2.0 FAQ; NIST IR 8547 ipd (an Initial Public Draft, so treat its years as NIST’s stated intent); NSM-10; OMB M-23-02, “Migrating to Post-Quantum Cryptography” (Nov 18, 2022); Executive Order 14306; EU Coordinated PQC Roadmap and Cyber Resilience Act, Reg (EU) 2024/2847; UK NCSC; CISA / NSA / NIST Quantum-Readiness Joint Guidance; GSMA PQ.1; BSI TR-02102 series; ANSSI Mécanismes cryptographiques (RGS).

Two things about these dates catch executives off guard. The 2035 headline is the outer bound, and the gates that actually constrain you arrive far sooner: the CNSA acquisition requirement lands January 1, 2027, the EU’s incident and vulnerability reporting obligations begin in 2026, and NIST has signaled that application-specific transitions for protocols like TLS may run years before 2035. Treat 2035 as the wall you can’t be standing behind, not the year you start. The full set of mandates is mapped in the mandates.

Two more forms of pressure sit alongside the mandates, and a public-company CISO should track both. Under the SEC’s cyber-disclosure rules, a material cyber incident and your governance of cyber risk are disclosable, so quantum-vulnerable exposure of material data is worth reasoning about as a risk factor before it becomes something you explain after the fact. And cyber insurance is the other lever: carriers already price controls like multi-factor authentication, and a missing cryptographic inventory or unaddressed harvesting exposure is the kind of thing underwriting questions and coverage terms tend to move toward over time. Neither sets a deadline, and both reward the same first move, an inventory and a quantified position.

The move: name the single regulation that binds you, put its earliest gate on the record, and identify the executive it holds accountable. “We didn’t get to it” reads badly once a public transition window has closed with your name on the risk.

The transition, end to end: the six phases

Here’s the entire program in one view, so you can see where you are and what’s still ahead. Most of the calendar lives in Phase 4, and most of the risk lives in Phases 0 through 2, where the program either gets real ownership or quietly dies.

Phase	Objective	What you do	What you walk out with	Typical duration
0. Ownership	Put someone in charge	Name an accountable owner; charter a working group; identify the binding mandate	A named owner and a deadline	2 to 4 weeks
1. Discovery	See your real exposure	Build a CBOM of crown-jewel systems; classify data by secrecy lifetime	A cryptographic inventory	1 to 3 months
2. Prioritization	Decide what moves first	Rank by harvesting exposure and blast radius; key establishment ahead of signatures	A risk-ranked migration queue	2 to 4 weeks
3. Strategy	Choose targets and design	Select algorithms; mandate crypto-agility; plan the hybrid rollout	A target-state design	1 to 2 months
4. Execution	Replace the cryptography	Migrate by system class; deploy hybrid; drive vendor commitments; manage the human change	Migrated systems, class by class	Often 3 to 7 years
5. Steady state	Prove it and keep it	Validate coverage; retire the classical components; run crypto-agility as a permanent capability	A defensible, agile posture	Ongoing

The single most common mistake is starting at Phase 3, picking algorithms, before Phases 0 through 2 exist. A team can choose ML-KEM and design a beautiful rollout in weeks, and then nothing happens, because no one owned it and no one knew where the cryptography actually lived. The rest of this page walks each phase in the depth you need to run it.

Phase 1: how do I find all my cryptography?

You can’t govern what you’ve never inventoried, and most organizations discover their real exposure only after they build the inventory, because the vulnerable algorithm hides where a normal asset audit never looks: inside vendor products, embedded firmware, hardcoded libraries, and forgotten systems. The artifact that captures it is a Cryptographic Bill of Materials, a structured record of every algorithm, key, certificate, and protocol configuration, plus the data class it protects and the control boundary it sits behind.

Scope it to your crown-jewel systems first, not the whole estate at once, and insist on real evidence rather than a scan alone. A network scan sees only what a server negotiates when you probe it, and misses what the configuration still permits. In a 2026 corpus study, 21.8% of TLS 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. The stronger inventory reads configuration files directly and treats the scan as a cross-check.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

The move: fund a scoped, owned inventory of crown-jewel systems, graded on evidence rather than vendor assertion. It’s the artifact every later decision stands on. Discovery mechanics are in CBOM and cryptographic discovery.

Phase 2: what do I migrate first?

With visibility, you rank by real risk instead of by system name. Two lenses do the sorting:

1. Harvesting exposure. Which systems carry long-lived data that an adversary can harvest today and read later. That data is under attack now, so it moves first.
2. Blast radius. How far the damage spreads if a system’s cryptography fails. A root certificate authority, a central identity provider, or a code-signing key outranks an isolated application, regardless of which algorithm each happens to run. Rank blast radius 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 reachability trap catches teams here: an internal root CA is hard to reach yet catastrophic if it falls, so low reachability is not low blast radius. And sequence key establishment ahead of signatures, because key exchange is the half exposed to harvesting, which is the one clock already running.

Source: NIST IR 8547 ipd, §4.2.

The move: a risk-ranked queue, harvesting exposure and blast radius first, key establishment before signatures.

Phase 3: which algorithms do I choose?

NIST finalized the first three post-quantum standards on August 13, 2024. Your selection maps cleanly to the job each one does:

You need to…	Use	Notes
Establish keys and exchange secrets	ML-KEM (FIPS 203)	The key-establishment standard; 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; ML-DSA-65 is a common starting point, ML-DSA-87 for national-security systems
Sign long-lived roots of trust and firmware	SLH-DSA (FIPS 205)	Conservative, rests only on hash strength; larger signatures, so reserve it for low-volume, high-assurance signing
Sign where size or speed is constrained	FN-DSA (FIPS 206, planned)	FALCON-derived, smaller signatures; not finalized in the November 2024 draft, so not yet part of the schedule

The practical cost of the new algorithms shows up in size rather than speed. ML-KEM keys and ML-DSA signatures are larger than their classical counterparts, which matters for certificates and constrained devices more than for a typical server.

Sources: NIST FIPS 203, FIPS 204, FIPS 205, August 2024.

One algorithm choice carries an availability consequence worth flagging to your operations team. SLH-DSA signing is orders of magnitude slower than the ECDSA it might replace, so putting it on a high-volume signing path, payment authorization, a public certificate authority, high-rate code or token signing, can let requests arrive faster than your hardware security modules can clear them, and the queue backs up until the service effectively stops. That’s a self-inflicted outage, needing no attacker and no quantum computer, and it’s the one migration risk that gets worse as you adopt the most conservative standard. The rule that avoids it is a sequencing one: keep the slow, high-assurance signatures on the low-volume roots of trust where they belong, and use ML-DSA on the high-throughput paths.

Above the individual choices, insist on one architectural law: crypto-agility, building so the next algorithm change is a configuration update instead of a rebuild. There will always be a next one, and a program that hardcodes today’s choice is signing up to run this same migration again in five years. In 1586, Mary, Queen of Scots trusted a cipher that Walsingham’s cryptanalyst had already broken, and her failure was structural: she had no way to recognize the cipher was compromised and no way to change it. That’s the capability crypto-agility gives you.

Source: Simon Singh, The Code Book.

The move: the target algorithm per job, a hybrid plan for the transition, and crypto-agility mandated on everything new.

Phase 4: what does migrating actually change, system by system?

Execution is where the calendar goes, and “migrate” means something different for each class of system. During the transition, most key exchange runs hybrid, a classical algorithm and a post-quantum one together, so the connection stays safe as long as either survives. One governing rule holds across all of it: a protocol is only as quantum-safe as its weakest deployed endpoint, so a single un-migrated load balancer or legacy gateway reopens the harvesting door.

System class	What actually changes	Watch out for
Web and TLS	Hybrid key exchange (classical X25519 with ML-KEM), then ML-DSA certificates over time	One un-migrated load balancer or legacy gateway reopens the exposure
PKI and certificates	Migrate the CA’s own signing keys; plan trust-store distribution and reissuance	Reissuing leaf certificates without migrating the CA key leaves the real exposure untouched
Code and firmware signing	Move to ML-DSA, or SLH-DSA for long-lived roots of trust	Already-signed binaries keep verifying; plan re-signing and timestamping
VPN and network gear	Hybrid key exchange on IPsec tunnels; much of it vendor firmware	Fixed-firmware equipment may need replacement rather than a config change
Identity (SAML, JWT, SSO)	Migrate token-signing keys, often owned by a different team than PKI	High blast radius, and frequently left out of the inventory
Data at rest	Usually fine, since AES-256 survives; re-wrap keys protected by RSA or ECDH	The key-wrapping path is the exposure, not the bulk cipher

Some things that look like fixes are not. Bumping RSA to 4096 bits buys almost nothing against Shor’s algorithm, and certificate pinning just pins a still-vulnerable classical certificate. The protocol-level detail is in the protocols and the new standards.

Phase 5: crypto-agility, so you never run this migration blind again

The lasting deliverable of the whole program is not a set of new algorithms, it’s the capacity to change algorithms cleanly. Crypto-agility means treating algorithm choice as configuration rather than a baked-in assumption, through abstraction layers, key-management services, provider architectures, and protocol negotiation. Build it once, and the next transition, and there will be one, becomes a config change instead of a multi-year project.

Source: Bertino et al., “Quantum-Resistant Networks,” arXiv:2605.04129 (2026).

Why do these programs stall, and how do I stop it?

Post-quantum migrations stall on the organization rather than on the cryptography. The algorithm swap is the easy 20%; roughly 80% of the effort and nearly all of the delay live in three human problems, and a cryptographer never touches any of them. The question forming in your head right now is probably “who actually owns this?”, and in most organizations the honest answer is “no one, exactly,” which is the single most common reason a program never starts.

1. Ownership. Cryptography is cross-cutting, so it falls between engineering, security, procurement, and governance, and a migration with no single accountable owner drifts. No function can own it alone: engineering controls rollout but not contracts, the CISO owns the risk but not the purchasing levers, procurement holds the vendor leverage but doesn’t assess crypto risk. The test is simple: ask five people who owns the migration, and a healthy organization gives you one name. You name that owner first, in writing, before discovery or budget. (who owns it)
2. People. The engineers who do the work often quietly fear it makes their hard-won expertise obsolete, so resistance shows up as a hundred small delays rather than open refusal. The way through is the smallest completely reversible first moves, a hybrid handshake on one internal service, a discovery pass on a single system, so the team builds confidence without a one-way door. Frame it around what they gain, less firefighting later and a scarce, rising skill, and make it the new baseline rather than a crisis. (change management)
3. Vendors. Vendor-controlled cryptography is usually the majority of your footprint by surface count, and the largest source of timeline uncertainty. A vendor won’t volunteer its exposure, because that spooks customers and commits it to a roadmap it would rather keep flexible. So the vendor sets your migration clock unless you take the leverage back. (vendor surfaces)

The difference between a program that ships and one that stalls is visible early:

A program that will ship	A program that will stall
One named executive owner	Ownership split across three teams
Crown-jewel systems scoped first	A boil-the-ocean full inventory
Reversible first moves that build confidence	A high-stakes debut on a critical system
Vendor deadlines written into procurement	Waiting for vendors to volunteer their exposure
Progress reported on the executive cadence	Migration left as work nobody is measured on

There’s precedent for the pattern. Germany’s Enigma was a genuinely strong cipher, and it fell on brilliant cryptanalysis combined with the human layer around it: operator shortcuts, predictable message formats, and sloppy key handling. The mathematics largely held, and the operations around it did not. Cryptographic systems have failed at the human seams first for as long as they’ve existed, which is why this is as much a change-management program as a cryptographic one.

Source: Simon Singh, The Code Book, on Enigma and Bletchley Park.

The move: one accountable owner, a sustainable cadence, and a deliberate plan for the human resistance. The full picture is in why migrations stall.

What exactly do I ask my vendors?

Because vendor surfaces dominate your footprint and your timeline, the questions you put to vendors are among your highest-leverage moves. Ask each critical vendor these, and record the answers in your CBOM alongside the contract-renewal date:

Ask your vendor	What the answer tells you
Do you have a published post-quantum roadmap?	Whether planning is even possible
Which algorithms will you support, and by when?	Alignment with the ML-KEM and ML-DSA timeline
Is my current product tier covered for the upgrade?	Whether your existing contract pays for the migration
Do I switch post-quantum support on, or do you decide?	Whether you control the timing
What’s your FIPS 140-3 validation status for the new algorithms?	Compliance readiness
Will you commit to it contractually?	Whether the roadmap is enforceable or just marketing

A verbal “we’re working on it” buys you nothing you can plan on, and only a contractual commitment is real. Almost all of your leverage lives at procurement and renewal, not in daily operations, so write post-quantum readiness into new RFPs, negotiate dated support obligations at renewal, and point regulated-serving vendors at the mandate that binds you. An opaque vendor surface with no roadmap and a long timeline is one of the highest-priority findings in any migration.

How do I get this funded and defend it to the board?

Defensibility keeps a migration funded through the budget fights and lets you answer a board or a regulator without flinching. Two moves get you there:

1. Quantify it. Turn “our RSA is quantum-vulnerable” into a number. Cyber risk quantification expresses the exposure as a probable dollar loss against your stated risk tolerance, by estimating how often a loss occurs and how much it costs, each as a calibrated range rather than a single fabricated figure. Harvesting exposure feeds the loss magnitude, the arrival timeline feeds the frequency, and the output is a loss-exceedance curve a board can weigh against every other investment. “Expected loss of X, which exceeds our stated tolerance” is the sentence that moves a migration from a backlog item to a funded program.
2. Document it. Keep a cited, dated roadmap tied to the mandate that binds you, so your decisions carry their own evidence in front of an auditor.

Source: The Open Group Open FAIR; FAIR Institute.

This plugs into the risk frameworks you already run rather than adding a new one. FAIR is the bridge from a qualitative risk appetite to a defensible dollar tolerance, supplying the financial-impact term that NIST SP 800-30 and SP 800-39, ISO 31000, and COSO ERM leave qualitative. Where a regulatory floor already binds you, DORA, APRA CPS 234, FFIEC, or FISMA, that floor sets a tolerance regardless of appetite, and quantum exposure is weighed against it like any other operational risk.

Source: NIST SP 800-30 Rev 1; NIST SP 800-39.

Keep the ask board-shaped. You’re not asking them to rebuild your cryptography, you’re asking them to fund a time-boxed inventory and a quantification pass, name an owner, and set a return date. A scoped, reversible ask is what a board approves. The full board narrative, the two numbers that land, and the free starter deck are in briefing your board and Doing the Work.

What do I do in the first 90 days?

1. Days 1 to 15, name the owner and the mandate. Assign one accountable executive owner, in writing and in their actual objectives, and identify the single regulation with a date that binds you. Ambiguous ownership is the most common reason a program never starts.
2. Days 15 to 45, fund a scoped inventory. Authorize a time-boxed cryptographic inventory of crown-jewel systems, graded on evidence. Scope it to answer one question: where is quantum-vulnerable public-key cryptography, and on what data.
3. Days 45 to 75, rank by risk. Sort the findings by harvesting exposure on long-lived data and by blast radius, and open the vendor conversation on every critical surface. The top of that list is your migration sequence.
4. Days 75 to 90, set governance and a return date. Establish the reporting cadence, mandate crypto-agility on new systems, and put a date on the board’s calendar to return with the quantified program.

By day 90 you hold a named owner, the binding deadline, a crown-jewel inventory, a risk-ranked sequence, and a scheduled board return. That’s a defensible position, built in a quarter.

How do I measure and report progress?

Give the board the same few numbers every cycle, so the program reads as managed rather than open-ended:

1. Crypto visibility: percent of crown-jewel systems with a completed inventory.
2. Harvesting exposure closed: percent of long-lived-data systems moved to ML-KEM, hybrid included.
3. Trust surface migrated: percent of high-blast-radius signing and PKI moved to ML-DSA or SLH-DSA.
4. Agility coverage: percent of new systems built crypto-agile.
5. Vendor commitments: count of critical vendors with a dated, contractual roadmap.

These five turn a multi-year effort into a dashboard you can defend, and they give you the language to show forward motion long before the last system is migrated.

For a single figure that captures maturity rather than progress, some boards adopt a quantum-readiness level per system: a five-level scale running from “no capable machine exists” (Level 1), through “harvesting is the live concern” (Level 2, the honest default for most systems today), to “capable machines are widely available” (Level 4). You set a target level per system from its data lifetimes and threat relevance, then report the percentage of systems designed to meet it. It’s an ordinal scale rather than a calibrated metric, so use it to communicate posture, not to replace the quantified exposure.

Source: Bertino et al., “Quantum-Resistant Networks,” arXiv:2605.04129 (2026), §5.5.

What do I run in-house, and where do I bring in help?

Be honest about capacity, because that honesty is part of owning the risk. Everything above is here, given freely, and a capable team can take it a long way. The honest line runs like this:

Capability	Run it in-house	Bring in a specialist
Cryptographic inventory of crown-jewel systems	A capable security team with the right tooling	When the estate is large, vendor-dense, or you need it audit-graded fast
First prioritized migration sequence	Yes, straight from this guide	Not required
Board-ready framing and a small reversible ask	Yes	Not required
Exposure quantified against your actual records and dollars	Beyond most in-house tooling	Yes, a specialized and defensible modeling exercise
A roadmap defensible to your specific regulator	Draft it	Yes, to make it audit-grade
Vendor-leverage strategy for surfaces you can’t move alone	Partly	Yes, where the leverage is both contractual and technical

The move: decide, capability by capability, what your team owns and where a specialist earns the fee. Making that call honestly is itself what a defensible program looks like.

The questions your board, CFO, and regulator will ask

Am I personally on the hook for this? Increasingly, yes. Regulation is moving cryptographic risk onto named executive owners, and “we didn’t get to it” reads badly once a public transition window has closed and a deadline has passed.

What’s this going to cost? It scales to your exposure, and you size it by funding a time-boxed inventory and a quantification pass first, rather than signing a blank check. Those two outputs tell you the real shape and cost of the program before you commit to it.

Aren’t our vendors already handling this? Mostly not, and you verify rather than assume. The vulnerable algorithm sits inside dozens of vendor products on timelines the vendor controls, and a roadmap statement is a promise about the future, while shipped protection is what you actually have today.

Can my existing team handle this, or do I need help? A capable team can run discovery and a first prioritized plan from this guide. The quantified exposure model, the regulator-defensible roadmap, and the vendor-leverage strategy are where most teams bring in a specialist.

What’s the one move this quarter? Fund a scoped cryptographic inventory, name an executive owner, and put a return date on the board’s calendar. Everything defensible starts from those three.

What do executives get wrong about quantum risk?

• “Our vendors have this handled.” Mostly they don’t, and a roadmap statement is a promise about the future, while shipped protection is what you have today. Verify it. (vendor surfaces)
• “Quantum is a decade out, so this is premature.” Your deadline comes from your data’s secrecy lifetime plus your migration time, and for long-lived regulated records that math is already underwater. (Mosca’s theorem)
• “This is an IT problem.” It stalls on ownership, budget, and vendor leverage long before it stalls on cryptography. It’s a governance program, and it’s yours to own. (why migrations stall)
• “We’ll deploy hybrid and be done.” Hybrid is a bridge, and the classical half still has to come out before the deadline. (CNSA 2.0)
• “We finished, we migrated our systems.” The systems you control are the easy part. The vendor-controlled surfaces, usually the majority, are where the exposure lingers. (vendor surfaces)

Quick reference: the vocabulary

The terms you’ll want to use fluently in the room, each linked to its full note:

• HNDL (Harvest Now, Decrypt Later): recording encrypted data today to decrypt it later. Why the clock is already running.
• CRQC: a machine large enough to break RSA and elliptic-curve cryptography. None exists yet.
• Mosca’s theorem: X + Y > Z, your secrecy lifetime plus migration time against time-to-machine. Your deadline in one line.
• ML-KEM (FIPS 203): the post-quantum standard for key establishment. Replaces RSA and ECDH key exchange.
• ML-DSA (FIPS 204): the general-purpose post-quantum signature. Replaces ECDSA and RSA signing.
• SLH-DSA (FIPS 205): the conservative, hash-based signature for long-lived roots of trust.
• CBOM: the inventory of every algorithm, key, and certificate you run.
• Crypto-agility: building so the next algorithm change is a config swap, not a rebuild.
• Hybrid: running a classical and a post-quantum algorithm together during the transition.
• Blast radius: how far the damage spreads when one cryptographic control fails.
• CNSA 2.0 and NIST IR 8547: the U.S. national-security and civilian deadline sets, converging on 2035.

---

Everything on this page is the map, given freely: your exposure, the mandate that binds you, the six-phase roadmap, the algorithms, the vendor and board plays, and the honest line between what your team runs and where a specialist earns the fee. The tailored work, your exposure quantified against your actual records and dollars and a roadmap built to survive your specific regulator, is the engagement. There’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.