The May 2026 NQM Task Force report on India's Quantum-Safe Ecosystem — chaired by Dr. Rajkumar Upadhyay (CEO, C-DOT), with RBI, SEBI, ICICI Bank, CERT-In, IIT Madras and DSCI at the table — formalised an acronym every Indian bank board now needs to know. Not HNDL. That one is old news.
TNFL — Trust Now, Forge Later. The DST framing is summarised on India's PQC roadmap; this post unpacks the mechanic, the exposure inventory, and the December 2027 deliverable the report binds BFSI to.
HNDL — harvest-now, decrypt-later — threatens confidentiality. An adversary records your encrypted traffic today and decrypts it the year a cryptographically-relevant quantum computer (CRQC) arrives. The fix is well understood: encrypt forward today with hybrid PQC for anything with a long secrecy lifetime.
TNFL threatens integrity. An adversary archives your signing certificate today, derives the private key when a CRQC arrives, and then forges signatures the system still treats as authentic. The audit trail will say your bank signed it. The signature will validate. There is no retrospective fix.
The two attacks share an enabling technology (Shor's algorithm on a CRQC) but they hit different security properties and have very different operational tails. HNDL exposure stops growing the day you migrate. TNFL exposure compounds with every long-lived signature you continue to mint on RSA-2048 or ECDSA.
The mechanic, in three frames
This is the part most people miss on the first reading. The attacker doesn't need to capture your transactions. They need one thing — your public signing certificate. And that's already public by design.
Today — archive the certificate
Every CA-issued signing certificate in BFSI is published. UPI signing certificates. Aadhaar e-KYC certificates. GST e-invoice DSCs. SWIFT BIC-linked PKI. Their public keys are the whole point — they let counterparties verify your signatures. An adversary harvests them with a script. RSA-2048. Done.
Q-Day — Shor's derives the private key
When a CRQC of sufficient size exists — mainstream estimates put this anywhere between late this decade and the mid-2030s, with the NQM report citing 2030–2032 as the planning window — Shor's algorithm derives the private key from the public key. This is not "hacking" in the conventional sense. It is mathematics on enough qubits. The cost of the attack drops from infeasible to tractable overnight.
The day after — forged signatures, backdated
With the private key in hand, the adversary can sign anything the original signer was ever authorised to sign. A payment instruction. A KYC response. A SWIFT MT103. A GST e-invoice. A digitally-signed contract. The forgery is producible in 2031 and dated 2026 if needed. Signed by a key the system still trusts, because nobody has revoked it — and even revocation does not help: the forged document predates any revocation date.
This is the asymmetry that makes TNFL nasty:
Every signature you mint today with quantum-vulnerable cryptography, on an artefact that has to remain trustworthy past Q-Day, is a TNFL liability you are accruing now and cannot recall later.
Where TNFL exposure lives in Indian BFSI
The figure above maps the systems the NQM Task Force inventory flagged. Read the third column — retention — first. Anything where the signed artefact has to remain authoritative for years to decades is a TNFL surface today:
- UPI signing certificates. RSA-2048, ~7–10 year retention on the underlying transaction records. Every UPI rail message is a candidate TNFL target.
- Aadhaar e-KYC signatures. RSA-2048, decade-plus retention on the KYC artefacts banks rely on for AML/CFT defensibility.
- GST e-invoice DSC chain. RSA-2048, ~8 year retention under Income-Tax Act audit windows.
- NEFT / RTGS message authentication. RSA-2048, ~10 year retention for settlement reconciliation.
- Income-Tax & MCA DSCs. RSA-2048, 7+ year retention.
- SWIFT MT message signing. RSA-2048, 7–10 year retention under correspondent-banking obligations.
- Mobile banking certificate pinning. RSA / ECDSA, 1–3 year retention but daily reissuance volume.
Compare to the two systems on the inventory that are not TNFL surfaces — internet-banking TLS and ATM PIN-block DUKPT. Both terminate inside a session. Once the session ends there is no artefact left to forge. They are HNDL surfaces (the session traffic is recordable) but not TNFL surfaces (there is no long-lived signed artefact). The two threat models are not interchangeable, and the distinction matters when you sequence the migration.
The TNFL surface inside an Indian universal bank is large, RSA-2048-dominated, and deeply integrated into rails the bank does not own — UPI, NPCI, GSTN, Aadhaar, SWIFT. Migration is not unilateral.
Why this is harder than HNDL
HNDL has a clean exit door: encrypt-forward today, the past stays past. TNFL does not. Three reasons:
- The artefacts are persistent, not ephemeral. A TLS session ends. A signed payment instruction sits in your audit trail for a decade. Whichever signature is on it at issue time is the signature it has forever — unless you re-sign every historical artefact under PQC at some future cut-over, which is operationally implausible.
- The trust graph is shared. UPI, NPCI, GSTN, UIDAI and SWIFT all sit upstream of your signing posture. Your bank cannot move alone. Migration is a coordinated activity across the entire BFSI rail, with regulators and rail operators setting the cut-over.
- The fix is dual-signature, not algorithm-swap. A signature mints once and lives forever. Replacing RSA-2048 with ML-DSA on day N protects everything signed on day N+1. Everything signed on day N-1 remains forgeable on Q-Day. The only mitigation for the historical estate is counter-signing under PQC — a second, PQ signature attached to the document — which most signing infrastructures do not yet support natively. This is a multi-year change-management problem, not a config flip.
The December 2027 reality check
The Task Force binds BFSI's first concrete deliverable to 31 December 2027: a complete Cryptographic Bill of Materials — every key, every certificate, every algorithm, every library, in every system the bank operates. The CBOM is the prerequisite, not the migration itself. You cannot migrate what you cannot see.
Nineteen months from today.
What does that timeline look like in practice? In a mid-sized PSU bank, cryptographic discovery — the inventory work alone — typically takes 12 to 14 months. The systems are heterogeneous, the documentation is partial, and the certificates are spread across vendors who have not been asked the question before. Migration of the highest-value TNFL surfaces (UPI, Aadhaar, GST, SWIFT) follows a longer tail, gated by NPCI, UIDAI, GSTN and SWIFT respectively.
The honest reading: there is no scenario where Indian BFSI is on track against the December 2027 milestone unless inventory work is in flight by the end of this quarter.
What to do this quarter
The first three moves are inexpensive and useful even if your view of Q-Day shifts later:
- Inventory the long-lived signing surfaces first. Forget data-in-motion for a moment. Pull the list of every CA-issued signing certificate in production, its algorithm, its expiry, its issuing CA, and the retention window of the artefacts it signs. Sort descending by retention. The top of that list is your TNFL exposure.
- Inventory the upstream dependencies. For each long-retention signing surface, identify the external rail operator (NPCI, UIDAI, GSTN, SWIFT, CCA, IDRBT). Your migration will be gated by theirs. Knowing the dependency chain now lets you participate in the operator's consultations rather than react after.
- Write PQC into procurement language. Every signing-infrastructure renewal — HSMs, signing services, document- management platforms, CA contracts — should now carry a PQC-capability clause. The cost of inserting the clause today is zero. The cost of swapping a vendor in 2028 because the platform does not support ML-DSA is not.
These are not the migration. They are the prerequisites to having a migration plan worth presenting at the December 2027 milestone. The CBOM is the deliverable. Inventory is what produces it.
Where this leaves you
HNDL was the easier story to tell, and the right story to start with — a cleanly bounded threat with a cleanly bounded fix. TNFL is the harder story and the one most BFSI conversations are not yet having. The NQM Task Force report changes that: TNFL is now in the official vocabulary, the December 2027 deliverable is named, and the question of whether the Indian financial system is on track has an answer that does not depend on optimism.
That is the gap KavachQ is being built to close — turning the DST framework into a sequenced, inventoried, audit-ready migration plan against the actual cryptographic estate of an Indian bank. The standards exist. The deadline is on the calendar. The plan still has to be written, per bank, against its real signing surfaces.