Financial institutions face a more complex PQC readiness problem than most sectors. The combination of live regulatory obligations, unusually long data retention requirements, and high adversarial interest in financial records produces a risk profile where the standard enterprise migration timeline is insufficient. The pillar framework below gives CISO, CTO, and CRO audiences a structured tool for assessing programme status and communicating it to boards. This article assumes the reader understands what PQC migration is and why it is necessary. The question here is not whether to migrate. It is how to assess current readiness across the five dimensions that determine whether a programme is adequate under regulatory scrutiny.

Why financial institutions face a distinct readiness challenge

Three factors combine to make financial institution PQC readiness more urgent than the average enterprise scenario.

Regulatory obligations are already live. DORA Regulation (EU) 2022/2554 entered into application on 17 January 2025 and applies directly to the range of financial entity types defined in Article 2(1), from credit institutions and payment providers through to crypto-asset service providers and insurance undertakings. Commission Delegated Regulation (EU) 2024/1774 (the RTS on ICT risk management tools, methods, processes and policies under DORA), Article 6, specifies that cryptographic controls must align with "state of the art" standards. NIST finalised ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, and FN-DSA (FIPS 206) in October 2024. Those publications shifted the state-of-the-art baseline. A financial entity that has not assessed whether its cryptographic controls align with those published standards cannot demonstrate it has met the RTS Article 6 requirement. In the UK, FCA PS21/3 and PRA SS2/21 impose operational resilience obligations that apply to cryptographic vulnerabilities as a category of operational risk. [INFERRED: FCA PS21/3 and PRA SS2/21 address operational resilience broadly; their application to quantum cryptographic risk specifically follows from the obligation to identify and address all material vulnerabilities to important business services, rather than from explicit quantum or PQC references in the policy text itself.] In the US, FFIEC IT Examination Handbook guidance (specifically the Information Security booklet) incorporates NIST standards by reference for cryptographic control requirements. [INFERRED: FFIEC Information Security booklet incorporation of NIST standards is current guidance practice; verify against the most recent FFIEC IT Examination Handbook release before publication.]

Data retention requirements are unusually long. MiFID II Delegated Regulation (EU) 2017/565, Article 72, requires retention of certain transaction records for five to seven years. Company Act record-keeping obligations extend further for certain categories. Data with confidentiality requirements extending into the 2030s is at immediate HNDL risk: the harvest-now-decrypt-later threat means adversaries collecting encrypted financial records today can decrypt them once a cryptographically relevant quantum computer (CRQC) exists. The Mosca inequality gives the quantitative frame: when migration time plus data lifetime exceeds time to CRQC (consensus estimate approximately 2033 to 2035), migration must begin now. For MiFID transaction data with a seven-year retention period, a five-year migration estimate, and an eight-year estimated CRQC window, the Mosca arithmetic returns a positive result. Migration is not deferred. It is urgent.

Adversarial interest in financial data is higher than in most sectors. Proprietary trading strategies, client financial records, inter-bank clearing data, and custody infrastructure are high-value HNDL targets. Nation-state adversaries with the capability to run persistent collection operations are the relevant threat actors for this category of data.

Pillar 1: Governance and executive ownership

PQC migration touches cryptographic infrastructure across the entire institution. Without board-level ownership and a named programme executive, the work fragments into isolated library upgrades with no architectural coherence, no prioritisation framework, and no mechanism for resolving conflicts between operational teams over migration sequencing.

DORA Article 6(2) makes this explicit: the management body of a financial entity "shall bear overall responsibility for setting and approving the digital operational resilience strategy." That is a board-level obligation, not a delegation. In the context of PQC migration, Article 6(2) means the management body cannot delegate ignorance of the cryptographic risk. The governance structure must include a board-approved cryptographic risk appetite statement; a named programme executive (Chief Cryptographic Risk Officer or equivalent); cross-functional steering membership covering CISO, CTO, CFO, Legal, and Compliance; and a defined escalation path to the board when migration milestones are missed.

NIST NCCoE SP 1800-38B recommends establishing a dedicated PQC migration working group as the first organisational step, with a charter covering scope (all cryptographic assets), authority (the ability to mandate migration roadmaps on operational teams, not merely advise), and reporting line (directly to the CISO or equivalent, not embedded in a sub-team). The authority point is the one that typically fails in early programme structures: a working group that can produce recommendations but cannot mandate timelines does not have sufficient authority to drive migration at the pace the regulatory timeline requires.

For the full DORA Article 6 implementation sequence, see DORA Implementation Guide: A Step-by-Step Plan for Financial Services CTOs.

Pillar 1 readiness criterion (score 3/4): A board-approved programme charter exists, a named executive owns the programme, the working group has mandate authority over operational teams, and escalation to the Risk Committee has a defined trigger.

Pillar 2: Cryptographic asset inventory

