How DORA Shapes Quantum Security Preparedness in Financial Services

The Digital Operational Resilience Act became applicable on 17 January 2025. Its ICT risk management obligations are live. So are its cryptographic controls requirements. Neither mentions post-quantum cryptography by name, and for practitioners trying to build a DORA-conformant quantum security programme, that absence creates a navigational problem: where exactly do PQC obligations arise in the DORA structure, and what does the binding secondary legislation actually require?

This article goes inside those questions. It is a companion to the existing analysis at DORA and post-quantum cryptography: what financial services ICT risk managers must know, which covers the DORA-PQC intersection in broad terms. This article focuses on the specific obligations in Articles 6 and 9, the binding Regulatory Technical Standards (RTS) that implement them, and the ICT third-party risk dimension under Articles 28 to 30. The output is a five-component programme that maps each deliverable to the DORA Article it satisfies.

Jurisdiction note. DORA is an EU Regulation. It applies to EU-licensed financial entities and to ICT third-party service providers designated as critical under DORA Chapter V. UK financial institutions are not directly subject to DORA. UK ICT operational resilience requirements derive from the FCA Operational Resilience Policy (PS21/3), PRA Supervisory Statement SS1/21, and the NIS Regulations 2018 (SI 2018/506), distinct instruments with different scope and timeline.

What DORA Requires from Financial Entities on ICT Risk

DORA (Regulation (EU) 2022/2554) applies to 20 categories of EU financial entity listed in Article 2(1): credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers under MiCA, insurance and reinsurance undertakings, pension funds, credit rating agencies, trading venues, central counterparties, and ICT third-party service providers when designated as critical under Chapter V. Application date was 17 January 2025; there is no further grace period on the core framework obligations.

Article 6 establishes the ICT risk management framework that each in-scope entity must maintain. The framework must cover the full ICT risk lifecycle: identification and classification of ICT assets under Article 6(4); continuous identification of all sources of ICT risk under Article 6(6); risk assessment and treatment planning; and continuous adaptation as the threat landscape evolves under Article 6(8). These are ongoing operational obligations, not one-time assessments.

The quantum connection enters through Article 6 at all three of those sub-clauses. Cryptographic algorithms are ICT assets under Article 6(4): a financial entity that has not inventoried its cryptographic primitives has a gap in its asset classification. Harvest-now-decrypt-later is a source of ICT risk under Article 6(6), a passive, ongoing threat to data confidentiality that the Article's "continuous identification" requirement applies to directly. And the publication of NIST FIPS 203/204/205 in August 2024 and NIST IR 8547 in November 2024 are threat landscape evolution events that Article 6(8)'s adaptation obligation requires the framework to absorb. A financial entity that reviewed its ICT risk management framework in late 2024 without addressing those publications has a documented gap under Article 6(8).

Article 9 on protection and prevention specifies ICT security measures. Article 9(2) requires financial entities to implement measures to ensure the confidentiality, integrity, and availability of data and to address ICT risks. Article 9(3) requires that policies on the "use of cryptography and encryption" are in place, documented, reviewed, and tested.

The RTS and ITS That Specify How: Commission Delegated Regulation (EU) 2024/1774

The primary binding technical specification for DORA Articles 6 and 9 is Commission Delegated Regulation (EU) 2024/1774. The date "13 March 2024" is the Commission adoption date; the OJ publication date, which determines the entry into force calculation, should be verified in OJ L 2024/1774 before citing in compliance documentation. [ASSUMED: OJ publication date consistent with the adoption date on the same calendar year; verify against the Official Journal record.] This is not guidance; it is a Commission Delegated Regulation binding in its entirety on in-scope entities.

Article 8 of the RTS on cryptographic policies requires financial entities to implement cryptographic controls that address the current threat landscape, including the confidentiality lifetime of data protected. The policy must be reviewed and updated as threats evolve. The RTS does not name NIST or specific PQC algorithms, but the logical chain is direct and is confirmed in the recitals of the parent Delegated Regulation. NIST FIPS 203/204/205 publication and NIST IR 8547 deprecation initiation are the events that require a policy review under Article 8's update requirement. A cryptographic policy that was last reviewed before August 2024 and has not been updated to address the post-quantum standard publication is not meeting the RTS Article 8 review obligation.

Commission Implementing Regulation (EU) 2024/2956 (the ITS on registers of information about ICT third-party service provider contractual arrangements, published November 2024) creates a separate but related obligation. Financial entities must maintain registers of their ICT TPP arrangements, including service classification and criticality assessment. For contractual arrangements covering cryptographic services (key management platforms, HSM-as-a-service, PKI, encrypted communications infrastructure), the register must reflect adequate transition planning assessment, which includes the ICT TPP's PQC roadmap as part of the concentration risk picture. [INFERRED: PQC roadmap as required register content; the ITS field specifications should be verified against the published text to confirm this inference is soundly grounded.]

Article 6 in Depth: Building the Quantum Risk Register

Three specific sub-clauses of Article 6 create the quantum risk register obligation, each in a different way.

