Many banking systems rely on public-key cryptography to establish trust, exchange keys and create digital signatures. A sufficiently capable quantum computer could undermine widely used public-key methods, so preparation focuses on finding those dependencies and moving them to tested post-quantum standards before the risk becomes immediate.
The risk is concentrated in particular cryptographic functions
Quantum computing does not make every security control or encryption method obsolete in the same way. The principal migration concern is public-key cryptography used for key establishment and digital signatures in protocols, certificates, applications, devices and software dependencies.
The timing of a cryptographically relevant quantum computer is uncertain, but some information must remain confidential for many years. An attacker could collect protected data now and attempt to decrypt it later, which makes data lifetime and exposure important inputs even before a practical quantum attack exists.
A cryptographic inventory reveals hidden dependencies
The bank identifies where public-key algorithms appear across internet services, internal networks, APIs, identity systems, code signing, payment connections, certificates, hardware security modules, embedded devices, backups and vendor products. The inventory records owners, versions, data protected and the protocols or libraries that implement the cryptography.
Discovery cannot stop at systems the bank operates directly. Cloud services, software packages, telecommunications, payment processors and other providers may manage cryptographic components the bank cannot see or replace without a coordinated product change.
Prioritization combines data life, criticality and change difficulty
Teams assess how long information needs protection, how essential the service is, whether a failure would affect authentication or transaction integrity and how long the platform takes to change. Long-lived confidential data and hard-to-replace critical infrastructure can require earlier planning than short-lived, isolated information.
The result is a migration sequence rather than one universal deadline. Certificate renewal cycles, protocol support, hardware replacement, partner readiness and regulatory or contractual obligations shape the order while risk owners document any period in which a dependency cannot yet move.
Standardized algorithms still require implementation testing
NIST has finalized initial post-quantum cryptography standards, but adopting a named algorithm is not the same as completing a safe migration. Implementations must fit protocols, key and signature sizes, performance requirements, certificate chains, devices and operational monitoring without introducing incompatible or untested custom cryptography.
Controlled tests examine interoperability, capacity, failure handling, rollback, logging and the ability to rotate keys and certificates. Hybrid approaches may combine classical and post-quantum methods during transition when supported, but their complexity, standards alignment and failure behavior still need explicit review.
Crypto-agility and governance keep the transition manageable
Crypto-agility means the bank can identify and replace cryptographic components without rebuilding every dependent service from the beginning. Modular interfaces, accurate asset records, supported configurations and practiced certificate and key changes make future transitions more controlled.
A multi-year program assigns accountable owners, integrates provider roadmaps with third-party oversight and subjects releases to security review, change control and resilience testing. Progress measures track discovery coverage, migration readiness and verified replacement rather than claiming that an entire institution became quantum-safe through one product purchase.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.