Five Quantum Questions Every Bank CISO Should Ask

Encryption & Key Management , Governance & Risk Management , Next-Generation Technologies & Secure Development Five Quantum Questions Every Bank CISO Should Ask Quantum Deadlines Loom. Most Banks Can't Say Where Their Cryptography Is Deployed Uma Ramani • June 24, 2026     Get Permission Image: Freepik In December 2024, Google's Willow chip achieved below-threshold quantum error correction using 105 superconducting qubits, demonstrating for the first time that error rates decrease exponentially as qubit count increases. This resolved one of the field's most persistent doubts: Scaling qubits would only multiply errors. It did not. See Also: Beat the Breach: Outsmart Attackers and Secure the Cloud In fewer than 12 months through early 2026, three research papers sharply reduced the estimated quantum resources needed to break the cryptographic systems protecting the global digital economy. What once required an estimated 20 million qubits now requires fewer than one million for RSA, and potentially fewer than 100,000 for newer architectures. Google has moved up its internal timeline for migrating to quantum-resistant encryption - a signal that 2035 may be too late to begin. The Regulatory Road Map to Quantum Readiness In August 2024, the National Institute of Standards and Technology finalized its three post-quantum cryptography standards after an eight-year evaluation process: ML-KEM for key encapsulation, ML-DSA for digital signatures and SLH-DSA as a hash-based fallback. NIST's deprecation timeline calls for quantum-vulnerable algorithms to be deprecated after 2030 and disallowed after 2035. RSA-2048 and ECDSA with P-256 are explicitly in scope. In October 2024, CERT-In released Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM Version 2.0, covering cryptographic elements, quantum readiness and artificial intelligence systems. For Indian BFSI organizations, a cryptographic bill of materials is moving from an optional best practice toward an expected security capability. The standards are written. The clock is running. The Practitioner's Problem Most banks today cannot answer the most basic question regulators are beginning to ask: Where is cryptography actually deployed across your environment? Not approximately - precisely. Which applications run RSA? Which systems rely on elliptic-curve cryptography? Which certificates expire, on what systems, under which trust chains? Which third-party software carries cryptographic dependencies you have never inventoried? The honest answer, in most institutions, is that people don't fully know. That's the real quantum problem today. Not the hardware. It's the visibility gap. Question 1: Do We Have a Cryptographic Inventory? Most banks maintain asset inventories. Many are now building a software bill of materials, but few have mapped where cryptography actually lives. This is what a CBOM is designed to address. A CBOM documents the cryptographic algorithms, libraries, protocols, certificates and key management practices embedded across systems and applications. At a minimum, a CBOM captures cryptographic libraries and modules in use, algorithms and modes, protocol versions, key metadata including rotation policy, and certificate trust anchors with expiry information. CERT-In has issued the framework. The expectation is documented, but the execution gap is wide. You can't migrate what can't be seen. And you can't defend what's never been mapped. Question 2: Which Data Needs Protection Beyond the Quantum Horizon? This question matters because of a specific attack model the security community refers to as "harvest now, decrypt later." Adversaries with sufficient motivation don't need quantum capability today. They collect encrypted data now, archive it and wait. When quantum capability eventually arrives, that archived data becomes readable. For a bank, consider the lifespan of what is encrypted today: Know Your Customer records, credit histories, litigation files, strategic communications and correspondent banking data. Some of that information will still be sensitive in 2035. Some of it will still matter in 2040. The question isn't whether the data is secure today. The question is whether it will remain secure across its full confidentiality horizon. Institutions that have never asked that question should start now. Question 3: How Crypto Agile Are We? This is the hardest question and the most important one. Crypto agility is not about which algorithm we use. It is about whether the architecture allows swapping algorithms without having to rebuild everything around them. Most legacy banking systems weren't built with cryptographic flexibility in mind. Cryptography is embedded deep inside applications, middleware, network infrastructure and vendor-supplied platforms. Replacing it often requires significant redesign - not a configuration change. Organizations that invest in crypto agility now will navigate the post-quantum transition with manageable effort. The ones who wait will face it as an emergency. Question 4: Are Our Vendors and Partners Preparing? Early real-world deployment data shows the direction of travel: AWS has integrated ML-KEM into its Key Management Service, and Microsoft includes post-quantum options in Windows 11 and Azure. Cloud providers may be moving, but the payment processors, switch vendors and core banking platform providers are less certain about migration. A quantum-ready bank inside a quantum-vulnerable ecosystem is still exposed. Third-party risk assessments need to include the question: What is your post-quantum cryptography road map, and where are you on it? Question 5: Do We Have a Transition Road Map? Below is a staggered approach and the only realistic path: Organizations must know what they have by mapping cryptographic dependencies across their own systems and third-party applications; Prioritize by classifying data according to its confidentiality lifespan and identifying which systems carry the highest exposure under a harvest now, decrypt later scenario; Build readiness by embedding crypto agility into new systems, opening vendor dialogue, and monitoring NIST standards adoption and CERT-In guidance evolution; Begin migration by transitioning high-priority systems to post-quantum standards and testing interoperability, rather than waiting for urgency to force compression. This journey will take years. That is precisely why it needs to start now. The Boardroom Conversation Boards are increasingly asking about AI risk and cyber resilience. Quantum will join that list. When it does, the CISO who has visibility into cryptographic exposure, a mapped inventory and a transition plan will be in a better position than the one encountering the question for the first time. The greatest quantum risk isn't that cryptography will suddenly fail. It's that when the regulator or the board asks about post-quantum exposure, the answer is silence. The standards are written. The guidelines are issued. The question of whether institutions are building the capability to comply remains open.