What changed on 17 January 2025

The Digital Operational Resilience Act entered into application on 17 January 2025. Unlike GDPR, there was no two-year run-up between publication and enforcement. The obligations became live on a single date, and they apply directly across all EU member states without national transposition. If your organisation spent 2023 and 2024 preparing against the Regulation's text, you may have missed the document where the implementation detail actually lives: Commission Delegated Regulation (EU) 2024/1774, published 13 June 2024, is the Regulatory Technical Standard (RTS) on ICT risk management. It specifies the operational requirements for DORA Articles 6 through 16. The RTS entered into application alongside the Regulation on 17 January 2025. Many organisations planned against DORA; fewer have read the RTS carefully enough to know where the implementation specifics sit.

DORA's scope in Article 2(1) covers credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, fund managers, data reporting service providers, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, credit rating agencies, statutory auditors and audit firms, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories. If your organisation is on that list, the obligations are live. UK financial entities are not directly subject to DORA unless they provide ICT services to EU financial entities as third-party ICT service providers under Chapter V.

One regulatory framing point matters throughout this guide. DORA Article 13 covers ICT business continuity management. The "state of the art" cryptographic obligation does not sit there. It sits in DORA Article 9(2) (the protection and prevention obligation) and is specified operationally in RTS (EU) 2024/1774, Article 6. If your legal team or consultants have been citing Article 13 as the source of the cryptographic resilience requirement, that is an error worth correcting before your next supervisory assessment.

DORA Article 6: the ICT risk management framework

Article 6 requires financial entities to establish, implement, maintain, and continuously improve an ICT risk management framework. The framework must identify ICT assets and dependencies, assess and classify ICT risks, define risk tolerance, implement mitigation measures, monitor and report, and review following material incidents. It is the structural foundation on which Articles 7 through 16 operate. Nothing downstream is implementable without the Article 6 framework as the container.

The most common implementation gap is treating Article 6 as a documentation exercise: write the policy document, obtain board approval, consider it closed. The RTS (EU) 2024/1774, Article 3, is explicit that the framework must operate continuously, with formal review triggered not only by incidents but by material changes to the ICT environment, changes to the risk landscape, and outputs from the threat intelligence function under Article 13. For a CTO, the operative question is: who owns the framework update cadence, and what are the specific triggers for a formal review outside the annual cycle? If the answer is "the annual audit," the framework is not operating as the Regulation requires. Article 6(4) also requires a comprehensive ICT asset inventory covering hardware, software, and data assets, including the data flows between them. That inventory is the prerequisite for the cryptographic bill of materials in Step 2 below.

DORA Article 9 and the cryptographic resilience obligation

Article 9(2) requires financial entities to implement "mechanisms to ensure the confidentiality, integrity and availability of data, including cryptographic techniques." That is the source of the quantum cryptographic resilience obligation. The RTS (EU) 2024/1774, Article 6, specifies that cryptographic controls must be appropriate to the sensitivity of the data and assets, and must align with current standards and the "state of the art" [ASSUMED: verify exact RTS Article 6 language against EUR-Lex text before publication]. The state of the art shifted in August 2024, when NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). FIPS 206 (FN-DSA) followed in October 2024. A financial entity that has not assessed whether its cryptographic controls align with those published standards cannot demonstrate it has met the RTS's state-of-the-art requirement. Not having assessed is the compliance risk, regardless of the outcome of the assessment.

The harvest-now-decrypt-later (HNDL) threat is the mechanism by which quantum risk enters Article 9 compliance today, before a cryptographically relevant quantum computer exists. Financial entities holding transaction records, client financial data, and long-duration position data are generating records today whose confidentiality requirements extend into the 2030s. The Mosca inequality, formalised in Mosca's 2018 paper in IEEE Security and Privacy, gives the quantitative framework: once the sum of migration time plus data secrecy lifetime exceeds the estimated time to Q-Day, the risk of adversarial capture and future decryption is non-zero. For the operational risk analysis specific to financial services, see the companion piece on HNDL risk in financial services: regulatory and operational dimensions. For the detailed cryptographic risk analysis under DORA Article 9, see DORA and post-quantum cryptography: ICT risk analysis.

