Generic quantum security guidance does not serve the financial sector well. The risk profile here is specific: retention obligations that place archived transaction data directly within the HNDL risk window, interconnected infrastructure where a single collection point can expose thousands of participants simultaneously, and a regulatory framework (DORA, NIST IR 8547, NIS2, the Basel operational risk provisions) that is already in force and already encompasses quantum-vulnerable cryptography as a categorisable risk. This guide is written for CISOs, chief risk officers, and compliance leads at financial institutions who need the specific detail, not the general argument.
Why Financial Services Is Structurally Different
Three factors create a higher-than-average quantum security exposure in financial services. Understanding them is necessary for scoping any migration programme accurately.
Regulatory retention requirements create a defined HNDL window. MiFID II (Directive 2014/65/EU, Art. 25) requires investment firms to retain records for at least five years. The Bank of England's Prudential Regulation Authority requires certain firms to retain records for seven years. Dodd-Frank mandates 5-7 years for swap records under 17 CFR Part 45. EMIR (Regulation (EU) 648/2012, Art. 9) requires ten-year retention for trade data. These are not notional periods. Apply the Mosca inequality, the risk framework developed by Dr Michele Mosca at the Institute for Quantum Computing, University of Waterloo (IEEE Security & Privacy, 2018), to a financial transaction record generated in 2022 with a 10-year retention requirement: that record must remain confidential until 2032. On the Global Risk Institute's central Q-Day probability estimate of 2033-2037, it is within the risk window. For an adversary collecting that ciphertext today, the wait is measurable in years, not decades.
High-value data at scale creates a high-priority collection target. Payment systems, clearing and settlement networks, foreign exchange, and correspondent banking generate enormous volumes of financially and strategically sensitive data encrypted under TLS protocols whose key exchange is quantum-vulnerable. SWIFT GPI processed over $150 trillion in transactions in 2023 (SWIFT Annual Review 2023). The TLS key exchange for each session (ECDHE or RSA) is a potential HNDL collection point. A well-resourced adversary does not need to compromise any financial institution directly. Bulk TLS traffic interception at internet exchange points captures sufficient key exchange material for future quantum decryption.
Interconnected infrastructure amplifies a single collection point. Financial markets are interconnected through SWIFT MT/MX messaging, ISO 20022, FIX protocol, and the clearing and settlement networks (CHIPS, CHAPS, TARGET2) that underpin them. A successful HNDL collection operation against a central counterparty or major messaging node exposes the transaction records of thousands of participants simultaneously. This systemic amplification is specific to financial infrastructure. SWIFT has published a post-quantum cryptography position paper (2022), but has not mandated member institution migration timelines. Waiting for SWIFT to mandate creates a dependency that is not operationally necessary and is not consistent with DORA obligations.
The HNDL Exposure: Specific to Financial Services
Nation-state actors have documented motivations for targeting financial data over long horizons. The CISA Advisory AA20-239A details North Korea's Lazarus Group SWIFT attacks between 2016 and 2019. The ODNI 2023 Annual Threat Assessment names China's financial intelligence collection objectives explicitly. The collection capability and targeting motivation are both documented. The specific quantum-motivated component is inferential. No public source confirms a HNDL operation against financial infrastructure by name, but the operational infrastructure and strategic incentive structure are directly applicable.
The most exposed financial services data categories, in priority order under the Mosca inequality, are as follows. Customer identity and KYC records carry no defined expiry: a permanent personal identifier is permanently sensitive. Long-term investment and portfolio records for pension and asset management accounts span decades. Correspondent banking records, retained for five years under 4AMLD (Directive 2015/849/EU, Art. 40), document financial relationships with strategic intelligence value. Foreign exchange and derivatives records are retained for five to seven years under EMIR and Dodd-Frank. Mortgage and long-term credit records are retained for six or more years post-settlement under FCA MCOB 13. Proprietary risk models and stress test parameters have no defined expiry and high competitive value.
For the full treatment of HNDL mechanics, evidence base, and Mosca inequality methodology, see our dedicated HNDL in Motion analysis. The financial services application of these principles is what this article addresses.
The Regulatory Landscape
Financial services is the most heavily regulated sector for quantum security readiness. The framework is not complete: no regulator has yet published a specific PQC migration mandate with a financial penalty attached. The obligations that are already in force do encompass quantum-vulnerable cryptography, and the supervisory expectation trajectory is clear.
DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554). In force 17 January 2025. Applies to banks, insurance companies, investment firms, payment institutions, and critical ICT third-party providers in the EU. The ICT risk management obligations in Art. 6-10 require identification and mitigation of ICT vulnerabilities. Quantum-vulnerable cryptography is a categorisable ICT vulnerability. Art. 21-24 requires advanced threat-led penetration testing for significant institutions. The third-party provisions in Art. 28-44 require assessment of critical ICT third-party providers (CITPs) for ICT security standards, which includes cryptographic security. A financial entity whose critical cloud provider or payment processor has not begun PQC migration has an unassessed DORA Art. 28 risk. The EBA, ESMA, and EIOPA joint guidelines on ICT third-party risk are expected to provide further specificity.
ECB supervisory expectations. The European Central Bank has identified quantum computing as a systemic risk to the European financial system. The ECB's Cyber Resilience Oversight Expectations for Financial Market Infrastructures (CROE v2.0, 2022) reference emerging technology risks including quantum computing. No explicit PQC migration requirement has been published; the supervisory communications signal expectation of proactive risk assessment by financial market infrastructure operators. Waiting for an explicit ECB mandate is not a credible governance position under DORA's existing ICT risk management requirements.
Basel operational risk framework. The Basel Committee on Banking Supervision's Principles for Operational Resilience (March 2021, BIS d516) require institutions to identify and manage emerging technology risks. Quantum computing is an emerging technology risk with a defined, documented impact on cryptographic systems that underpin virtually all financial infrastructure. The absence of an explicit Basel mention of quantum risk does not exempt the risk from the framework's scope. An unassessed quantum exposure is an unquantified operational risk exposure under the Basel framework.
UK-specific. The Bank of England and PRA have not yet published specific PQC migration requirements. The NCSC's post-quantum cryptography migration guidance (2023) is referenced by the PRA in the context of general cyber risk management obligations. The FCA Operational Resilience Policy (PS21/3, 2021) and SYSC sourcebook create general obligations that encompass quantum-vulnerable cryptographic risk. FCA and PRA-specific quantum guidance should be verified for any updates published after early 2026 before use in formal regulatory submissions.
US-connected institutions. NIST IR 8547 (August 2024) sets the deprecation timeline: RSA and ECDSA disallowed in US federal civilian executive branch systems by 2030, other use cases by 2035. Most enterprise cryptographic stacks are built on NIST-compliant algorithms. For US-connected financial institutions (correspondent banks, US branches of international banks, and US-listed entities) the 2030 milestone functions as an effective planning deadline. CNSA 2.0 (NSA, September 2022) applies to defence sector and supply chain financial entities. NSM-10 (May 2022) covers executive branch contractors.
Where Quantum Vulnerability Sits in a Financial Institution
A cryptographic inventory is the prerequisite for migration. Before beginning one, it is useful to know where the most exposed systems are typically found. The important caveat: "typical" architecture varies significantly across institutions, and only the inventory will confirm the actual exposure map.
External-facing systems (highest HNDL risk). TLS 1.2/1.3 for customer-facing applications: online banking, mobile apps, open banking APIs mandated under PSD2 (Directive 2015/2366/EU). The ECDHE key exchange in each TLS session is the collection target. SWIFT MT/MX messages transported over TLS between member institutions.
Internal infrastructure (systemic risk if compromised). IPsec VPN tunnels connecting trading floors, data centres, and branch offices. HSM (Hardware Security Module) key hierarchies: the root CA and signing keys that anchor the institution's entire PKI. Database encryption (Transparent Data Encryption) where key management uses RSA or ECDH.
Long-lived credentials (most operationally urgent). Root CA certificates anchoring the internal PKI have lifetimes of 10-20 years. The key exchange material for a root CA compromise enables decryption of everything that trusted it. Code signing certificates for deployed financial software carry long validity periods and sign systems that will be in production for years. Archive encryption for historical records (encrypted backup tapes and cold storage) is permanently at HNDL risk if the key wrapping used RSA or ECDH, regardless of future protocol upgrades.
HSMs deserve specific mention. Financial institutions use HSMs for root CA, payment card processing (PCI DSS v4.0, Req. 3.7), and code signing. Current generation HSMs certified to FIPS 140-3 Level 3 or 4 can store post-quantum keys, but firmware must be updated and in some cases hardware must be replaced to support PQC algorithm operations at the required throughput. The HSM procurement and deployment cycle for a major bank, including FIPS 140-3 validation of updated firmware, typically runs 3-5 years from procurement decision to full deployment. This is among the primary operational arguments for beginning the migration programme before regulatory mandates arrive. The NIST NCCoE SP 1800-38 migration guidance covers HSM transition specifically.
A Risk-Prioritised Migration Sequence
The NIST NCCoE SP 1800-38 phasing methodology and CISA's post-quantum migration guidance for critical infrastructure provide the structural basis for the following sequence. The specific timelines for any institution depend on its cryptographic inventory, which must come first.
Phase 1: Commence now.
Cryptographic inventory: catalogue all asymmetric cryptographic use across the organisation: algorithm, key size, protocol, system owner, data classification. This is the precondition for every subsequent decision. For a large financial institution with thousands of cryptographic touchpoints across its application estate, this phase takes 6-18 months. It cannot be shortcut. Nothing else can be prioritised without it.
Root CA and code signing key migration to PQC: the trust anchor for the entire PKI. Replacing root CA certificates requires a transition period measured in years because of the chain of trust implications. Beginning the CA migration programme now is not premature. It is consistent with completing before the 2030 planning horizon.
Long-lived archive encryption assessment: encrypted backup archives using RSA or ECDH key wrapping are permanently at HNDL risk. Prioritise assessment of archives containing PII, KYC records, and long-retention trade data. Re-encryption of the highest-priority categories should begin in Phase 1.
Phase 2: Concurrent with Phase 1 for HNDL-exposed flows.
Hybrid TLS deployment for external-facing APIs and customer applications: NIST FIPS 203 (August 2024) standardised ML-KEM. Hybrid key exchange (classical ECDHE combined with ML-KEM) protects new communications from the deployment date forward without breaking backward compatibility with unupgraded clients. Google Chrome deployed X25519Kyber768 in August 2023; Cloudflare deployed post-quantum hybrid TLS the same year; IETF RFC 9496 (December 2024) standardised hybrid KEM constructions. Enterprise deployment requires OpenSSL 3.2+ or equivalent. It is a configuration project, not a hardware replacement.
SWIFT message transport: do not wait for SWIFT to mandate migration. Begin internal testing in parallel with the Phase 1 inventory. SWIFT's own PQC position paper (2022) acknowledges the migration requirement; the absence of a member mandate does not reduce the organisation's own DORA ICT risk management obligations.
Phase 3: Medium term, 2026 to 2030.
Full TLS migration for internal infrastructure. HSM firmware and hardware upgrade cycle. Long procurement lead times mean Phase 3 designation does not mean this decision can be deferred; procurement should begin in Phase 1 or Phase 2 to meet the Phase 3 operational target. Third-party and correspondent bank quantum readiness assessments, required under DORA Art. 28 for critical ICT third-party providers.
QSECDEF's Cryptographic Asset Prioritisation Matrix maps cryptographic assets against HNDL risk exposure, regulatory obligation, and operational complexity. The output is a prioritised migration roadmap structured for presentation to a steering committee or board.
The 2030 Horizon Is a Planning Deadline, Not a Safety Margin
NIST IR 8547 sets 2030 as the deprecation date for RSA and ECDSA in US federal civilian systems. For EU financial institutions, the equivalent practical horizon comes from DORA's ICT risk management requirements and ECB supervisory expectations. Any financial institution whose cryptographic stack is built on NIST-compliant algorithms, which means virtually all of them, should treat 2030 as the planning end point, not the safe point.
The arithmetic is unforgiving. A cryptographic inventory begun in 2026 and completed in 2027 leaves three years for the active migration phases before 2030. That is achievable with programme discipline for a well-scoped organisation. A migration programme that begins in 2028 does not reach the same conclusion before the deadline without compressing timelines that have genuine technical constraints. HSM procurement and validation cannot be rushed. CA migration chains cannot be shortened beyond the technical transition requirements.
ENISA's post-quantum cryptography guidance (2021, updated annually for the NIST FIPS publications) and the EU Cybersecurity Act (Regulation (EU) 2019/881) provide the European regulatory alignment basis for institutions that need to frame their migration programme in EU supervisory terms. Financial market infrastructure operators in the EU should treat ENISA's updated cryptographic recommendations as a proxy for regulatory expectation ahead of formal mandates. Those mandates are coming, and they will assume that organisations with the sophistication and resources of major financial institutions have not been waiting to be told.
QSECDEF's financial services workshop programme gives security teams a structured process for cryptographic inventory, regulatory mapping, and migration prioritisation. Details at /workshops/financial.
