What the Regulatory Context Actually Requires
The Reserve Bank of India has issued guidance on cyber resilience for financial institutions that increasingly references quantum computing as an emerging threat to cryptographic infrastructure. The SEBI cybersecurity framework, updated in 2023, added provisions requiring regulated entities to assess and address emerging threats to encryption systems. Neither document mandates a specific timeline for post-quantum migration, but both create a compliance expectation that institutions have assessed the risk and have a documented migration plan.
This matters because "regulatory compliance" and "actual quantum-safe posture" are different goals with different timelines. A bank that produces a migration assessment document satisfies the near-term regulatory expectation. A bank that has deployed quantum-safe key establishment on its highest-risk data paths has addressed the actual threat. Most institutions currently need to be working on both simultaneously, because the procurement and audit cycles for the first require different inputs than the engineering work for the second.
We are not interpreting these regulatory instruments as requiring immediate QKD deployment. We are observing that the documentation requirement creates an organizational forcing function that is useful for security teams trying to get budget allocation for quantum migration infrastructure. That is a different argument than pure technical necessity, but it is a real one in most institutional environments.
The Specific Exposure Surface for Banks
Before mapping a migration path, it helps to be specific about what is actually exposed. Indian banks running core banking system communications face quantum vulnerability in several distinct places.
Interbank settlement communication travels over networks using TLS or dedicated encrypted protocols. The key establishment in those protocols, typically ECDH-based, is the primary harvest-now exposure surface. A mid-size private bank settling transactions on the National Electronic Funds Transfer (NEFT) network or Real-Time Gross Settlement (RTGS) infrastructure is transmitting transaction data that may carry confidentiality obligations extending several years beyond the transaction date. That data is vulnerable to the harvest-now pattern if captured today and decrypted after quantum computers mature.
Core banking system internal communications, particularly between branches and central processing infrastructure, often run over site-to-site VPN connections using IPSec. The IKE key exchange in IPSec is RSA or ECDH based and carries the same exposure. The fix here is not different in principle, but the vendor landscape for core banking system network encryption is more constrained than the general enterprise IT market, with fewer vendors and longer certification cycles for cryptographic updates.
Customer authentication channels, particularly mobile and internet banking TLS sessions, are a third category. The confidentiality requirement here is shorter (session data rather than transaction records), but the volume is high and the surface is continuously exposed. Browser and mobile app TLS stacks are generally updated on faster cycles than enterprise network equipment, which means this is often the first place migration becomes technically feasible.
A Practical Migration Sequence
Based on the realistic timelines for different migration components, a practical migration sequence for an Indian private or regional bank looks roughly as follows.
In the 0 to 6 month horizon: conduct the cryptographic inventory. Map every place in the network where RSA and ECDH key material is established. This includes obvious places like public-facing web certificates and VPN peer keys, but also less obvious places like the keys used for HSM communication, the key material in database encryption systems, and the application-layer encryption in payment processing modules. Build the inventory before making migration decisions; the inventory will reveal constraints you do not currently know about.
In the 6 to 18 month horizon: migrate the highest-volume, most-accessible encryption surfaces to hybrid key exchange. Browser-facing TLS is the easiest target because the major TLS libraries (OpenSSL, BoringSSL) already support ML-KEM in hybrid mode, and certificate authorities can issue RSA or EC certificates alongside the hybrid key exchange without requiring immediate certificate migration. This addresses the most voluminous harvest-now exposure surface while the harder migration tracks run in parallel.
In the 18 to 36 month horizon: migrate network encryption appliances as vendor firmware becomes available, deploy post-quantum key management infrastructure to support eventual QKD integration, and complete the certificate authority migration planning. This is the period where the longest-lead items in the migration will typically bottleneck: core banking system vendor updates, HSM firmware updates, and regulatory documentation.
Where QKD Fits in the Banking Migration
Software post-quantum cryptography, specifically ML-KEM key exchange and ML-DSA signatures, is a necessary and near-term deployment for most of the exposure surfaces described above. QKD addresses a different requirement: the highest-assurance key establishment for the highest-risk data paths.
For an Indian bank, that means the interbank settlement communication tier. A QKD key delivery infrastructure that serves the primary data center and the disaster recovery site provides information-theoretically secure key material for the encrypted channels between those sites. Any data encrypted with a QKD-distributed session key is not vulnerable to harvest-now attacks: the key was never transmitted through a channel that an adversary could intercept and store.
The practical entry point for banks is a pilot deployment covering two to three physical locations within a single metropolitan area. This is a contained scope that produces measurable data on integration complexity, operational overhead, and actual key delivery reliability before the institution commits to broader deployment. Our Bengaluru pilot demonstrated sub-2ms key delivery at city scale across four ground stations, which is within the latency tolerance of interbank settlement communication.
Procurement and Vendor Assessment for Indian Banks
The procurement environment for quantum-safe networking in India is still forming. A few practical observations from working with banking security teams on deployment planning.
Most core banking system vendors, including international and domestic providers, are at varying stages of quantum-safe roadmap development. Some have announced ML-KEM support timelines. Others are more opaque. The right question for vendor assessments is not "do you support post-quantum cryptography" (most will say yes) but "which specific releases support FIPS 203 / ML-KEM for key exchange, and what is the support lifecycle for legacy RSA key exchange on the versions we run today?"
For HSM vendors specifically: physical key management devices have longer firmware update cycles than software, and the cryptographic module validation process means that new algorithm support requires re-certification. Ask about the validation timeline for ML-KEM support in your current HSM models, because that timeline will determine whether your key management infrastructure can support the migration on the schedule your other systems require.
The risk of over-investing in migration tooling before the vendor ecosystem catches up is real. Building cryptographic agility infrastructure is the right priority: it allows you to slot in new algorithm sources as vendor support arrives, rather than trying to migrate all systems simultaneously when the vendor updates do eventually appear.