A cryptographic bill of materials (CBOM) is the structured inventory of every cryptographic asset in the institution: algorithms, key sizes, protocols, certificates, HSMs, cryptographic libraries, and the systems and data each asset protects. The CBOM is the prerequisite for all downstream risk assessment and migration planning. Without it, migration prioritisation is guesswork.

DORA Article 8 creates the legal obligation for this inventory. Article 8(1) requires financial entities to maintain a comprehensive inventory of ICT assets supporting critical or important functions. For quantum security purposes, that obligation specifically encompasses cryptographic assets and their relationships to the systems and data they protect. The CBOM is the Article 8 instrument applied to the cryptographic layer.

A complete CBOM entry records: the cryptographic asset identifier; the algorithm and parameter set; the system or service it protects; the data classification of what it protects; the confidentiality lifetime of that data; the migration complexity estimate; and the owner team. That last field matters: every asset must have an engineering team accountable for its migration. An asset without an owner is an asset that will not be migrated until someone asks why it has not moved.

Manual inventory at enterprise scale is not operationally reliable. Static analysis of application code identifies algorithm calls; network traffic analysis identifies TLS versions and cipher suites in active use; HSM and key manager inventory export captures the hardware layer. Commercial automated discovery tooling supports CBOM construction at scale. The NIST NCCoE SP 1800-38B practice guide covers vendor-agnostic methodology and provides the reference framework for any discovery approach. [ASSUMED: verify current vendor tooling capabilities before naming specific products in procurement decisions.]

The CBOM enables the HNDL exposure quantification that gives the risk assessment its urgency signal. For the HNDL quantification methodology, see the companion article HNDL Risk in Financial Services: Regulatory and Operational Dimensions.

Pillar 2 readiness criterion (score 3/4): CBOM covers more than 80% of the cryptographic estate; each entry includes data classification, confidentiality lifetime, and a named owner; CBOM is maintained in a version-controlled system with a defined update cadence.

Pillar 3: Risk assessment and migration prioritisation

The Mosca inequality is the tool that converts a CBOM into a prioritised migration list. For each CBOM item, sum the estimated migration time and the confidentiality lifetime of the data it protects. If that sum exceeds the estimated time to a CRQC (approximately 2033 to 2035, or 7 to 9 years from 2026), migration must be prioritised now. The formula: T_migration + T_data_lifetime > T_CRQC means migrate now.

Applied to specific financial data categories, the arithmetic is stark. MiFID II transaction records with a seven-year retention requirement, combined with a five-year migration timeline for the system protecting them, against an eight-year CRQC window: 5 + 7 = 12 > 8. Immediate priority. Proprietary trading strategies with an indefinite confidentiality requirement: any reasonable migration estimate produces an immediate priority classification. Long-lived CA root keys with 10-year validity periods: immediate priority. Inter-bank clearing infrastructure with multi-year operational continuity requirements: immediate priority.

Migration priority should be documented in three tiers. Tier 1: migrate within 18 months, for items where the Mosca inequality returns a positive result under conservative estimates. Tier 2: migrate within 36 months, for items approaching the threshold under mid-range estimates. Tier 3: migrate on standard refresh cycle, for items where the data lifetime is short and migration complexity is low. The tier classification must be reviewed at least annually, because CRQC timeline estimates will evolve and migration complexity estimates will change as the programme progresses.

The highest-priority categories for most large financial institutions under this framework are long-duration client financial records, CA root keys and code-signing keys, inter-bank clearing infrastructure, and proprietary trading algorithm protection. All four typically have long confidentiality lifetimes combined with high migration complexity.

Pillar 3 readiness criterion (score 3/4): Every Tier 1 item has a named migration owner and a documented target completion date; the three-tier classification has been reviewed within the last 12 months; the Mosca calculation is documented per CBOM item for all Tier 1 items.

Pillar 4: Technical migration execution

The pragmatic first step for most financial institutions is hybrid TLS using the X-Wing construction (RFC 9496): X25519 combined with ML-KEM-768 in a single TLS 1.3 handshake. This provides immediate HNDL protection for new traffic without requiring full downstream migration of PKI, certificate infrastructure, or application-layer cryptography. It is backward-compatible with existing TLS infrastructure. Google and Cloudflare have operated hybrid ML-KEM-768 TLS at internet scale since 2023; the protocol is proven in production. ML-KEM-768 is the commercial parameter set appropriate for most financial institution environments; it is not the NSS parameter set — deployments in scope for CNSA 2.0 or equivalent national security obligations require ML-KEM-1024.

ML-KEM-768 parameter sizes are not a deployment barrier for financial applications: public key at 1,184 bytes, ciphertext at 1,088 bytes. ML-DSA-65 signature size is 3,309 bytes. These overheads are modest relative to financial transaction payload sizes and well within TLS record limits. [ASSUMED: cite a specific benchmark for the ML-KEM-768 performance overhead rather than a generalised claim; verify against Open Quantum Safe or Cloudflare Research published benchmarks before publication.]

