Quantum readiness starts before migration.
Most conversations about post-quantum cryptography jump straight to the algorithm question – which standard to adopt, when to switch, what the new certificates should look like. For a bank, that question comes too early. Before any institution can replace RSA or ECC with something quantum-resistant, it has to answer a harder question first: where does that cryptography actually live across the organization, and who else’s infrastructure does it depend on?
Shor’s Algorithm is the reason this work has a deadline at all – it gives a sufficiently capable quantum computer a path through the mathematics RSA and ECC rely on. But understanding the threat and organizing a response to it are two different projects. This article is about the second one: how a bank builds and executes a practical roadmap toward quantum readiness, rather than treating PQC migration as a single algorithm swap.
A typical financial institution’s cryptographic footprint is larger than most security teams assume, spread across core banking systems, customer-facing applications, vendor integrations, cloud infrastructure, and archives that predate the current security team entirely. Readiness means having visibility into all of it before deciding what to replace and in what order.
What Does Quantum Readiness Mean for a Bank?
Quantum readiness is not a single milestone – it’s an operational state. A bank is quantum-ready to the degree that it knows where quantum-vulnerable cryptography exists in its environment, understands what data and systems each instance protects, has identified which assets carry the greatest urgency, has mapped which vendors and third parties introduce dependencies outside its direct control, has sequenced a migration plan around that information, and has built the ability to keep updating its cryptography as standards continue to evolve.
Notice what’s absent from that list: it doesn’t require having already migrated to a post-quantum algorithm. An institution that has completed a thorough cryptographic inventory and built a realistic, funded roadmap is meaningfully more quantum-ready than one that has migrated a handful of systems without ever mapping the rest of its environment. Readiness is a function of visibility and planning before it’s a function of algorithms deployed.
Why Banks Need a Structured PQC Roadmap
The instinct to treat this as an algorithm-replacement project is understandable, but financial-sector guidance emphasizes that migration is more complex than a simple algorithm replacement. RSA and ECC aren’t confined to one system that can be patched in isolation. They’re embedded in TLS configurations across customer-facing and internal applications, in certificate chains issued by internal and external certificate authorities, in the key management systems and hardware security modules that generate and protect keys, in API authentication between the bank and its payment processors, in the cloud and managed-service platforms running parts of the infrastructure, in backup and archival systems that may not have been touched in years, and in the vendor relationships that support core banking, lending, and compliance functions.
Each of those is a different owner, a different upgrade cycle, and in many cases a different organization entirely. Post-quantum cryptography for financial institutions covers what this exposure looks like specifically in a banking context. A roadmap exists to sequence this work deliberately – because without one, migration tends to happen system by system, driven by whichever team notices the issue first, with no coordinated view of what’s actually been covered and what hasn’t.
Step 1 – Discover Your Cryptographic Exposure
Discovery is the starting point, and it needs to be more thorough than most teams initially expect. It means locating every instance of RSA and ECC across TLS configurations, certificates and PKI infrastructure, VPN tunnels, API authentication, application-level cryptographic calls – including ones hard-coded years ago by developers no longer at the company – embedded systems and IoT-adjacent infrastructure, code-signing processes, and key management systems.
The instances that get missed can be outside the obvious systems. A bank’s primary online banking platform is usually well understood and actively maintained. The exposure tends to hide in the systems nobody has opened recently: a batch settlement tool built a decade ago, a legacy VPN configuration inherited through an acquisition, a certificate embedded in firmware on a branch device. Cryptographic discovery covers the methodology for finding these systematically rather than relying on institutional memory. This step produces the raw material everything else depends on – you cannot inventory, prioritize, or migrate what you haven’t found.
Step 2 – Build a Cryptographic Inventory
Discovery finds cryptographic assets. Inventory is the discipline of documenting and maintaining a record of what was found, so the information doesn’t decay the moment the discovery project ends.
A useful inventory tracks, at minimum: the algorithm and key size in use, the certificate and its issuing authority, the protocol it supports, the application or system it belongs to, the business function it serves, the data it protects, the business owner responsible for it, any vendor dependency involved, its criticality to operations, and its current migration status.
This is where many quantum-vulnerable algorithms get identified for the first time – not just RSA and ECC in obvious places, but older key sizes, deprecated protocol versions, and cryptographic configurations set once during initial deployment and never revisited. An inventory that isn’t maintained becomes outdated within months as systems change, new vendors are onboarded, and applications are updated. Treat it as a living record, not a one-time deliverable.
Step 3 – Identify Which Data and Systems Need Protection First
Not every cryptographic asset carries equal urgency, and the temptation to migrate alphabetically or by whichever system is easiest is worth resisting. Prioritization should be driven by how long the data behind each system needs to stay confidential, how sensitive it is, how critical the system is to daily operations, how exposed it currently is, and how complex migrating it will actually be.
Customer records, KYC documentation, transaction histories, regulatory filings, legal records, and archived communications tend to carry the longest confidentiality requirements – often years or decades – which makes them a natural starting point for prioritization regardless of how technically straightforward or difficult their migration turns out to be. Harvest Now, Decrypt Later (HNDL) explains why data with long confidentiality windows carries urgency independent of when quantum decryption capability actually arrives – the exposure window on long-lived data opens the moment it’s collected, not the moment it’s decrypted.
Backups and archives deserve particular attention here. They’re frequently overlooked in migration planning because they aren’t part of daily operations, but they often hold the institution’s longest-lived and most sensitive data under its oldest cryptographic configurations.
Step 4 – Map the Bank’s Third-Party Cryptographic Dependencies
This is where a bank’s actual exposure tends to exceed its internal inventory, because a meaningful share of the cryptography protecting its data isn’t under its direct control.
Vendors and Managed Services
Core banking platforms, lending systems, and compliance tools are frequently run or hosted by third parties, each maintaining its own certificate infrastructure and cryptographic configuration on the bank’s behalf.
APIs and Payment Processors
Every API connection to a payment processor, credit bureau, or fintech partner represents a key-exchange point the bank doesn’t directly configure. Its own migration timeline is only as fast as the slowest counterpart on the other end of that connection.
Cloud Infrastructure
Cloud environments introduce cryptography through configurations that may be set by a cloud provider’s defaults rather than a decision the bank’s security team explicitly reviewed.
File Transfer and Data Exchange
Batch file-transfer systems used for settlement, reporting, and interbank data exchange often run on protocol versions and cryptographic configurations set up years earlier and rarely revisited.
Certificates and External Trust Relationshipsv
Certificate authorities and the trust chains they issue are themselves a dependency. A bank’s own migration doesn’t complete the picture if the CAs and partners it trusts haven’t moved to quantum-resistant signatures.
Backups and Archives
Third-party backup and archival services may retain years of sensitive data under cryptographic standards the vendor controls, not the bank.
A bank can complete a flawless internal inventory and still hit a hard blocker in execution if its critical vendors haven’t started their own PQC planning. Vendor readiness needs to be assessed as its own workstream, not assumed as a byproduct of the bank’s internal effort.
Step 5 – Assess and Prioritize Quantum Risk
Once discovery and dependency mapping are complete, the question shifts from what exists to what needs attention first. A practical assessment weighs data sensitivity, data longevity, the degree of cryptographic vulnerability involved, business criticality, the extent of external dependencies, migration complexity, and vendor readiness.
This doesn’t need to produce an artificial numerical risk score to be useful. What it needs to produce is a defensible ranking – the systems and data sets that combine high sensitivity, long confidentiality requirements, and significant exposure should move to the front of the queue, ahead of systems that are technically vulnerable but low-consequence if migration takes longer.
Step 6 – Build a Phased PQC Migration Roadmap
This is where the previous steps come together into an executable plan, organized across eight phases.
Phase 1 – Discovery
Locate every instance of quantum-vulnerable cryptography across the environment. Output: a comprehensive map of where RSA, ECC, and related algorithms are actually deployed.
Phase 2 – Inventory
Document each discovered asset in a structured, maintained record. Output: a living cryptographic inventory tied to system owners and business functions.
Phase 3 – Risk Assessment
Evaluate what each asset protects and how exposed it is. Output: a risk profile for each cryptographic asset or system grouping.
Phase 4 – Prioritization
Rank assets by sensitivity, longevity, criticality, and complexity. Output: a sequenced priority list that drives everything downstream.
Phase 5 – Planning and Architecture
Design the target-state architecture, including hybrid approaches that run classical and post-quantum algorithms in parallel during transition. Output: a migration architecture and timeline for each priority tier.
Phase 6 – Testing and Pilot Deployment
Validate interoperability, performance, and compatibility on a limited set of systems before wider rollout. Output: a tested, validated approach ready for production scale.
Phase 7 – Production Migration
Execute the migration across prioritized systems, coordinating with vendors and dependent parties as needed. Output: systems running quantum-resistant cryptography in production.
Phase 8 – Continuous Cryptographic Monitoring
Maintain visibility into the cryptographic environment as new systems, vendors, and standards emerge. Output: an ongoing monitoring function, not a closed project.
Skipping ahead to Phase 5 or 6 without the groundwork in Phases 1 through 4 is the most common reason migration projects lose momentum – they run into a system or dependency nobody had mapped.
Where NIST PQC Standards Fit Into the Roadmap
In August 2024, NIST finalized its first three post-quantum cryptography standards. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism for establishing shared secrets over a public channel; it is a key part of the transition away from quantum-vulnerable public-key mechanisms such as RSA and ECDH in relevant key-establishment scenarios. FIPS 204 specifies ML-DSA, a lattice-based digital signature standard intended to replace RSA and ECDSA. FIPS 205 specifies SLH-DSA, a hash-based signature scheme offering a conservative alternative built on a different set of mathematical assumptions than the lattice-based options.
These standards give the roadmap a defined technical target at the algorithm level. What they don’t do is replace the discovery, inventory, assessment, testing, and vendor-coordination work described above. A bank can be fully aligned with NIST’s published standards and still be unprepared for migration if it hasn’t done the organizational work to know where those standards need to be applied.
It’s also worth being precise about what these standards represent. FIPS are Federal Information Processing Standards used by U.S. federal agencies and do not automatically create a binding legal requirement for every private-sector financial institution. They nevertheless provide an important technical reference point for the broader transition. NIST PQC guidance covers how federal direction and examiner expectations are shaping this space, and how that differs from an explicit regulatory mandate.
Why Crypto-Agility Must Be Part of Bank Quantum Readiness
Treating PQC migration as a single, finite project – replace RSA, deploy ML-KEM, close the ticket – sets an institution up to repeat the same disruption the next time cryptographic standards change. Crypto-agility is the alternative: building systems, key management processes, and certificate infrastructure so that algorithms, keys, and certificates can be updated without re-architecting the underlying applications each time.
FS-ISAC has highlighted crypto-agility as a core component of financial-sector quantum readiness precisely because standards in this space are still maturing. NIST’s current standards are a strong foundation, not necessarily a permanent endpoint. An institution that builds crypto-agility into its architecture now reduces the cost and disruption of every future cryptographic transition, not just this one.
How Banks Can Measure PQC Readiness
A few direct questions indicate where an institution actually stands:
Do you know where quantum-vulnerable cryptography exists across your environment? Is there a maintained cryptographic inventory, or does the information live in individual teams’ heads? Have critical data assets and systems been prioritized by sensitivity and longevity? Have third-party and vendor dependencies been mapped and assessed for their own readiness? Is there a board-approved or leadership-approved migration roadmap with phases and timelines? Have pilot systems been identified for early testing? Has interoperability between legacy and post-quantum systems been validated? Is crypto-agility a stated architectural requirement, or an afterthought?
An institution answering “no” to most of these is still in the discovery stage, regardless of how much it has read about NIST’s standards. That’s a normal starting point – it’s simply the honest one.
What Financial Institutions Should Do Now
The sequence holds regardless of an institution’s size or current maturity: discover, inventory, assess, prioritize, plan, test, migrate, and maintain crypto-agility. None of these steps require a cryptographically relevant quantum computer to exist first – they require an accurate picture of the institution’s own cryptographic environment, which is work that can start immediately.
Post-quantum cryptography services for banks supports institutions through this sequence, from initial discovery through migration planning and execution. The work is substantial, but it’s structured – and an institution that has genuinely completed the early phases is in a fundamentally stronger position than one still deciding which algorithm to adopt first.
—
Frequently Asked Questions
Que.1 What is quantum readiness for banks?
Quantum readiness means a bank knows where quantum-vulnerable cryptography exists in its environment, understands what it protects, has prioritized its migration, mapped its third-party dependencies, and built the capacity to keep updating its cryptography as standards evolve. It does not require migration to already be complete.
Que.2 What is a PQC roadmap?
A PQC roadmap is a phased plan sequencing an institution’s transition to post-quantum cryptography – typically covering discovery, inventory, risk assessment, prioritization, architecture planning, testing, production migration, and ongoing crypto-agility.
Que.3 Why do banks need a cryptographic inventory?
A cryptographic inventory documents where algorithms, certificates, and keys are deployed and what they protect. Without it, migration decisions are made without visibility into the full scope of what needs to change, increasing the risk of missed systems and vendor blind spots.
Que.4 What should a bank do first for PQC migration?
Cryptographic discovery – identifying where RSA, ECC, and other quantum-vulnerable mechanisms are actually deployed across applications, infrastructure, and third-party systems – comes before any algorithm selection or replacement decision.
Que.5 Which NIST PQC standards should banks know?
FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a hash-based signature alternative. NIST finalized all three in August 2024.
Que.6 How should banks prioritize systems for PQC migration?
By weighing data sensitivity, how long that data needs to stay confidential, business criticality, degree of exposure, and migration complexity – not by convenience or the order systems happen to be discovered.
Que.7 Do third-party vendors affect a bank’s PQC readiness?
Yes. A significant share of a bank’s cryptographic exposure runs through vendors, APIs, cloud providers, and payment processors it doesn’t directly control. A bank’s migration can be blocked by a critical vendor’s readiness even after its own internal work is complete.
Que.8 Why is crypto-agility important for financial institutions?
Crypto-agility allows a bank to update algorithms, keys, and certificates without rebuilding the systems around them, reducing the cost and disruption of future cryptographic transitions as standards continue to evolve beyond the current NIST specifications.