N° 06Migration

The Countdown

The CII foundation deadline is roughly nineteen months out. This is what belongs in each window — and why the work that wins is front-loaded into the one we're in now.

THREE WINDOWS (CII TIMELINE) NOW → Dec 2027 FOUNDATION ▸ Stand up governance ▸ Discover & inventory crypto ▸ Generate first CBOM ▸ Quantum risk analysis ▸ Persona classification ▸ Pilot PQC on 1–2 systems ~19 months from today 2027 → Dec 2028 MIGRATE ▸ Fund migration programmes ▸ No new classical-only systems ▸ PQC-capable PKI + hybrid certs ▸ Upgrade HSM / KMS / libraries ▸ Mandate vendor CBOMs ▸ Independent validation 2028 → Dec 2029 FULL RESILIENCY ▸ PQC as default everywhere ▸ Retire classical-only roots ▸ PQC-only trust chains ▸ All signatures quantum-safe ▸ Enclose un-migratable legacy ▸ Institutionalise crypto-agility
Windows shown on the CII clock (Foundation 2027 · Migrate 2028 · Full 2029). Regular enterprises run the same sequence on the 2028 / 2030 / 2033 schedule.

It is tempting to read the 2029 (or 2033) endpoint as the deadline and work backwards leisurely. That misreads how the programme actually loads. The hardest, slowest, most dependency-laden work sits in the first window — and that window, for CII, closes around December 2027, roughly nineteen months from now.

Window one — Foundations (now → Dec 2027)

Nothing in the later milestones is possible without this. The report's Milestone 1 asks for governance with board oversight, a complete cryptographic inventory, quantum risk analysis, asset prioritisation, persona classification, the first CBOM, and early PQC pilots on one or two high-priority systems.

The order matters. Discovery feeds the CBOM; the CBOM feeds risk analysis; risk analysis feeds prioritisation. Skip or rush the first and everything downstream inherits the error. This is also the window where you learn your own performance constraints by piloting before committing — the report deliberately sequences pilots ahead of funded migration.

The work here is mostly understanding rather than changing, which is precisely why organisations defer it — and precisely why deferring it is fatal. You cannot compress a year of discovering decades of accumulated cryptography into the quarter before an audit.

Window two — Migrate high-priority systems (2027 → Dec 2028)

Now pilots become funded programmes with KPIs. Three obligations from the report define this phase:

  • "No new classical-only deployments." This bites immediately and quietly: every project that ships RSA-only from here adds to the backlog you're trying to clear.
  • PQC-capable PKI and hybrid certificates, plus upgrading the root-of-trust layer — HSMs, KMS and cryptographic libraries — beginning with high-priority systems.
  • Vendor CBOM mandate (FY 2027–28) and contractual PQC/crypto-agility clauses, so the supply chain migrates with you rather than stranding you.

Independent third-party validation enters here too — the report wants migration progress confirmed externally, not self-attested.

Window three — Full resiliency (2028 → Dec 2029)

PQC becomes the default. Classical-only roots of trust are retired, internal trust chains run PQC-only, and every digital signature is quantum-safe. Systems that genuinely cannot migrate are contained within segmented enclaves under a layered risk-management approach, with planned decommissioning. The endpoint is not "we replaced some algorithms" but "cryptographic change is now a managed, repeatable capability" — which is the definition of crypto-agility.

The deadline that should drive your budget is 2027, not 2029. The foundation is where the calendar gets eaten.

The sequencing mistakes that cost the most

  • Treating discovery as a formality. Every week saved here is repaid with interest in window two, when you migrate systems you didn't know existed.
  • Migrating before prioritising. Without a graph CBOM, teams fix the visible and easy rather than the exposed and critical. HNDL-exposed, internet-facing paths protecting regulated data come first.
  • Ignoring the supply chain until 2027. Vendor readiness is the report's named risk; a core-banking or payments vendor that can't produce a CBOM becomes your bottleneck on someone else's timeline.
  • Skipping pilots. PQC's performance overhead is real; discovering it in production on a payment rail is the most expensive way to learn it.

What to do this quarter

Three concrete moves need no budget approval to begin. Confirm your persona honestly (and apply the highest-risk one). Commission a first cryptographic discovery and a baseline CBOM on your most critical, most exposed system — not the whole estate, just enough to calibrate effort. And insert a CBOM-and-roadmap request into your next vendor procurement, ahead of the mandate. None of these is the migration; all of them are the foundation the migration stands on.

Where KavachQ fits · PLAN · 03

KavachQ's PLAN module produces exactly the window-one artefact a board needs: a prioritised migration backlog tiered P0 / P1 / P2 (immediate HNDL-exposed first, then regulated-data systems, then legacy), with engineer-day effort estimates and each task pinned to its DST deadline. It exports to formats engineering teams already run on, so the plan moves from a report into a tracked programme.
→ Start with one critical system to calibrate effort, then scale the plan.