A bank preparing for post-quantum cryptography could begin by examining its internet-facing certificates, only to discover that the more difficult work lies inside systems that rarely appear in conventional cybersecurity assessments. Cryptographic algorithms are embedded in payment applications, database connections, hardware security modules, authentication services, network equipment and software libraries supplied by third-party vendors. Some are centrally managed, while others are buried in applications developed years ago or incorporated into products whose internal security architecture is largely invisible to the bank. This creates a fundamental challenge for financial institutions planning to replace cryptographic mechanisms that could become vulnerable to future quantum computers: before they can upgrade their encryption and digital signatures, they need to establish where those mechanisms are used, what depends on them and whether they can be changed without disrupting banking operations.
The First Challenge Is Finding the Cryptography
Most large banks maintain inventories of their servers, applications, databases, network equipment and technology suppliers. These records help security and infrastructure teams understand what the organisation operates, who is responsible for individual systems and which services depend on particular technology components. However, a conventional IT asset inventory does not necessarily reveal the cryptographic algorithms used within those systems, the software libraries implementing them or the relationships between encryption mechanisms and critical business processes.
Consider a payment application that communicates with several internal services before submitting a transaction to an external network. Encryption may protect the initial connection, while digital certificates authenticate the participating systems and separate cryptographic mechanisms protect messages or verify their integrity. The application may also rely on a hardware security module to safeguard keys or perform cryptographic operations. Although the bank may know which servers host the application and which vendor supplied the software, its existing records may not identify every algorithm involved or the components that would need modification during a cryptographic migration.
The difficulty increases when systems have been developed or upgraded over many years. Different teams may have selected cryptographic libraries independently, older applications may depend on algorithms no longer recommended for new implementations, and vendor products may conceal their internal cryptographic dependencies. A bank could therefore have a reasonably accurate view of its technology estate while lacking the detailed information required to determine how exposed that estate is to changes in cryptographic standards.
This is why cryptographic discovery is becoming an important part of post-quantum preparation. The objective is not simply to produce a list of certificates or encryption products. It is to establish which cryptographic mechanisms protect particular information, identities and transactions, and to understand the operational consequences of replacing them.
Quantum Computing Is Turning an Inventory Gap into a Migration Problem
The urgency surrounding cryptographic inventories is closely connected to developments in quantum computing. Many widely deployed public-key cryptographic systems rely on mathematical problems that are considered difficult for conventional computers to solve. A sufficiently capable fault-tolerant quantum computer could undermine important algorithms based on integer factorisation or discrete logarithms, including RSA and commonly used elliptic-curve cryptographic schemes.
This does not mean that today’s banking encryption has already become obsolete or that all cryptographic algorithms face the same quantum threat. Symmetric encryption, such as AES, is affected differently from public-key cryptography and can generally be strengthened through appropriate algorithm and key-size choices. The most significant migration challenge concerns quantum-vulnerable public-key mechanisms used for establishing secure communications, authenticating systems and verifying digital signatures.
In August 2024, the US National Institute of Standards and Technology finalised its first three principal post-quantum cryptography standards. These include ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. The standards provide a technical foundation for organisations preparing to replace vulnerable public-key algorithms, but publishing new standards does not automatically make existing banking systems compatible with them.
A bank may need to update cryptographic libraries, security appliances, application protocols, certificate infrastructure and vendor products before a particular service can support new algorithms. Some systems may require software changes, while others could depend on hardware replacements or broader architectural modifications. Identifying these dependencies early is essential because the complexity of the migration will vary considerably between applications.
The threat also involves information that needs to remain confidential for many years. Attackers could capture certain encrypted communications today and retain them in the hope of decrypting them using more capable quantum computers in the future. This scenario, commonly described as harvest now, decrypt later, creates an additional reason to examine how long sensitive information must remain protected and which cryptographic mechanisms safeguard it.
Why a Certificate Inventory Is Not Enough
Banks commonly use certificate management platforms to monitor digital certificates, identify approaching expiration dates and reduce the risk of outages caused by expired credentials. These systems can provide useful information about certificate issuers, validity periods, public-key algorithms and the services associated with particular certificates. However, certificate discovery represents only one part of the wider cryptographic environment.
A certificate may identify the public-key algorithm used for authentication without revealing every cryptographic mechanism employed during a communication session. Similarly, an application may use cryptography internally without exposing a certificate that can be discovered through conventional network scanning. Encryption may be implemented within application code, embedded software components, database drivers or proprietary vendor platforms. Some cryptographic operations take place entirely within hardware security modules or specialised payment security environments.
A comprehensive cryptographic inventory therefore needs to capture more than the existence of certificates. It should identify the algorithms and protocols in use, the software or hardware implementing them, their purpose, the systems that depend on them and the information or transactions they protect. It should also distinguish between cryptography used for confidentiality, authentication, digital signatures, key exchange and other security functions, because the migration requirements are not identical.
For example, replacing an algorithm used to establish a secure network connection may involve updating communication protocols and ensuring that both endpoints support compatible mechanisms. Replacing a digital signature algorithm may affect certificate authorities, signature verification systems, archived records and external counterparties that rely on the existing signature format. The underlying business application might remain unchanged in one scenario but require substantial modification in another.
This distinction is particularly relevant in banking, where cryptographic mechanisms frequently operate across organisational boundaries. An institution cannot necessarily change a security protocol independently if the receiving system, payment network or technology partner does not support the replacement.
The Cryptography Hidden Inside Banking Infrastructure
The challenge becomes clearer when examining the range of systems that may contain cryptographic dependencies. Internet banking platforms and mobile applications use cryptography to establish secure sessions and authenticate services. Internal APIs rely on transport security and, in some cases, additional message-level protection. Databases may use encryption for stored information and communications between applications. Identity systems use cryptographic mechanisms to validate credentials, issue tokens and establish trusted relationships between services.
Payment infrastructure introduces further complexity. Banks use cryptography across payment gateways, transaction messaging, security appliances, hardware security modules and connections to payment networks. Different parts of these environments may rely on distinct algorithms and protocols, some of which are governed by industry standards or implemented through specialised products. Cryptographic functions associated with payment cards and PIN processing also require careful distinction from the public-key algorithms most directly affected by quantum computing. Not every cryptographic mechanism requires the same migration response.
Legacy banking applications present another category of difficulty. A core banking platform or related integration service may depend on an older operating system, a specific cryptographic library or a vendor-controlled software component. Even where the application itself remains operationally reliable, replacing its underlying cryptography may not be straightforward. The bank may need to establish whether the vendor intends to provide a compatible upgrade, whether the existing product can support newer algorithms or whether the migration will require changes to surrounding infrastructure.
These dependencies can extend beyond the bank’s immediate technology environment. Outsourced processing platforms, managed security services, telecommunications providers and software-as-a-service applications may all perform cryptographic operations on behalf of the institution. A bank’s own inventory may therefore need to be supplemented with information obtained from suppliers, particularly where the relevant algorithms cannot be observed directly.
How Cryptographic Discovery Actually Works
Building a useful cryptographic inventory requires several complementary discovery techniques because no single method can reliably identify every cryptographic mechanism across a large banking environment. Network analysis can help identify protocols, negotiated algorithms and certificate information associated with observable communications. Endpoint and server scanning can reveal installed cryptographic libraries, configurations and certificates. Software analysis can identify dependencies on cryptographic packages and, where source code is available, locate calls to cryptographic functions.
Software bills of materials can also contribute to the process by identifying components and libraries included within applications. However, knowing that a particular library is present does not always establish which cryptographic functions are actually used, how they are configured or whether an application can support alternative algorithms. Runtime observations and configuration analysis may therefore be necessary to distinguish between potential dependencies and active cryptographic operations.
Hardware security modules require additional attention because they may perform sensitive cryptographic functions through controlled interfaces that do not expose the underlying key material. Discovery in these environments may involve reviewing device configurations, supported algorithms, firmware versions, key attributes and application integrations. The objective is to understand the cryptographic capabilities and dependencies without weakening the protections that make these systems valuable.
A practical inventory also needs to associate technical findings with business services. Identifying a vulnerable algorithm in an isolated development environment is different from finding the same dependency in infrastructure supporting high-value payments or customer authentication. Banks therefore need to connect cryptographic discovery results with application ownership, business criticality, information sensitivity and technology lifecycle information.
This turns the inventory into a risk-management tool rather than a purely technical register. It allows institutions to prioritise migration activities based on the consequences of compromise, the difficulty of replacement and the operational importance of affected systems.
The Problem of Cryptography Embedded in Third-Party Software
One of the largest obstacles to comprehensive discovery is the extent to which banks depend on technology they do not develop or maintain themselves. Core banking platforms, payment processing applications, treasury systems, fraud detection products and security appliances frequently incorporate proprietary software components. Banks may have contractual rights to use and configure these products without having visibility into every cryptographic implementation inside them.
This creates a dependency on suppliers for accurate information about algorithms, libraries, supported protocols and future upgrade plans. A vendor may need to modify its product before a bank can adopt post-quantum cryptography, and the timing of that modification may depend on product development priorities, hardware compatibility and changes to industry standards. Even when an upgrade becomes available, the bank may need to test it extensively to ensure that the product continues to interact correctly with other systems.
The issue becomes more complicated when several vendors participate in the same business process. A bank may be able to upgrade one component while another remains dependent on an older protocol. In some cases, both parties must support compatible cryptographic mechanisms before a new configuration can be activated. This means migration schedules may be determined by the least adaptable component rather than the readiness of the institution’s primary systems.
As a result, banks may need to make cryptographic transparency a more explicit part of technology procurement and supplier management. Questions about supported algorithms, upgrade paths, cryptographic libraries and the ability to replace security mechanisms could become important alongside conventional assessments of product functionality, performance and resilience.
Cryptographic Agility Could Be More Valuable Than a One-Time Upgrade
An important concept emerging from post-quantum migration planning is cryptographic agility: the ability to change cryptographic algorithms and related mechanisms without requiring extensive redesign of the systems that depend on them. In an agile architecture, cryptographic functions are implemented through controlled interfaces or configurable components rather than being tightly embedded throughout application code.
This does not mean algorithms can always be replaced through a simple configuration change. Different cryptographic schemes can have different key sizes, signature sizes, performance characteristics and protocol requirements. Applications and connected systems must still support the replacement. Nevertheless, reducing unnecessary dependencies on specific algorithms can make future transitions more manageable.
For banks, cryptographic agility is particularly relevant because post-quantum migration may not be the final major change in cryptographic standards. Security requirements evolve as vulnerabilities are discovered, computing capabilities advance and new protocols become available. Institutions that design systems around replaceable cryptographic components may be better positioned to respond to future changes without repeatedly undertaking expensive application redevelopment.
The same principle applies to vendor selection. A banking software product that supports algorithm updates through a maintained cryptographic abstraction layer may be easier to adapt than one whose security functions are embedded in proprietary code that cannot be modified independently. Over time, the ability to demonstrate cryptographic agility could become a differentiating capability for banking technology providers.
Financial Sector Testing Shows Why Migration Is More Than an Algorithm Change
The Bank for International Settlements has already explored some of the operational challenges associated with introducing post-quantum cryptography into financial infrastructure. In December 2025, the BIS Innovation Hub published findings from the second phase of Project Leap, conducted with central banks and industry participants including Swift. The experiment tested the use of post-quantum digital signatures within an operational payment system environment, requiring changes across multiple components to support updated cryptographic libraries.
The work demonstrated that migration involves more than replacing one algorithm with another. Systems must remain interoperable, performance must be assessed and the surrounding infrastructure must support the new cryptographic mechanisms. The project identified performance differences between conventional and post-quantum algorithms, reinforcing the need for testing under realistic operational conditions.
This is particularly important for payment systems, where transaction processing, message validation and settlement operations must meet demanding reliability and performance requirements. Changes to signature formats or cryptographic processing can affect message sizes, verification workloads and integration behaviour. A technically secure algorithm may still require substantial engineering work before it can be introduced safely into a production financial environment.
The findings support a broader conclusion: the earlier banks understand their cryptographic dependencies, the more time they have to assess compatibility, coordinate with counterparties and avoid disruptive last-minute changes.
The Migration Timelines Are Already Taking Shape
The UK’s National Cyber Security Centre has established a phased timeline for organisations preparing to migrate to post-quantum cryptography. Its guidance sets 2028 as the target for completing discovery and assessment activities and developing an initial migration plan, 2031 for completing the highest-priority migration activities and refining the roadmap, and 2035 for completing the transition across systems, services and products.
These are UK guidance milestones rather than universal deadlines imposed on every bank globally. Nevertheless, they illustrate the scale of the work involved. The NCSC expects large organisations to require approximately two to three years for discovery, assessment and initial planning alone. For banks operating complex technology estates, this suggests that cryptographic inventory work cannot reasonably be postponed until every product and protocol has completed its transition to post-quantum standards.
NIST has also made cryptographic visibility and risk management a central workstream of its migration programme through the National Cybersecurity Center of Excellence. The initiative is examining approaches to building and maintaining cryptographic inventories, alongside interoperability and benchmarking activities intended to support adoption of post-quantum technologies.
Together, these efforts signal a shift in the industry’s approach. The immediate task for many organisations is not to replace every algorithm at once, but to establish enough visibility to make informed decisions about which systems need attention, which changes are technically feasible and where supplier dependencies could delay progress.
A New Market for Cryptographic Visibility Tools
The inventory challenge is creating opportunities for cybersecurity vendors, infrastructure providers and enterprise software companies. Traditional certificate management and vulnerability scanning tools can provide useful information, but banks may increasingly require platforms capable of correlating cryptographic findings across applications, networks, software components and hardware environments.
A mature cryptographic visibility platform would ideally identify algorithms and protocols, associate them with particular systems, assess their relevance to quantum-related risks and track remediation progress. It would also need to accommodate information from supplier assessments and software component inventories, particularly where direct technical discovery is limited. Integration with configuration management databases, asset management platforms and technology risk systems could help banks connect cryptographic findings with business ownership and operational priorities.
However, automated discovery should not be mistaken for complete visibility. Encrypted traffic may conceal details, proprietary software may limit inspection and dormant cryptographic functions may not appear during runtime monitoring. Some tools can identify the presence of vulnerable libraries without determining whether the affected functions are actually used. Banks will therefore need processes for validating findings, documenting uncertainty and obtaining information from system owners and vendors.
The commercial opportunity extends beyond discovery software. Technology providers may offer cryptographic migration assessments, application remediation, hardware upgrades, protocol modernisation and testing services. Banking software vendors will also face pressure to demonstrate how their products can support new standards without creating unacceptable disruption for financial institutions.
The Inventory Must Become a Living Record
A cryptographic inventory assembled as a one-time project can quickly become outdated. Banks continuously introduce new applications, deploy software updates, replace certificates, connect additional APIs and modify infrastructure. Each change can introduce new cryptographic dependencies or alter existing ones. A discovery exercise completed today may therefore provide an incomplete picture within months unless the institution establishes a process for keeping the information current.
This suggests that cryptographic visibility should eventually become part of routine technology governance. New applications could be required to document their cryptographic dependencies during development and procurement, while software updates could trigger reassessment of relevant algorithms and libraries. Infrastructure monitoring and certificate management systems could supply ongoing information, with exceptions investigated when discovered configurations differ from approved standards.
The resulting inventory would support more than post-quantum migration. It could help institutions identify obsolete cryptographic mechanisms, reduce certificate-related outages, improve incident investigations and assess exposure when vulnerabilities are discovered in widely used security libraries. It could also provide clearer evidence for internal risk reviews and discussions with regulators about the protection of critical systems.
For banks, the longer-term value may lie in establishing cryptographic visibility as a permanent capability rather than treating it as a temporary compliance exercise.
The Real Risk Is Discovering Dependencies Too Late
Post-quantum cryptography is often discussed as a future cybersecurity challenge, but the engineering work required to prepare for it is already relevant. New standards provide a direction for replacing vulnerable public-key mechanisms, while research and industry testing are helping establish how those mechanisms can operate in real financial environments. The unresolved difficulty for many organisations is understanding the scale of the systems that will need to change.
A bank that discovers an outdated algorithm in a replaceable software library may be able to address the issue through a controlled upgrade. Discovering the same dependency in a critical legacy application, specialised hardware device or externally operated payment service could require years of coordination, testing and investment. The difference is not simply the severity of the cryptographic weakness, but the institution’s ability to identify and manage the dependency before it becomes urgent.
This makes the cryptographic inventory problem more than a technical preparation exercise for quantum computing. It exposes a wider weakness in how complex organisations understand the security mechanisms embedded throughout their technology estates. Banks may know which applications they operate and which suppliers they depend on, yet still lack visibility into the cryptographic foundations supporting their most important services.
The institutions best positioned for post-quantum migration will not necessarily be those that adopt new algorithms first. They will be those that can identify where cryptography is used, determine which dependencies matter, coordinate changes across suppliers and upgrade critical systems without compromising operational stability.
What this means for the industry
- Cryptographic discovery is becoming a strategic banking technology requirement. Institutions need visibility into the algorithms, protocols, libraries and hardware mechanisms protecting critical applications and information.
- Traditional asset and certificate inventories may be insufficient. Banks must connect cryptographic findings with software dependencies, business services and third-party technology arrangements.
- Post-quantum migration will require coordination across the financial ecosystem. Payment networks, software vendors, infrastructure providers and financial institutions may need compatible upgrades before new cryptographic mechanisms can be deployed.
- Cryptographic agility could become an important software capability. Banking technology providers that make algorithms easier to replace may reduce future migration complexity for their clients.
- Supplier transparency will matter more. Banks may increasingly require vendors to disclose cryptographic dependencies, supported standards and realistic upgrade plans.
- Discovery tools represent an emerging cybersecurity opportunity. Platforms that combine cryptographic scanning, dependency mapping, risk assessment and migration tracking could become valuable components of banking security infrastructure.
- The greatest migration risk may be poor visibility rather than delayed adoption. Discovering a critical cryptographic dependency late in the transition could leave banks with limited options and expensive remediation requirements.
