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.
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.