The inequality, from Mosca's 2015 framing and refined every year since in the Global Risk Institute's PQC survey:
X + Y > Z ⇒ you are already late
Three variables. Each one has a defensible number for an Indian bank. The sum tells you whether your current plan is adequate.
X — the secrecy lifetime of what you encrypt today
How long does data being encrypted right now have to remain confidential? This is the variable most CISOs underestimate because they default to "operational" secrecy lifetimes (days to weeks) when the regulated answer is "regulatory" lifetimes (years to decades).
For Indian BFSI, defensible X numbers by data class:
- KYC, biometrics, Aadhaar references: decades. Some classes never declassify.
- Banking transaction history: 10–15 years, driven by tax record-keeping and dispute resolution windows.
- Internal risk models, treasury strategies: 5–10 years.
- Pricing engines, marketing analytics: 1–3 years.
- Session tokens, ephemeral keys: hours.
Use the maximum X across the data classes you actually protect. For a universal bank, that's "decades".
Y — how long your migration will take
From the moment a PQC programme starts to the moment the last legacy primitive is decommissioned. Defensible Y numbers for an Indian universal bank:
- Cryptographic discovery + edge TLS: 6–12 months. The fast bits — CBOM plus hybrid TLS at the perimeter.
- HSM migration: 6–9 months per fleet, and often parallel-stalled by procurement (see the HSM problem).
- Internal PKI rotation: 12–24 months. The algorithm change is fast; re-issuing every certificate the old root ever signed is what takes the quarters (see PKI rotation).
- Application crypto refactoring: depends entirely on how much crypto-agility the codebase already has. For a bank with hard-coded RSA everywhere, this is the longest single line item.
A realistic full-stack Y for a mid-tier Indian universal bank is 3–5 years. Larger and more regulated estates lean toward 5+.
Z — time to a cryptographically relevant quantum computer
The most contested variable. The Global Risk Institute's 2023 survey of cryptographers reported a median consensus placing roughly a 1-in-7 chance of CRQC arrival within five years (i.e. by 2028), and roughly a 1-in-2 chance within fifteen (by 2038). These are subjective expert estimates, not physical predictions; they have widened and narrowed over the survey's history.
The pragmatic planning posture is to use Z = 8–10 years as a working assumption. It is well within the spread of expert opinion, it is consistent with what NSA and BSI and NCSC plan against, and it makes the inequality bite for any data class with a decade-plus secrecy lifetime.
Filling in the inequality
For a typical Indian universal bank protecting customer PII and KYC:
- X (max secrecy lifetime): decades. Call it 20 years to be conservative.
- Y (migration time): 3–5 years.
- Z (CRQC arrival): planning at 8–10 years.
X + Y = 23–25 years. Z = 8–10 years. The inequality is satisfied with a wide margin. You are already late for that data class — meaning some data encrypted today is at risk no matter how fast you migrate.
That isn't a counsel of despair. It's the framing that decides the migration order. The data classes where X + Y > Z most strongly are the ones that go first. Session tokens and operational logs (where X is small) go last. The ranking that falls out of the inequality is the same ranking the secrecy-lifetime analysis in the HNDL piece produces.
What this tells you to do
Three things:
- Compute X per data class. The CISO who can name X for the top ten data classes in their bank has already done more rigorous quantum risk planning than 90% of peers.
- Tighten Y where the inequality bites. For the forever-secret classes, accelerate the migration path. For the short-lived classes, opportunistic timing is fine.
- Stop arguing about Z. Z is structurally unknowable. The right posture is to plan for Z conservatively and revisit the assumption every year as the field updates.