Four tiers, not four verdicts

The DST National Quantum Mission Task Force has produced a tiered framework for cryptographic assurance in Indian systems. The tiers are named L1, L2A, L2B, L2C, L3, and L4 — six categories, increasing in criticality. The framework is meant to give regulators, auditors, and CISOs a shared vocabulary for talking about where a system sits in the national criticality stack and what level of cryptographic hardening is expected at that tier.

That's the use it was designed for. The misuse — common enough in PQC pitch decks to be worth calling out — is reading the framework as a scoring system that assigns each individual asset a verdict. It is not that, and treating it that way produces unreliable reports.

What each tier names

From the bottom up, the tiers cover increasing levels of consequence if cryptography fails. For BFSI specifically:

• L1 — Internal collaboration. Email, intranet, ticketing, document sharing. Confidentiality and integrity matter; consequence of failure is operational embarrassment, not systemic risk. Expected hardening: contemporary PQC-hybrid TLS, sensible defaults, low evidentiary burden.
• L2A — Business-line applications. Loan operations, treasury, trading desks, internal analytics. Failure has business consequences but bounded systemic impact. Expected hardening: ML-DSA signatures across application flows; ML-KEM in API-to-API channels.
• L2B — Internal critical tooling. CI/CD signing pipelines, internal PKI, secrets stores. Failure ripples through everything signed or trusted by these systems. Expected hardening: ML-DSA across application layer; SLH-DSA for code-signing chains.
• L2C — Customer-critical channels. Net banking, mobile banking, payment APIs, customer authentication flows. Failure is customer-visible and regulator-visible. Expected hardening: hybrid PQC TLS at the edge; ML-DSA in customer signing flows.
• L3 — Enterprise critical. Core banking, KYC stores, HSMs, fraud-detection backbones. Failure threatens the bank's operating licence. Expected hardening: ML-DSA and SLH-DSA in combination; ML-KEM across all internal mTLS; audit trail for every key operation.
• L4 — National critical. RTGS, NEFT, central-bank links, settlement-rail integrations. Failure threatens systemic stability. Expected hardening: highest tier, including air-gap modes, hash-based signature chains, and full crypto-agility instrumentation.

Descriptive, not a scoring system

The framework defines tiers; it does not define a verdict. The distinction matters because a CISO who reads "L1 to L4" and thinks this asset got an L3, that asset got an L2 is reading something that isn't there.

What the framework actually says is: systems of type X belong in tier Y. Whether a specific bank's specific L3 system meets the expected L3 hardening is a separate question. The framework gives a vocabulary for that question; it doesn't answer it.

This matters for reporting in particular. Aligned reporting means producing deliverables that are organised by tier — so a regulator reading the report can see, at a glance, which tiers are migrated and which remain. It does not mean emitting an L1/L2/L3/L4 label per asset. The first is structurally useful; the second is structurally noisy.

How a useful tier-aligned report is shaped

A migration-progress report aligned to the DST framework looks like:

• Tier inventory. Per tier: how many systems live there, what classes of cryptography they use, what their PQC-readiness baseline is.
• Tier progress. Per tier: percentage of systems migrated, percentage in progress, percentage not yet started. Diffable quarter-over-quarter.
• Tier exceptions. Per tier: systems that cannot meet the expected hardening this quarter, why, and the compensating control or sunset plan.
• Tier roadmap. Per tier: the next 12 months of planned work, the dependencies (HSM procurement, vendor commitments, PKI rotations), the budget required.

That structure works for board reporting, for regulator reporting, and for cross-organisation conversations with sector peers. Asset-level verdicts work for none of those — they're the wrong granularity for the audience.

What to do this quarter

If the framework is new for your team:

1. Classify your top 30 systems by tier. Don't try to classify everything immediately. Pick the operationally critical 30 and decide each tier. The boundaries will be obvious in some cases and contested in others; the contested cases are the ones to socialise.
2. Define the hardening baseline per tier. What algorithm choices, what key management practices, what observability — for each of the six tiers. Write it down. Get it reviewed.
3. Shape one tier-aligned report. Even if migration hasn't started, a baseline report shows the organisation that the framework is in use and produces a meaningful starting position for the next quarter's diff.

The framework is most valuable as a piece of communication infrastructure. The hardening it asks for is the same hardening any responsible PQC migration would do; the value is being able to describe progress in a vocabulary the regulator and the auditor and the board all share.