India's 2029 PQC Deadline, Decoded: What the DST Roadmap Actually Requires

Most coverage of post-quantum cryptography still treats it as a physics story: when will a cryptographically relevant quantum computer exist, whose qubit count is real, which lab published what. That framing lets security teams file the whole subject under "not this year."

For Indian critical infrastructure, that filing decision expired in February 2026. The Department of Science and Technology, under the National Quantum Mission, published Implementation of Quantum Safe Ecosystem in India — a Task Force report chaired by the CEO of C-DOT and co-chaired by the Director of IIT Kanpur, with sub-groups led by the Telecommunication Engineering Centre on testing and certification and by DSCI on migration strategy. It is not a discussion paper. It sets dated milestones, and it makes cryptographic inventory a compliance artifact rather than an architectural nicety.

This post is the first in a series on what quantum-safe migration means operationally. No qubits here — just the deadlines, what they demand, and where the work actually is.

The timelines

The report splits the world into two tracks. Critical Information Infrastructure — defence, power, telecom, transport and BFSI — runs on an accelerated schedule. Everyone else follows a baseline schedule two to four years behind.

The CII track compresses three milestones into 24 months. The baseline track has six years for the same work.

Two structural details matter more than the dates themselves.

First, the report directs that where an organisation matches more than one profile, the highest-risk one governs. A bank that also operates telecom infrastructure follows the CII track for that infrastructure. If you have been assuming the 2033 date applies to you, check whether any part of your estate pulls you onto the 2029 track.

Second, planning is to proceed on an assume-breach basis with respect to Harvest Now, Decrypt Later. The premise is that traffic captured today may be decrypted later, which makes retrospective mitigation impossible: you cannot un-send data that an adversary already holds. That single assumption is what turns a 2029 deadline into a 2026 problem for anything with a long confidentiality life — health records, credit files, biometric templates, long-lived contracts, source code, root key material.

Milestone 1 is the one to worry about

December 2027 sounds like the easy one. Establish governance, appoint an owner, inventory your cryptographic assets. It reads like paperwork before the real migration starts.

It isn't. Every subsequent milestone depends on the inventory being accurate, and cryptography is one of the worst asset classes to inventory in a modern estate. Ask where RSA and ECC live in your organisation and the honest answer spans:

• Application code — hardcoded algorithm choices, key sizes, signing routines, JWT verification, custom crypto helpers written years ago by someone who has left.
• Third-party dependencies — the transitive library six levels down your build graph that pins an old cipher suite, and the SDK that quietly negotiates its own TLS.
• Cloud configuration — KMS key specs, load-balancer TLS policies, S3 and RDS encryption settings, VPN and tunnel parameters, certificate managers.
• Identity and access — token signing algorithms, SAML and OIDC assertions, service-account keys, mTLS between internal services.
• Network and endpoints — public TLS termination, expiring certificates, legacy protocol support left enabled for one integration partner nobody wants to break.

Five layers, five discovery methods. No single tool covers all of them, which is why most inventories are partial before they are stale.

A consultant-led audit can produce a snapshot of that estate. What it cannot produce is a snapshot that is still true next quarter. Between the audit and the deadline you will ship hundreds of deploys, add dependencies, spin up services and rotate certificates. Any inventory that isn't regenerated continuously is a document about the past.

That's the practical reason the 2027 milestone deserves attention now rather than in late 2027: it is not a task you complete, it is a capability you have to stand up.

CBOM turns inventory into a procurement gate

The report doesn't leave inventory as an internal exercise. From FY 2027–28, vendors selling into government and CII are expected to supply a Cryptographic Bill of Materials — a machine-readable inventory of the cryptographic components in a system, sitting alongside SBOM and hardware and quantum equivalents.

For anyone who lived through the SBOM transition, the shape of this is familiar. A documentation requirement attached to procurement propagates down the supply chain far faster than any technical mandate, because the buyer's deadline becomes the seller's deadline. If you sell software to a bank, a power utility or a telco in India, the CII 2027 milestone is your milestone too, one contract renewal removed.

The corollary is worth stating plainly: if you cannot generate a CBOM for your own product, you will be answering questionnaires by hand while competitors attach a file.

Certification: four assurance levels, three lab tiers

Alongside migration, the report lays out a national testing and certification framework — four assurance levels and three tiers of laboratory, with labs to be operational by December 2026 and Tier-3 sovereign-grade facilities aimed at CII protection.

The report is unusually candid about the gap here. It acknowledges that PQC testing labs do not yet exist in the country, that hardware OEMs have been reluctant to share the design documentation deeper validation requires, and that the pool of people with PQC-specific skills is small. Independent commentary has questioned whether the 2029 CII date is achievable at the stated funding level.

That candour is useful rather than discouraging, but it has a planning implication. Expect the certification path to firm up later than the migration clock demands, and expect interim arrangements. Don't sequence your own work as "wait for the labs, then inventory." The inventory is the part you control, and it's the input to everything else.

What to do in the next twelve months

If you operate CII in India, or sell into it, a reasonable posture for the coming year:

1. Name an owner. Quantum risk that belongs to everyone belongs to no one. The report expects cross-functional governance, not a line item in an existing risk register.
2. Find out how bad the inventory problem is. Not the full inventory — a sample. Pick two production services and try to enumerate every algorithm, key length and certificate involved, across code, dependencies, cloud and identity. However long that takes, multiply by your service count. That number is your real Milestone 1 estimate.
3. Classify by data shelf life, not system criticality. HNDL exposure is a function of how long your data stays sensitive. A system that handles data which is worthless in 18 months is a different risk from one holding records that must stay confidential into the 2040s.
4. Add crypto-agility to your architecture review. Every new system should answer one question: how hard would it be to change the algorithm? Hardcoded and vendor-locked cryptography is what makes 2029 expensive.
5. Ask your vendors now. Their CBOM readiness is your dependency. Some will have an answer, and their answer tells you something about the rest of their engineering.

Where this series goes next

Migration order is the part almost nobody has worked out yet. "Inventory everything, then migrate everything" is not a plan for a 2029 deadline — there is not enough engineering time in the estate. What's needed is a defensible way to rank vulnerable cryptography by exposure, so the work that happens first is the work that actually reduces risk.

Both entries read "RSA-2048" in an inventory. Only one of them is being harvested today.

That ranking problem is what the next posts are about: why harvest-now-decrypt-later is really a data-classification exercise, why cryptographic inventory defeats spreadsheets, and how attacker reachability changes the migration order. An internal RSA key behind three layers of network isolation and a public TLS endpoint on a customer-data API are not the same deadline, even though a flat inventory lists them side by side.

Xhield builds continuous attack surface intelligence for teams that need to know what changed before attackers do. If you're scoping cryptographic inventory across code, cloud and identity, we'd like to hear how you're approaching it — contact@xhield.tech.