Building the cryptographic bill of materials under DORA Article 8

Article 8 requires financial entities to identify and classify all ICT assets and data assets on a continuous basis. Article 8(4) specifically requires identification of dependencies between ICT assets and external service providers. For quantum security purposes, Article 8 creates the obligation for a cryptographic bill of materials (CBOM): a structured inventory of every cryptographic component in the ICT estate, algorithms, key sizes, protocols, certificates, HSMs, and libraries, mapped to the systems and functions they protect, along with the data classification and confidentiality lifetime.

A CBOM row looks like this: "TLS 1.3 on payments API gateway: ECDHE_RSA_WITH_AES_256_GCM_SHA384, RSA-2048 key exchange, protecting payment authorisation flows, data classification: financial transaction records, confidentiality lifetime: 7 years, migration complexity: medium (gateway firmware update required)." That row tells you the algorithm, what it protects, how long it needs to stay protected, and how hard it is to migrate. Multiply that by every system in the estate and you have the instrument that converts abstract HNDL risk into a ranked, actionable migration list. NIST NCCoE SP 1800-38B (2024) provides the methodological framework, including discovery approaches using static analysis of application code for algorithm calls, network traffic analysis for live TLS cipher suites, and HSM and key manager inventory export. Manual inventory at enterprise scale is not operationally reliable. Automated tooling is necessary.

The CBOM is the prerequisite for every subsequent risk assessment and prioritisation decision in the programme. Start here.

DORA Article 28: quantum readiness in third-party ICT risk management

DORA Chapter V, Articles 28 through 44, addresses ICT third-party risk management. Article 28(1) requires financial entities to manage ICT third-party risk as an integral part of the ICT risk management framework. Article 28(2) requires that contractual arrangements with third-party ICT service providers include specific provisions on information security, including cryptographic controls. The companion RTS on third-party ICT, Commission Delegated Regulation (EU) 2024/1773, specifies what those contractual provisions must address, including provisions enabling the financial entity to audit and verify cryptographic controls at the third party, and requirements for third parties to maintain cryptographic controls at least as stringent as the financial entity's own. [ASSUMED: verify RTS 2024/1773 exact clause detail against EUR-Lex text before publication.] That gives the financial entity a DORA basis to require PQC roadmap disclosure and commitment from ICT service providers at contract renewal.

Critical third-party service providers (CTPPs) are subject to direct oversight by the European Supervisory Authorities under DORA Article 32. Cloud hyperscalers are among the most likely CTPP candidates based on the systemic importance criteria in Article 31. A financial entity using a CTPP's services should note that the CTPP's quantum security posture will eventually be visible to supervisors through the CTPP oversight mechanism. That means supervisors reviewing a financial entity's ICT risk framework will be able to cross-reference against what they know about the CTPP from the oversight programme. Gaps between what the financial entity reports about third-party risk and what the CTPP assessment shows will be visible.

The most actionable lever for CISOs and CTOs is contract renewal. Every contract renewal with a tier-1 ICT service provider is an opportunity to require: a cryptographic algorithm inventory as a contract deliverable, a commitment to ML-KEM and ML-DSA support by a specified date, a right to audit cryptographic controls, and a notification requirement for material changes to the vendor's cryptographic architecture. Frame this as a DORA Article 28 and RTS 2024/1773 compliance obligation in discussions with legal and commercial teams, not as a procurement preference.

Incident management: where quantum events fit in DORA's reporting framework

DORA Article 17 requires a comprehensive ICT-related incident management process. Article 19 sets the major incident reporting timeline: initial notification within 4 hours of classification; intermediate report within 72 hours; final report within one month. These timelines are not aspirational; they are enforcement-relevant deadlines.

