Decommissioning & Program Closure
Retire classical cryptography on a defensible schedule, prove the migration happened from observed behaviour, and hand the program to business-as-usual.
Why this matters: A migration isn't done when the ticket closes — it's done when the system's observed behavior proves it, and closing the program without that evidence just defers the risk instead of retiring it.
Start here: Retire one classical asset in the Decommission Checklist: deprecate, remove, verify removed, log — the four gates a closure claim has to show.
For your role
- Executive / Business Leader
- Retire one classical asset through deprecate, remove, verify removed and close, plan which systems to verify with what proof per tier, and hand standing capabilities to permanent owners: done means proven, not ticketed.
- GRC / Risk & Compliance
- The Verification Coverage Planner sets the proof per tier, and the Closure & Handover Register records the transfer of standing capabilities: the closure evidence the Migration Verification tool collects.
- IT Ops / DevOps
- The Decommission Checklist is the runbook for retiring a classical asset; the coverage planner says which systems need observed-behaviour proof and which a lighter check.
Retire classical crypto safely
● standardThe migration isn't done when PQC is added — it's done when the classical cryptography is gone. The defensible schedule is the deprecation timeline: NIST IR 8547 (still a draft) proposes deprecating 112-bit-strength RSA/ECC/finite-field key exchange after 2030 and disallowing all quantum-vulnerable public-key cryptography after 2035; NCSC-UK sets phased targets — 2028 (discovery + plan), 2031 (highest-priority migration), 2035 (complete); NIST SP 800-131A carries the transition rules.
The discipline is four steps: deprecate → remove → verify removed → log. The step teams skip is the third — confirm by observation that the old key material is gone, not just that a new key exists.
Prove it from observed behaviour
◆ practitionerA system is “migrated” when its behaviour shows it — the handshake negotiates ML-KEM/ML-DSA — not when a change ticket says so. Reuse the Active PQC Scanner (in the PQC Testing module) and passive handshake capture to collect the evidence. (Evidence-by-observed-behaviour is practitioner guidance.)
● standardThe control basis is independent: NIST CSWP 48 (draft) maps the NCCoE Migration-to-PQC capabilities to CSF 2.0 and SP 800-53.
Coverage at estate scale
◆ practitionerYou can't verify a large estate by hand, so decide which systems and what proof per tier: verify business-critical systems fully, sample the rest per migration wave, and let any sampled failure widen the check. (The specific sampling rule is practitioner guidance, not a named standard.)
Close into business-as-usual
◆ practitionerPrograms drift into an unfunded twilight unless they close deliberately. Define closure criteria in advance, accept residual risk with a named owner + re-evaluation date, and hand the standing capabilities — CBOM, continuous discovery, vendor cadence, SOC content, KRIs, crypto-agility — to permanent owners, with an archived evidence dossier.
● standardAnchor the generic governance to ISO/IEC 27001 and the NIST Risk Management Framework (SP 800-37) residual-risk-acceptance process. Make “acquire only PQC-capable products” a standing procurement rule — the CISA product-category list (2026) flags the categories where they are already available.
Related modules
Check your understanding
15 questions on Decommissioning & Program Closure, each with its answer and the reason.
Take the quizNext step
Produce the artifact: Migration Verification & ClosureThis module belongs to the Verification & Closure phase; Migration Verification & Closure produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.