The signature migration path depends on use case. Short-lived authentication signatures in TLS: ML-DSA-65 is the standard replacement for ECDSA. Long-lived signatures present a distinct requirement. Document signatures, code-signing keys, audit trail integrity, and software supply chain signing all require cryptographic durability well beyond the certificate validity period. SLH-DSA (FIPS 205) and LMS/XMSS (NIST SP 800-208) provide hash-based signature alternatives with security assumptions that reduce to well-understood hash function properties rather than novel lattice assumptions. Financial institutions with long-lived signing infrastructure should not assume ML-DSA alone addresses all signature use cases. The audit trail signing case, in particular, may require hash-based alternatives for the most conservative post-quantum margin.

SWIFT CSP and PCI DSS v4.0 do not yet mandate PQC algorithms by name. SWIFT CSP Control 2.6A addresses restricted access and protection of critical systems; PCI DSS v4.0 Requirement 4.2.1 requires strong cryptography. Neither framework insulates a financial institution from the DORA Article 9 / RTS (EU) 2024/1774 state-of-the-art obligation. Industry framework compliance and prudential regulatory compliance are not the same obligation. [ASSUMED: verify PCI DSS v4.0 Requirement 4.2.1 and any subsequent PCI SSC quantum guidance against current documentation before publication.]

Pillar 4 readiness criterion (score 3/4): Hybrid TLS deployment is in progress or complete for external-facing services; a ML-DSA-65 migration roadmap for authentication signatures exists with target dates; long-lived signing infrastructure has been assessed and SLH-DSA or XMSS migration options documented.

Pillar 5: Supply chain and third-party assurance

DORA Article 28(1) requires that the ICT risk management framework encompasses third-party ICT service providers. Article 28(2) requires contractual provisions on cryptographic controls. Commission Delegated Regulation (EU) 2024/1773 (RTS on third-party ICT) specifies what those contractual provisions must address. The practical consequence: a financial institution's PQC readiness is only as strong as its critical ICT suppliers' readiness, and DORA creates a legal basis to require PQC migration roadmap disclosure from those suppliers at contract renewal.

The major cloud hyperscalers have published PQC roadmaps and begun deploying hybrid TLS in managed services. AWS has enabled hybrid post-quantum TLS for its Key Management Service API channel; Azure and GCP have published equivalent deployment intentions. [ASSUMED: verify current AWS KMS, Azure, and GCP PQC deployment scope and default vs opt-in status before publication.] The cloud layer is partially protected for channel security. Application-layer cryptography, inter-service communication within the institution, and legacy on-premises infrastructure are not covered by cloud provider migration. A financial institution that migrates to a cloud provider with hybrid TLS has addressed one layer; the application-layer and key management migrations remain explicit tasks.

A third-party PQC assurance questionnaire for the next supplier review cycle should cover: cryptographic algorithm inventory for services used by the institution; a published PQC migration roadmap with dated milestones; expected dates for ML-KEM and ML-DSA support in each service; FIPS 140-3 validation status for post-quantum modules; and sub-contractor and fourth-party cryptographic practices for critical services. Every Tier 1 critical ICT supplier should have completed this questionnaire before the next contract renewal cycle.

Pillar 5 readiness criterion (score 3/4): PQC questionnaire issued to all Tier 1 critical ICT suppliers; responses received and assessed; gaps entered into the programme risk register; contract renewal clause templates updated to include CNSA 2.0 or FIPS 203/204 migration commitments. [INFERRED: Pillar 5 questionnaire content follows from DORA Article 28 third-party obligations and RTS (EU) 2024/1773; specific questionnaire fields are not prescribed by the regulation and represent good-practice interpretation.]

The five-pillar scorecard: assessing and reporting readiness

Each pillar should be assessed on a 0 to 4 scale: 0 = not started; 1 = initiated but no output produced; 2 = partial (CBOM exists but covers less than 50% of the estate; governance exists but no mandate authority); 3 = substantially complete and meeting the readiness criterion described above; 4 = complete with continuous monitoring and formal annual review in place. A score of 3 or above on all five pillars represents a programme that can withstand regulatory scrutiny.

Board Risk Committee reporting should translate each pillar score into business risk terms rather than technical metrics. A Pillar 2 score of 2 is not a technical finding. It means 60% or more of the institution's cryptographic surface is uncharted, cannot be assessed for HNDL exposure, and therefore cannot be prioritised for migration. That is a board-level risk statement.

NIST IR 8547 (November 2024) provides the external forcing function: RSA, ECDSA, and ECDH are deprecated for new use from 2030 and disallowed from 2035. With the DORA Article 9 state-of-the-art obligation already live, the SHA-1-to-SHA-256 migration experience as a precedent (approximately 10 years across the industry), and four years to the 2030 new-use deprecation, financial institutions with complex cryptographic estates are already in tight territory. The question is not whether the five pillars are eventually necessary. It is whether current programme velocity is sufficient to reach a score of 3 across all five before the regulatory timeline closes.

For the DORA post-quantum cryptography ICT risk analysis, see DORA and Post-Quantum Cryptography: ICT Risk Analysis.