A quantum-relevant incident scenario worth building into your classification criteria: discovery of evidence that encrypted data has been exfiltrated for HNDL purposes. Under Article 18's classification criteria, a large-volume encrypted data exfiltration to external destinations is likely to qualify as a major incident given its potential impact on long-term confidentiality. Financial entities should check whether their incident detection and classification procedures can recognise HNDL-pattern network behaviour. The question is not whether such an event is currently occurring; it is whether your detection and classification capability is built to recognise it if it were, and whether the response procedure includes triggering the Article 19 reporting clock. This is a preparedness point, not an assertion about current threat activity.

The five-step implementation sequence

The sequence below is a structured CTO plan. Each step names the Article it satisfies, the output it produces, and a realistic time estimate for a mid-size financial entity. Complex multi-system estates will take longer at Steps 2 and 3.

Step 1: Governance and framework establishment (Article 6). Ensure the ICT risk management framework document is board-approved and explicitly includes quantum threats in scope: HNDL as a named risk category, algorithm deprecation per NIST IR 8547 as a known future constraint, and a nominated owner for cryptographic risk. The framework is the legal container for everything that follows. Without board approval of a quantum-inclusive risk framework, downstream decisions lack the governance anchor. Target: complete before any technical work begins. Estimated timeline: 2-4 weeks for organisations with an existing ICT risk governance structure.

Step 2: Asset inventory and CBOM (Articles 8 and 9). Run automated discovery against production environments to identify all cryptographic protocols, algorithms, key sizes, and certificates in use. Categorise by function criticality and data confidentiality lifetime. Output: a CBOM ranked by HNDL risk exposure. Target completion: 60-90 days for a mid-size financial entity with a defined scope; longer for complex multi-cloud or acquired-entity estates. NIST NCCoE SP 1800-38B provides the phased implementation guidance for discovery tooling deployment.

Step 3: Risk assessment and migration prioritisation (Articles 6 and 9). Apply the Mosca inequality to each CBOM item. Priority tier 1: data with confidentiality lifetime exceeding 10 years that is currently protected by RSA or ECDH key exchange. This includes client records, transaction histories, and proprietary trading data. Priority tier 2: long-lived signing keys including CA root keys, code signing infrastructure, and document authentication certificates. Priority tier 3: shorter-lived operational data where re-encryption or re-keying is operationally feasible within a normal maintenance cycle. Output: a prioritised migration backlog. Target: complete within 30 days of CBOM completion.

Step 4: Hybrid deployment on priority tier 1 assets (Article 9). Deploy hybrid TLS 1.3 key exchange combining X25519 with ML-KEM-768 on connections protecting priority tier 1 data flows. ML-KEM-768 public key size is 1,184 bytes; ciphertext size is 1,088 bytes; ML-DSA-65 signature size is 3,309 bytes. For financial transaction flows at typical message sizes, these overheads are within acceptable bounds. IETF RFC 9496 (X-Wing hybrid KEM) specifies the mechanism. Hybrid deployment provides immediate HNDL protection for new traffic without requiring full migration of downstream infrastructure. This is the step that moves the programme from assessment to measurable risk reduction. Target: deploy on highest-risk flows within 90 days of completing Step 3.

Step 5: Third-party due diligence uplift (Article 28). Issue a questionnaire to all tier-1 ICT service providers. The five questions from the supply chain PQC vendor evaluation framework cover the key dimensions: algorithm inventory, NIST IR 8547 alignment timeline, FIPS 140-3 validation status, hybrid mode support, and crypto-agility architecture. Incorporate PQC roadmap requirements into contract renewal and new procurement documentation under the DORA Article 28 and RTS 2024/1773 basis. For strategic preparedness framing across the full programme, see the companion piece on DORA quantum security and financial services preparedness. Target: questionnaire issued to tier-1 providers within 30 days of completing Step 4; contract language incorporated at next renewal cycle.