If you've read one piece on post-quantum cryptography, you've probably read that NIST published ML-KEM (Kyber) and that everyone should "migrate to PQC". Both true, both useless if you're the CISO of an Indian bank trying to write the migration plan. The standards are a menu, not a single switch. This post is the field guide I wish existed when we started building KavachQ.
The five standards, in one paragraph each
FIPS 203 — ML-KEM (formerly Kyber)
A key encapsulation mechanism. It does the job RSA-OAEP and ECDH do today: agreeing on a symmetric key between two parties who don't share a secret. This is the standard you'll deploy first because it's where the bulk of your exposure lives — every TLS handshake, every internal mTLS connection, every VPN tunnel. ML-KEM is lattice-based and has three parameter sets (512, 768, 1024); 768 is the pragmatic default for BFSI workloads.
FIPS 204 — ML-DSA (formerly Dilithium)
A general-purpose digital signature scheme. Replaces RSA-PSS, RSA-SSA, and ECDSA across most use cases — JWT signing, mutual auth tokens, X.509 leaf certificates. Also lattice-based. Signatures are larger than ECDSA (≈3.3 KB for ML-DSA-65 vs 64 bytes for P-256), which matters when you measure bytes-on-the-wire at bank-scale.
FIPS 205 — SLH-DSA (formerly SPHINCS+)
A hash-based signature scheme. Slower and bigger than ML-DSA (signatures range from 8 KB to 50 KB depending on parameters), but its security depends only on the properties of a hash function — no lattice assumptions, no number theory. That makes it the conservative fallback for things you can't afford to revisit: firmware signing on POS terminals, code-signing for software you'll deploy for ten years, root certificates with twenty-year validity.
FIPS 206 — FN-DSA (formerly FALCON)
A second lattice signature scheme, still in draft as of 2026 (NIST is standardising it as FIPS 206). Smaller signatures than ML-DSA (≈660 bytes for FN-DSA-512) at the cost of more complex implementation — it uses floating-point arithmetic, which makes constant-time implementation hard and makes some HSM vendors nervous. Reach for FN-DSA when signature size dominates your design (TLS chains, IoT firmware, anything where you ship every byte down a constrained link).
HQC — the code-based backup KEM
NIST selected HQC in 2025 as a second KEM for standardisation, to sit alongside ML-KEM. The reasoning is diversification: ML-KEM is lattice-based, HQC is code-based, and a future cryptanalytic break against one family wouldn't compromise the other. HQC's keys and ciphertexts are larger than ML-KEM's, so the operational default remains ML-KEM. Think of HQC the way you think of a backup data centre: budget for it, plan failover, hope you never need it.
Why two KEMs and three signature schemes?
This is the single most useful framing to take into a board conversation. NIST is not being indecisive. It is deliberately hedging: lattice-based schemes (ML-KEM, ML-DSA, FN-DSA), hash-based (SLH-DSA), code-based (HQC). If one mathematical foundation turns out to have a flaw — and the history of cryptanalysis is long enough that this is not paranoid — the others still hold. For a CISO, this is the same logic as multi-vendor sourcing for ATM hardware. The portfolio survives any one component failing.
What changes in your stack
Here is where the abstract becomes operational. For a typical Indian universal bank, the cryptographic estate breaks into five domains. Each gets a different recommendation.
TLS termination (the top exposure)
The single largest concentration of asymmetric cryptography in any bank is at the perimeter — load balancers terminating TLS for customer-facing channels and B2B APIs. The migration path here is hybrid: pair classical X25519 with ML-KEM-768 in the same handshake. If either holds against a future attacker, the channel is safe. Chrome shipped X25519MLKEM768 as the default in 2024–2025. Cloudflare, AWS, and the major CDN/load-balancer vendors followed. For an Indian bank, the question is whether your edge stack (F5, Citrix ADC, A10, NetScaler) is on a firmware version that supports hybrid PQC. Most have rolled this out in the last 12 months. Check.
Internal PKI and code signing
Your internal CA, the one issuing certificates for service-to-service mTLS and developer code-signing, needs to migrate to ML-DSA. SLH-DSA for the root and the long-lived intermediates; ML-DSA for the shorter-lived leaves. The painful part is not the algorithm change — it's the re-issuance of every certificate the old root ever signed. Inventory of cert holders inside a bank is rarely current, and rotating the trust anchor is a several-quarter project.
Document signing, Aadhaar e-Sign, IT Act signatures
This is the domain where Indian banks have to wait. The Controller of Certifying Authorities will publish guidance on which PQC signature schemes are admissible for IT Act §3A purposes. Until that lands, the right posture is: pilot internally with ML-DSA, design flows so the signature algorithm is configurable (crypto-agility at the application layer), and stay close to CCA consultations.
HSMs
Most HSMs from Thales, Utimaco, Entrust, and AWS CloudHSM shipped PQC firmware in 2024–2025. Older HSMs are not upgradeable — they are end-of-life and need to be replaced. For an Indian bank, HSM procurement is a 6-month cycle in good conditions because of import duties and, for regulated environments, STQC evaluation. Start that conversation now if you haven't.
Database and archive encryption
The symmetric layer (AES-256) is unchanged — Grover's algorithm gives only a quadratic speed-up and AES-256 remains comfortably safe. What changes is the KEM that wraps the data key. If your database encryption uses an RSA-wrapped AES key (a common pattern in legacy enterprise databases), the wrapping operation needs to migrate to ML-KEM. The encrypted data itself does not need to be re-encrypted.
The migration order for an Indian bank
Six steps, in the order that minimises wasted effort:
- Inventory first. Before anything else, cryptographic discovery: what algorithms are in use, where, by which workload, signed by which key, terminated at which device. Most banks discover they have 200+ TLS endpoints, dozens of internal CAs, and HSMs they had forgotten existed. Without inventory, every later step is guesswork.
- External-facing TLS. Roll hybrid X25519+ML-KEM at the edge. If your load-balancer firmware supports it, this is configuration; if not, it's a firmware upgrade. Either way it's the lowest-friction first step and removes your largest single exposure.
- Internal PKI. Stand up an ML-DSA-based CA in parallel with the existing one. Migrate workloads, re-issue leaves, decommission the legacy CA last.
- High-assurance signing chains. SLH-DSA for code signing, firmware signing, and any artefact that will live longer than five years.
- Document signing. Pilot in parallel. Wait for CCA guidance before going to production.
- Legacy workloads. Things that genuinely cannot move (vendor lock-in, embedded systems, batch jobs that cost more to migrate than to retire) get protected with envelope encryption using PQ KEMs at the boundary. Document the residual risk. Plan retirement.
What "DST-aligned reporting" actually means
The DST National Quantum Mission Task Force published a phased framework for India's PQC migration. Reports are framed against L1 / L2A,B,C / L3 / L4 assurance levels — categories that describe the criticality of a system and the depth of cryptographic hardening expected at each tier.
For BFSI specifically: core banking sits in the L3–L4 range; customer-facing channels in L2; internal collaboration tooling in L1. Aligned reporting means producing discovery and migration deliverables that map cleanly onto these categories so a regulator reading the report can see, at a glance, which tiers are migrated and which remain. It is descriptive, not a per-asset verdict — the framework is a structure for reporting, not a scoring system.
Three things most CISOs underestimate
- HSM lead times. If you need replacements, six months is fast. Plan accordingly.
- Internal PKI re-issuance. Once you migrate the root, every certificate it ever signed must be re-issued. The inventory of those certificates is rarely current.
- Vendor pressure as the cheapest lever. Most enterprise software vendors will not ship PQC-capable updates until customers ask for them in writing. Putting PQC into the procurement and renewal language for every contract is the single highest-leverage thing a CISO can do in 2026. It costs nothing and makes the entire ecosystem move faster.
Where this leaves you
The mathematical work is done. NIST has shipped the standards. Library support (BoringSSL, OpenSSL 3.4+, AWS-LC, BouncyCastle) is in place. The migration that remains is operational, not cryptographic — and that is where most plans stall. The constraints that matter for Indian BFSI are, in roughly this order: HSM replacement budgets, internal PKI hygiene, CCA's document-signing guidance, and vendor responsiveness. None of those are math problems.
That is the gap KavachQ is being built to close — turning the published standards into a sequenced, inventoried, audit-ready migration plan aligned to the NQM Task Force framework. The standards exist. The plan still has to be written, per bank, against its actual estate.