Article 6(4) requires financial entities to "identify, classify and document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their interdependencies." Cryptographic algorithms and key material are ICT assets. The instrument that satisfies this obligation for cryptographic assets is a Cryptographic Bill of Materials (CBOM): a structured inventory mapping every algorithm, key size, protocol, certificate, and library to the systems and data it protects. A financial entity that builds a CBOM for PQC migration purposes simultaneously produces the cryptographic asset register that Article 6(4) requires. This is the CBOM's dual-purpose value: it serves the migration programme and the DORA compliance programme with a single artefact. NIST NCCoE SP 1800-38B provides the reference methodology.

Article 6(6) requires continuous identification of "all sources of ICT risk, including ICT risk stemming from other financial entities and ICT third-party service providers." Harvest-now-decrypt-later is a source of ongoing ICT risk that satisfies this description precisely. The collection event may already have occurred; the risk materialises progressively as CRQC capabilities develop. The risk register entry for HNDL should document: threat actor category (state-level adversary), attack method (passive traffic collection for future decryption), trigger condition (CRQC availability, probability-weighted for the 2033 to 2035 window), and the data categories affected with their confidentiality lifetime estimates. That is a standard ICT risk register entry, not a speculative exercise.

Article 6(8) requires financial entities to "update the ICT risk management framework continuously, at least on the basis of lessons stemming from its implementation and following major incidents, as well as based on supervisory instructions or conclusions stemming from relevant supervisory assessments." The NIST FIPS 203/204/205 publication and NIST IR 8547 deprecation announcement are the equivalent of a major external standards event: the cryptographic landscape changed materially. Article 6(8)'s "continuous update" obligation applies.

Article 9 in Depth: Cryptographic Policy and Protection Measures

RTS Article 8 (of Commission Delegated Regulation (EU) 2024/1774) specifies the minimum content for the DORA Article 9(3) cryptographic policy. Note: "RTS Article 8" throughout this article refers to Article 8 of the Delegated Regulation, not DORA Article 8 (which addresses ICT-related incident management); the companion article at DORA and post-quantum cryptography follows the same attribution convention. The policy must identify asset classifications by data sensitivity, specify appropriate cryptographic controls for each classification, include a review cycle, and address key management lifecycle. A DORA-conformant cryptographic policy written or reviewed in 2026 that does not acknowledge NIST IR 8547's deprecation of RSA and ECC, or the availability of FIPS 203/204/205 implementations, is not satisfying the spirit of the RTS review requirement, and the spirit is also the letter, given that the RTS requires policies to reflect the current threat landscape.

Article 9(4)(c) requires financial entities to implement procedures for detecting anomalous activities on ICT networks. The connection to quantum preparedness is operational. A financial entity that deploys X25519+ML-KEM-768 hybrid key exchange (per IETF draft-ietf-tls-hybrid-design) on its externally accessible services will generate TLS logs that show cipher suite negotiation outcomes, specifically which counterparties and cloud services are capable of quantum-safe key exchange and which are not. That information is directly relevant to concentration risk assessment: even a fully migrated financial entity cannot achieve end-to-end quantum-safe communications if its critical ICT dependencies are still using classical key exchange. Article 9(4)(c) logging of TLS cipher suite negotiation is the mechanism that surfaces this gap operationally.

The hybrid deployment step itself is both a migration action and an Article 9(2) protection measure. X25519+ML-KEM-768 is operational today, deployed at scale by Google Chrome, Mozilla Firefox, and Cloudflare. Client-side support exists in the current browser and TLS library ecosystem. A financial entity deploying hybrid key exchange on its external interfaces is implementing a documented Article 9(2) protection measure against a documented ICT risk. The compliance narrative writes itself from the risk register entry to the protection measure.

ICT Third-Party Risk: The Quantum Supply Chain

DORA Articles 28 to 30 create third-party obligations that extend the quantum security requirement beyond the financial entity's own infrastructure.

Article 28(2) requires that contractual arrangements with ICT TPPs address ICT security requirements, including the use of encryption and security controls for data in transit and at rest. For critical or important function contracts, this is not a generic security clause, it is a specific obligation. Cryptographic service providers, cloud key management platforms, HSM-as-a-service vendors, and any ICT TPP processing financial entity data under encrypted channels are within scope. The Article 28(2) contractual requirement should include disclosure of the ICT TPP's PQC roadmap as part of the security obligation: an ICT TPP without a documented PQC migration plan cannot demonstrate that it has adequate cryptographic controls for critical functions over a multi-year horizon.

Article 30(2)(h) requires contracts for critical or important functions to include provisions for the ICT TPP's participation in the financial entity's Threat-Led Penetration Tests (TLPT) under DORA Article 26. As financial entities implement hybrid and pure PQC migration, the cryptographic integrity of that migration (misconfigured hybrid schemes, inadequate key management, residual classical algorithm use in critical flows) becomes a TLPT scope item. ICT TPPs providing cryptographic services to critical functions need to be contractually engaged in that testing scope.

