Standing up a post-quantum migration program
How to turn 'we should do something about quantum' into a funded program with an owner, a plan, and a budget — roles, a RACI, a phased timeline, and the first ninety days.
The shape of a program
A post-quantum migration is a multi-year cryptographic modernization, not a one-off project. It needs a named executive sponsor, a single accountable program lead, a cross-functional working group, and a phased plan anchored to a cryptographic inventory. Fund the inventory first — you cannot scope, sequence, or budget a migration until you know where your vulnerable cryptography actually lives.
Most organizations already agree post-quantum cryptography matters. Where they stall is turning that agreement into an owned, funded program. The failure mode is a slide deck with no budget line and no name next to 'accountable'. This article is the antidote: the roles, the decision rights, the timeline, and the concrete first ninety days.
Roles and decision rights
A migration touches identity, networking, application teams, procurement, and risk. That breadth is exactly why it needs clear ownership. Vague ownership is the single most common reason these programs stall — everyone assumes someone else holds the crypto.
- **Executive sponsor** — usually the CISO or CTO. Owns the budget ask, removes blockers, and reports risk to the board. Accountable for the program existing at all.
- **Program lead** — one named person, accountable end to end. Not a committee. Runs the plan, the inventory, and the reporting. This is the role most often left unfilled.
- **Crypto / architecture owner** — makes the technical calls: which algorithms, hybrid or not, migration sequencing. Owns the crypto-agility target architecture.
- **Domain leads** — TLS/PKI, identity, data-at-rest, code signing, and applications each need someone responsible for migrating their surface.
- **Procurement / vendor risk** — drives third-party readiness into contracts and renewals.
- **Program manager** — tracks the plan, dependencies, and reporting cadence so the lead can focus on decisions.
Name one accountable lead before anything else
The first governance decision is not which algorithm or which vendor — it is who is accountable. Appoint a single program lead with a mandate and a reporting line to the sponsor. Everything else (inventory, budget, timeline) flows from that appointment. A program with shared accountability has none.
A simple RACI
Keep the decision-rights model boringly explicit. For each major activity, exactly one role is Accountable, one or more are Responsible for the work, others are Consulted, and the rest are Informed.
- **Cryptographic inventory** — Accountable: program lead. Responsible: crypto owner + domain leads. Consulted: application teams. Informed: sponsor.
- **Risk prioritization** — Accountable: crypto owner. Responsible: program lead. Consulted: risk / data governance. Informed: sponsor, domain leads.
- **Target architecture (crypto-agility)** — Accountable: crypto owner. Responsible: architecture team. Consulted: domain leads. Informed: program lead.
- **Vendor readiness** — Accountable: procurement / vendor risk. Responsible: domain leads. Consulted: crypto owner. Informed: program lead.
- **Board / executive reporting** — Accountable: sponsor. Responsible: program lead. Consulted: risk. Informed: working group.
A phased timeline
Sequence the program in phases that each produce a decision-quality artifact. Do not try to migrate anything before you have discovered and prioritized it — a discover-first order is what keeps the program honest.
- **Phase 0 — Mobilize (weeks).** Appoint the lead, form the working group, secure seed funding for discovery, and agree how you will report.
- **Phase 1 — Discover (1–3 months).** Build the cryptographic inventory / CBOM. Find every use of RSA, ECDH, and ECDSA across TLS, PKI, code signing, data-at-rest, and identity.
- **Phase 2 — Assess & prioritize (1–2 months).** Score each asset by data shelf life and exposure using the harvest-now-decrypt-later lens. Produce a sequenced backlog.
- **Phase 3 — Architect for agility (ongoing).** Decouple systems from hard-coded algorithms so future swaps are configuration, not rewrites.
- **Phase 4 — Migrate by domain (multi-year).** Start with externally-facing key exchange (hybrid TLS), then PKI, secrets, and long-lived data. Signatures follow.
- **Phase 5 — Validate & sustain (ongoing).** Interoperability and performance testing, continuous rescanning, and vendor tracking so you do not regress.
Do not wait for a 'final' timeline to start
The exact year a cryptographically-relevant quantum computer arrives is unknowable, and teams use that uncertainty as a reason to defer. But discovery and crypto-agility work pays off regardless of when Q-Day lands — and it is the long pole. Start the inventory now; you can sequence migrations later, but you cannot compress the years of discovery you skipped.
Budgeting the ask
You cannot put a credible number on the full migration before the inventory exists — and that is fine. Fund discovery as a discrete, small first tranche, then let the prioritized backlog drive the multi-year budget. Frame the spend in categories rather than inventing a precise figure: discovery tooling and effort, architecture and engineering time for agility, per-domain migration work, vendor and procurement effort, and training. The inventory turns a hand-wave into a defensible line-by-line request.
Your first ninety days
- Get the sponsor to name the program lead in writing.
- Stand up a small cross-functional working group and set a reporting cadence.
- Fund and kick off the cryptographic inventory — this is the anchor for everything.
- Agree the readiness metric you will report from day one, so progress is visible early.
- Draft the leadership briefing (see the leadership-brief article) and get the risk on the record.