Banks run on trust, and trust runs on cryptography. Every wire transfer, mortgage application, ATM transaction, and customer login depends on math that quantum computers will eventually break. The Federal Financial Institutions Examination Council (FFIEC) expects banks to manage cryptographic risk like any other operational risk, and the National Institute of Standards and Technology (NIST) has published the standards that make a quantum-resistant migration possible. The work is not optional, and it cannot wait until quantum computers actually arrive. Adversaries are already storing encrypted bank traffic to decrypt later, a strategy known as harvest now, decrypt later.
This playbook walks through the migration process the way a regional or national bank should approach it: inventory first, prioritize by exposure, pilot with hybrid encryption, then scale across the institution. It pulls directly from FFIEC guidance, NIST IR 8547, and the Cybersecurity Assessment Tool that examiners actually use during reviews.
Why Banking Cannot Delay Post-Quantum Migration
Banking data has unusually long sensitivity windows. A loan application contains thirty years of financial history. A wealth management client file may be relevant for the lifetime of a family trust. Even routine transaction logs are subject to retention rules that span seven to ten years under Sarbanes-Oxley and Bank Secrecy Act requirements. The Office of the Comptroller of the Currency (OCC) treats long-term confidentiality of customer information as a fundamental safety and soundness issue.
The threat is not theoretical. Researchers from Google Quantum AI, IBM Quantum, and academic labs have demonstrated steady scaling of logical qubit counts. NIST's own analysis assumes a cryptographically relevant quantum computer (CRQC) could appear within the migration window, which is why NIST IR 8547 sets aggressive deprecation deadlines for RSA, ECDSA, and Diffie-Hellman key exchange. Banks that wait to begin migration will find themselves doing rushed, expensive work under examiner pressure, exactly the conditions in which mistakes happen.
For deeper background on why this matters, see What Is Post-Quantum Cryptography and Why RSA-2048 Will Break.
The FFIEC Cybersecurity Assessment Framework
FFIEC's Cybersecurity Assessment Tool (CAT) gives examiners a structured way to score a bank's maturity across five domains: cyber risk management, threat intelligence, cybersecurity controls, external dependency management, and cyber incident management. Cryptographic agility falls into the controls domain, but post-quantum migration touches all five. A complete migration plan demonstrates risk management discipline, surfaces vendor exposure, and proves the bank can respond to cryptographic incidents without operational disruption.
Banks should map their PQC migration milestones directly to the CAT maturity levels. Baseline maturity means the bank has identified where cryptography is used. Evolving maturity adds documented policies for cryptographic standards. Intermediate maturity introduces algorithm agility, the ability to swap algorithms without rewriting applications. Advanced and innovative maturity reach the point where hybrid post-quantum is in production for high-value flows. Examiners will increasingly ask where the bank sits on this curve.
Step One: Cryptographic Inventory
You cannot migrate what you cannot see. The first phase of any banking PQC effort is a complete inventory of every place cryptography is used. This sounds simple and is not. Cryptography hides in TLS terminators, payment switch HSMs, ACH gateways, SWIFT connectivity, mainframe channels, mobile banking SDKs, third-party fintech APIs, customer email gateways, and dozens of internal microservices.
NIST IR 8547 recommends that organizations build a Cryptographic Bill of Materials (CBOM) similar to the software bill of materials popularized by executive order 14028. For each asset the inventory should record: algorithm and key size, library and version, certificate authority chain, expiration date, owner, business function, data sensitivity classification, and current quantum vulnerability status. Vendors should be required to populate the CBOM for every product they sell into the bank.
A useful starting set for a retail bank includes core banking platforms, card processing networks, ATM connections, online and mobile banking, fraud detection pipelines, identity and access management systems, and the dozens of regulatory reporting feeds that flow to FinCEN, OCC, FDIC, and the Federal Reserve. Commercial banks add SWIFT messaging, treasury services, syndicated loan platforms, and trade finance channels, all of which carry data that adversaries would happily harvest.
Step Two: Prioritize by Exposure Window
Not every system needs to migrate first. The right prioritization combines two factors: the sensitivity lifetime of the data and the cost of replacement. Customer credit applications, wealth management records, and high net worth client communications have multi-decade sensitivity. ATM session keys are ephemeral and can be migrated last. A simple matrix sorts every system in the inventory into four quadrants: high sensitivity and easy to replace gets migrated first, high sensitivity and hard to replace becomes the longest project, low sensitivity and easy to replace fills opportunistic upgrade windows, and low sensitivity and hard to replace can wait until natural refresh cycles.
The exposure window calculation is the variable that quantum makes painful. If your data must remain confidential for twenty years and you believe a CRQC may exist in fifteen, the cryptographic window is already negative. Anything encrypted today with classical RSA or ECDH that an adversary can capture will be readable inside the sensitivity lifetime. This is the core of the harvest now, decrypt later threat model.
Step Three: Hybrid Encryption Pilot
NIST recommends hybrid post-quantum deployments during the migration window. Hybrid encryption combines a classical algorithm like X25519 or ECDH with a post-quantum algorithm like ML-KEM. Both must fail for the channel to be broken, which means the deployment is at least as strong as classical encryption while gaining post-quantum protection. Hybrid is also the only way to deploy PQC inside compliance regimes that have not yet certified pure PQC stacks.
Pilots should target a high-value, narrow flow. Good candidates include the wealth management portal, the corporate treasury platform, the SWIFT gateway, or the executive communications channel. The pilot validates that key sizes work inside existing TLS infrastructure, that HSM partners support hybrid key generation, that latency stays inside SLA, and that monitoring and incident response teams know what hybrid certificates and handshakes look like. For more detail on how hybrid is built, see Hybrid Encryption.
Step Four: Key Management System Migration
The biggest single architectural decision in a banking PQC migration is the KMS strategy. Most banks use a centralized HSM fleet from Thales, Entrust, Utimaco, or AWS CloudHSM. PQC support varies. Some platforms ship ML-KEM and ML-DSA in firmware updates today. Others require a hardware refresh. The KMS migration plan should identify which HSMs are PQC-capable, which are upgradeable, which need replacement, and what the procurement timeline looks like.
Key sizes matter operationally. ML-KEM-768 ciphertexts are about 1,088 bytes versus 32 bytes for X25519. ML-DSA-65 signatures are 3,309 bytes versus 64 bytes for Ed25519. Storage, bandwidth, and HSM throughput all need to be sized for the new realities. Banks running thousands of TPS across payment switches need to model PQC overhead carefully and plan capacity accordingly. Performance is acceptable on modern hardware, but it is not free.
Step Five: Vendor and Third-Party Risk
Most banking technology is bought, not built. The OCC, FDIC, and Federal Reserve all expect banks to extend cryptographic risk management to third parties. Every vendor contract should be reviewed for PQC roadmap commitments. Critical vendors include core banking platforms (FIS, Fiserv, Jack Henry), payment processors (TSYS, FIS, Worldpay), fraud platforms (Feedzai, NICE Actimize, SAS), and the CRM and document management systems where customer data lives.
The bank's vendor risk management program should add a quantum cryptography rider to every renewal. The rider should require a CBOM, a published PQC migration roadmap, evidence of NIST FIPS 203 / 204 / 205 conformance plans, and contractual commitments around cryptographic agility. Smaller fintech vendors may not yet have answers; that is exactly the conversation the bank needs to start now, while there is time to find alternatives if needed.
Step Six: Documentation and Examiner Readiness
FFIEC examiners will want to see written policy, evidence of execution, and forward-looking plans. The PQC migration playbook should live as a board-approved policy document, with quarterly progress reports to the Risk and Audit committees. NIST IR 8547 and NIST SP 800-208 (for stateful hash-based signatures, where applicable) should be cited in the policy. The CBOM should be inspectable, the prioritization matrix should be defensible, and the pilot results should be documented with metrics.
A common examiner question is whether the bank has performed cryptographic agility testing. This means demonstrating that the bank can switch from one algorithm to another in production without code changes, ideally via configuration or a key rotation event. Banks that built this capability for the SHA-1 to SHA-256 migration are well-positioned. Those that did SHA-1 deprecation through code changes have homework to do.
The board's role in cryptographic risk oversight is increasingly explicit. The 2023 SEC cybersecurity disclosure rule for public companies requires material cybersecurity incidents to be disclosed in 8-K filings within four business days, and annual 10-K filings must describe the company's cybersecurity risk management approach. For publicly traded banks, the PQC migration program is part of that disclosure conversation. Boards should be asking management about quantum readiness in the same cadence as they ask about other forward-looking risks like climate, geopolitics, and AI.
For broader regulatory context, see PQC for Financial Services and the NIST FIPS Guide.
Step Seven: Operational Runbooks and Incident Response
Cryptographic migration creates new failure modes. A misconfigured hybrid TLS handshake produces a different error than a classical TLS failure. A PQC certificate that exceeds the size limit on a legacy network appliance fails in ways that look like network problems rather than cryptographic problems. Operations teams need updated runbooks before PQC reaches production, not afterward.
The runbook updates should address several categories. First, monitoring: SIEM rules need to recognize PQC handshake events, and dashboards need to surface PQC-specific metrics like ML-KEM ciphertext expansion ratio and ML-DSA signing latency. Second, incident classification: a TLS handshake failure on a hybrid endpoint may be a classical-side issue, a PQC-side issue, or a hybrid composition issue. The triage tree should distinguish them. Third, rollback procedures: if a PQC deployment causes a production incident, the rollback path back to classical TLS should be tested and time-budgeted.
Tabletop exercises help. A reasonable cadence is one PQC tabletop per quarter for the first year of deployment, then twice per year as operations stabilize. The tabletop scenarios should include a PQC library CVE disclosure, a CMVP validation revocation, an unexpected interoperability failure with a major counterparty, and a quantum cryptography breakthrough announcement that requires expedited migration. Each tabletop produces action items that feed back into runbook revisions and procurement priorities.
The audit trail produced by these exercises is itself useful evidence. FFIEC examiners and internal auditors expect to see that the bank can respond to cryptographic incidents the same way it responds to other operational incidents. Documentation of tabletop exercises, runbook revisions, and lessons learned demonstrates that the cryptographic risk management program is operationalized rather than just documented.
Frequently Asked Questions
When should a bank start its PQC migration?
Now. NIST IR 8547 recommends that organizations begin inventory and pilot work immediately. Even if cryptographically relevant quantum computers are a decade away, the harvest-now-decrypt-later threat means data being captured today is already at risk. Examiners will increasingly expect to see a documented program.
What is the FFIEC's official position on quantum cryptography?
FFIEC has not issued a dedicated quantum guidance document yet, but cryptographic risk falls under the existing IT Examination Handbook on Information Security. Examiners can and do cite NIST publications during reviews. CISA and NIST's joint quantum readiness factsheet has been distributed widely to financial regulators.
Can a bank just wait for vendors to ship PQC?
Partial yes, mostly no. Vendors will deliver PQC in their products, but the bank still owns risk classification, prioritization, key management, and vendor oversight. Sitting and waiting violates the spirit of the FFIEC's risk management expectations.
How disruptive will PQC be to existing TLS infrastructure?
For most modern TLS 1.3 deployments, hybrid post-quantum support is already available in OpenSSL, BoringSSL, and major load balancers. Older TLS 1.2 systems and embedded devices may need replacement. The biggest disruptions tend to be in HSMs, certificate management, and any custom protocol that hardcodes RSA or ECDSA.
Do banks need to retire RSA immediately?
No. Hybrid deployments keep RSA or ECDH alongside ML-KEM during the transition. NIST's deprecation timeline runs into the 2030s. The goal is graceful migration, not flag-day cutover.
What about community banks and credit unions?
Smaller institutions have the same quantum exposure as large banks but typically with less in-house expertise and more reliance on core banking service providers (Fiserv, FIS, Jack Henry, COCC, Symitar). The PQC migration for community banks and credit unions will largely be delivered through service provider product updates. Boards should be asking their core providers and their key technology vendors about PQC roadmaps now, with milestones tied to NIST IR 8547 deprecation timelines.
How does PQC migration interact with the bank's PCI DSS posture?
PCI DSS v4.0 effective March 2024 requires strong cryptography for cardholder data in transit and at rest. PCI DSS does not mandate PQC by name, but the council's Cryptographic Roadmap discussion and the broader payment industry direction are toward including PQC in future PCI DSS revisions. Banks operating cardholder data environments should include their CDE in the PQC inventory and treat the migration as part of broader PCI DSS compliance maintenance. The PCI Council has signaled that cryptographic agility will become an explicit PCI DSS requirement in future versions.
What budget magnitude should a bank plan for the PQC migration?
The cost depends on the bank's size and complexity, but order-of-magnitude estimates suggest medium and large banks should budget several million dollars for inventory, pilot work, vendor coordination, and initial deployments over the first three years, with substantially more for full enterprise rollout over a 7 to 10 year horizon. Specific cost drivers include HSM hardware refresh (the biggest single line for many banks), software vendor PQC license fees, internal staffing for the migration program, and contingency for unexpected incompatibilities. The cost of not migrating is the long-tail liability of harvest-now-decrypt-later exposure plus future regulatory penalties for non-compliance.
Sources
- NIST. "NIST IR 8547: Transition to Post-Quantum Cryptography Standards." nist.gov.
- FFIEC. "Cybersecurity Assessment Tool." ffiec.gov.
- FFIEC. "Information Technology Examination Handbook: Information Security." ffiec.gov.
- NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism." nist.gov.
- NIST. "FIPS 204: Module-Lattice-Based Digital Signature." nist.gov.
- CISA, NIST, NSA. "Quantum-Readiness: Migration to Post-Quantum Cryptography." cisa.gov.
- OCC. "Comptroller's Handbook: Information Technology." occ.gov.
- PCI Security Standards Council. "PCI DSS v4.0." pcisecuritystandards.org.
Related Articles
- What Is Post-Quantum Cryptography
- Why RSA-2048 Will Break
- Harvest Now, Decrypt Later
- PQC for Financial Services
- Hybrid Encryption
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.