Article 29 on concentration risk creates a systemic dimension. The quantum preparedness of central financial infrastructure (messaging networks, clearing systems, settlement infrastructure) is a concentration risk factor that DORA Article 29 risk assessments must address. Where a financial entity has systemic cryptographic dependencies concentrated in a small number of providers, the PQC migration status of those providers directly affects the entity's own quantum-safe communications capability. The Article 29 risk assessment should include an assessment of the PQC migration status of the financial entity's most critical infrastructure dependencies. [ASSUMED: status of systemic financial infrastructure PQC migration in mid-2026; verify current state before publication.]

The Five-Component DORA Quantum Security Programme

A starting framework for DORA-aligned programme design has five components, each mapped to a specific DORA obligation. This is not a definitive statement of DORA conformance; it is a structured basis for programme development that qualified legal and compliance counsel should review against each entity's specific circumstances and supervisory context.

Component 1: CBOM completion (DORA Article 6(4)). All cryptographic assets classified and documented per the NIST NCCoE SP 1800-38B methodology. This satisfies the Article 6(4) ICT asset classification requirement for cryptographic primitives and produces the inventory needed for every subsequent component.

Component 2: HNDL risk register entry (DORA Article 6(6)). A formal risk register entry documenting the HNDL threat: threat actor, attack method, trigger condition, affected data categories with confidentiality lifetime estimates, and probability-weighted impact assessment. This satisfies the Article 6(6) continuous risk identification requirement.

Component 3: Cryptographic policy update (DORA Article 9(3) and RTS Article 8). Review and update of the cryptographic policy to acknowledge NIST IR 8547's deprecation timeline and plan for FIPS 203/204/205 adoption across classified asset categories. The review date and the NIST publications that triggered the review should be documented in the policy version history.

Component 4: ICT TPP contract review (DORA Article 28(2)). Contract amendments with ICT TPPs providing cryptographic, key management, or encrypted communications services, requiring PQC roadmap disclosure and documented quantum security commitments. For critical function providers, include TLPT participation for cryptographic integrity testing under Article 30(2)(h).

Component 5: Priority migration for highest-risk flows (DORA Article 9(2)). Hybrid key exchange deployment on the financial entity's highest-HNDL-risk external interfaces: settlement data, counterparty position information, long-tenor derivatives traffic. X25519+ML-KEM-768 is the current implementation standard per IETF draft-ietf-tls-hybrid-design. This provides immediate HNDL protection while maintaining compatibility with counterparties and systems not yet PQC-capable.

DORA and NIS2: One Programme, Two Obligations

EU financial entities that are also essential entities under NIS2 (Directive 2022/2555) (typically financial market infrastructure operators, large banks, or systemic payment institutions) face overlapping compliance obligations on cryptographic security. DORA Article 1(2) resolves the overlap: DORA is lex specialis for ICT risk in financial services, prevailing over NIS2 where both apply to the same entity and obligation.

In practice this means the CBOM built for Component 1, the risk register entry in Component 2, and the cryptographic policy in Component 3 collectively satisfy the NIS2 Article 21(1) risk assessment requirement and the Article 21(2)(h) encryption obligation. One programme, two regulatory obligations met. The NIS2 financial sector carve-out under Article 4(2) reinforces this: DORA is the primary compliance vehicle for ICT risk in financial services. Organisations should avoid running parallel DORA and NIS2 programmes with separate deliverables for cryptographic risk, the duplication is unnecessary and the risk of inconsistency between them creates its own compliance exposure.

For the full NIS2 treatment of the quantum security obligation for essential entities outside financial services, see NIS2 and post-quantum cryptography.

The Supervisory Timeline and the Window to Act First

DORA Article 45 provides for administrative penalties up to €10 million or 2% of total annual worldwide turnover for financial entity breaches of DORA requirements. The supervisory position for a financial entity that has not addressed quantum risk in its ICT risk management framework is weaker than one that has. National competent authorities conducting DORA compliance assessments in 2026 will examine whether the ICT risk management framework has been updated to reflect the current threat landscape. The NIST FIPS 203/204/205 publication and NIST IR 8547 deprecation announcement are public, documented, and dateable events. A supervisor can establish a clear timeline: the standards were published, the threat landscape shifted, and Article 6(8) requires adaptation. Was the framework adapted?

Neither the EBA nor ESMA had published PQC-specific guidance for financial institutions as of knowledge cutoff August 2025. ENISA's 2023 and 2024 Threat Landscape reports identify quantum computing as a documented emerging threat. The absence of specific EBA or ESMA guidance does not create a safe harbour from the DORA obligations that are already in force. It does, however, create a window: proactive organisations that define their PQC compliance posture now can shape what best practice looks like before it becomes formally mandated supervisory expectation. [ASSUMED: EBA/ESMA PQC guidance status in mid-2026; verify whether either authority has published relevant guidance between August 2025 and publication date.]

The practical implication: the five-component programme above is not a compliance exercise to complete once supervisory pressure arrives. It is the programme that positions a financial entity as already compliant when that pressure does arrive. Starting with the CBOM (Component 1) is the prerequisite for demonstrating compliance on the other four components. It is also proportionate: it costs a fraction of the migration programme it enables, and it produces the risk data that makes every subsequent decision defensible.