# Post-Quantum Cryptography Migration Plan — Template

> Adapt to your organization. Aligned with the CISA/NSA/NIST Quantum-Readiness factsheet,
> NIST NCCoE SP 1800-38, NIST IR 8547, and NIST CSWP 39 (crypto-agility).
> Source guide: https://pqcstatus.ai/migration.html

## 0. Program summary
- **Executive sponsor:**
- **Migration lead / working group:**
- **Scope (business units, systems in / out):**
- **Bound external deadlines:** CNSA 2.0 (2027, if NSS/gov) · IR 8547 deprecate 2030 / disallow 2035 · OMB M-23-02 (annual inventory) · other: ______
- **Internal target dates:**
- **Budget / reporting cadence:**

## Phase 0 — Governance & roadmap
- [ ] Name sponsor and cross-functional working group (security, infra, apps, procurement, risk)
- [ ] Map external mandates to internal obligations and deadlines
- [ ] Define scope, success criteria, budget, reporting
- [ ] Update policy: new systems must be crypto-agile & PQC-capable
- **Owner:** ___  **Target:** ___

## Phase 1 — Cryptographic inventory (CBOM)
- [ ] Layer 1: mine SIEM/logs + cloud KMS/PKI APIs (fast breadth)
- [ ] Layer 2: passive network capture + targeted active TLS/cert scans
- [ ] Layer 3: source/binary analysis (CBOMkit, cryptobom-forge)
- [ ] Layer 4: host agents (osquery) for keystores/SSH/config
- [ ] Layer 5: reconcile into one CycloneDX 1.6 CBOM with owners
- [ ] Capture per asset: algorithm+params, purpose, data lifetime, exposure, owner
- **Owner:** ___  **Target:** ___

## Phase 2 — Assess & prioritize
- [ ] Score assets with Mosca's inequality (X + Y > Z)
- [ ] Flag harvest-now-decrypt-later exposure and long-lived roots of trust
- [ ] Map dependencies & migration complexity (self vs. vendor vs. hardware)
- [ ] Produce prioritized migration backlog
- **Owner:** ___  **Target:** ___

## Phase 3 — Plan & engage vendors
- [ ] Request vendor PQC roadmaps & support dates (see vendor questionnaire)
- [ ] Add PQC + crypto-agility clauses to procurement/contracts
- [ ] Select target algorithms/params (ML-KEM-768 / ML-DSA-65 defaults) and hybrid strategy
- [ ] Sequence waves: quick wins → high-risk long-lived → embedded/hardware last
- **Owner:** ___  **Target:** ___

## Phase 4 — Remediate, test & pilot hybrid
- [ ] Stand up non-production lab; validate PQC/hybrid handshakes
- [ ] Pilot hybrid key exchange (e.g. X25519MLKEM768) on high-priority TLS/VPN
- [ ] Test larger keys/signatures vs. protocol/buffer/MTU/device assumptions
- [ ] Update libraries; refactor hard-coded algorithms behind an abstraction layer
- **Owner:** ___  **Target:** ___

## Phase 5 — Deploy in waves
- [ ] Roll out hybrid/PQC by priority wave with change control & rollback
- [ ] Reissue certs / re-key from PQC-capable CAs/HSMs where in scope
- [ ] Coordinate both ends of every protocol
- [ ] Track coverage against the CBOM
- **Owner:** ___  **Target:** ___

## Phase 6 — Validate, monitor & report
- [ ] Re-run discovery; confirm vulnerable algorithms removed
- [ ] Monitor for downgrade attacks / classical-only fallback
- [ ] Keep CBOM current; report progress vs. deadlines
- [ ] Validate compliance evidence (FIPS 140-3, CNSA 2.0 where applicable)
- **Owner:** ___  **Target:** ___

## Phase 7 — Crypto-agility (continuous)
- [ ] Keep algorithms behind abstraction/config, never hard-coded
- [ ] Maintain living inventory + scheduled automated discovery
- [ ] Track standards pipeline (HQC, FN-DSA/FIPS 206, revisions)
- [ ] Bake crypto-agility into architecture reviews & procurement
- **Owner:** ___  **Cadence:** ___

---
*Informational only; not legal or security advice. Confirm against primary sources for your jurisdiction and sector.*