# DORA: Cryptography Requirements for EU Financial Entities **Source**: https://quantumsequrity.com/blog/dora-financial-cryptography **Category**: Compliance & Regulation --- [← Back to Blog](../../blog.html) Compliance & Regulation # DORA: Cryptography Requirements for EU Financial Entities 11 min read The Digital Operational Resilience Act, formally Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022, became directly applicable across the European Union on 17 January 2025. Unlike the NIS2 Directive, DORA is a regulation, which means it applies uniformly without national transposition. Financial entities subject to DORA share one cryptography baseline, one supervisory framework, and one set of penalties. DORA was drafted in response to the operational risk landscape that emerged after the 2008 financial crisis, the Wirecard collapse, and the steady stream of ransomware events that have hit banks, insurers, and payment institutions through the late 2010s and early 2020s. Cryptography is not the dominant theme of DORA, but it is a mandatory pillar of the ICT risk-management framework that every covered entity must build. This article explains who DORA applies to, what Articles 9 and 10 say about cryptography, what the Regulatory Technical Standards (RTS) on ICT risk management add, and how the post-quantum migration is becoming a DORA compliance topic. ## Who DORA Covers Article 2 of DORA enumerates the financial entities in scope. The list is long and deliberately inclusive: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers (after MiCA), central securities depositories, central counterparties, trading venues, trade repositories, AIFMs, UCITS management companies, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and ICT third-party service providers. The combined population is more than 22,000 financial entities across the EU, plus the non-EU ICT third-party service providers that supply them. DORA includes a critical ICT third-party service provider designation under Article 31 that brings cloud providers, managed security service providers, and other infrastructure suppliers under direct supervision by the European Supervisory Authorities (EBA, ESMA, EIOPA). Recital 79 and Article 33 establish a Joint Examination Team mechanism for oversight of designated CTPPs. Microsoft, Amazon Web Services, Google Cloud, IBM, Oracle, and several other major providers have either been designated or are in the designation pipeline. ## The Five Pillars of DORA DORA is structured around five pillars set out in Articles 5 to 50: 1. ICT risk management (Articles 5-15). 2. ICT-related incident management, classification, and reporting (Articles 17-23). 3. Digital operational resilience testing (Articles 24-27), including threat-led penetration testing. 4. Managing ICT third-party risk (Articles 28-44). 5. Information sharing arrangements (Article 45). Cryptography sits inside pillar one. Articles 9 and 10 are the load-bearing provisions. ## Article 9: ICT Security Mechanisms Article 9 of DORA is titled "Protection and prevention." Paragraph 1 requires financial entities to continuously monitor and control the security and functioning of ICT systems and tools, and to minimise the impact of ICT risk through deployment of appropriate ICT security tools, policies, and procedures. Paragraph 2 requires financial entities to design, procure, and implement ICT security policies, procedures, protocols, and tools that aim to ensure the resilience, continuity, and availability of ICT systems and to maintain high standards of availability, authenticity, integrity, and confidentiality of data. Paragraph 3 requires financial entities to put in place and maintain mechanisms ensuring high standards of confidentiality, integrity, and authenticity of data. Paragraph 3(c) explicitly requires the use of "strong authentication mechanisms based on relevant standards and dedicated control systems." Paragraph 4 covers data and system security, including: - (a) policies and procedures to ensure data confidentiality, integrity, and availability; - (b) measures to prevent information leakage; - (c) the implementation of policies that limit the physical or logical access to information assets and ICT assets only to what is required for legitimate and approved functions; - (d) implementation of policies and protocols for strong authentication mechanisms; - (e) implementation of policies, procedures, and controls for ICT change management; - (f) implementation of policies for ICT projects and systems acquisition, development, and maintenance. The cryptography obligation is implicit but pervasive. Confidentiality, integrity, authenticity, and strong authentication all require cryptographic primitives. The detail comes in the RTS. ## Article 10: ICT-Related Incident Detection and Response Article 10 requires financial entities to have mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents. Detection capabilities must enable layered protection and provide alerts based on triggers and criteria. In a cryptographic context, this includes detecting compromised keys, anomalous certificate use, deprecated algorithm use in production paths, and protocol downgrade attempts. ## The RTS on ICT Risk Management The European Supervisory Authorities published Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, the Regulatory Technical Standards specifying the ICT risk management framework requirements. The RTS came into force alongside DORA on 17 January 2025. Article 6 of the RTS requires policies and procedures on cryptography and key management. Specifically, financial entities must: - maintain an inventory of cryptographic algorithms, protocols, and applications, including identification of those algorithms that are not state-of-the-art; - assess the use of cryptography against the protection objectives (confidentiality, integrity, authenticity, non-repudiation); - consider, when designing cryptographic solutions, leading practices and emerging risks, including risks arising from the development of quantum computing capabilities. The reference to quantum computing risk is explicit. The RTS does not require post-quantum cryptography to be deployed today, but it requires the risk to be assessed and to be considered in the design of cryptographic solutions. For financial entities with long-lived data such as mortgage records, life insurance contracts, and pension data, that assessment will conclude that "harvest now, decrypt later" is a present-day risk requiring action. Article 7 of the RTS adds key management requirements: secure generation, distribution, storage, archival, retrieval, and destruction of cryptographic keys; secure replacement of compromised keys; recovery of encrypted information in the absence of available keys; and segregation of duties. Article 8 specifies physical and logical security measures for cryptographic key material, including the use of hardware security modules where appropriate. ## What "State of the Art" Means for DORA The RTS, like NIS2, uses the phrase "state of the art" without defining specific algorithms. ENISA, BSI, ANSSI, and the European Banking Authority all publish guidance that fills the gap. For financial entities in 2026, the state-of-the-art cryptographic baseline includes: For data in transit: TLS 1.3 with ECDHE_X25519 or ECDHE_P-256, AES-256-GCM or ChaCha20-Poly1305, with hybrid post-quantum extensions where supported. The IETF draft for hybrid TLS key exchange (X25519MLKEM768) has been deployed by Cloudflare and Google in production. For data at rest: AES-256 in GCM mode, with key wrapping using AES-KW (RFC 3394) or RFC 5649. Database column-level encryption for personally identifiable information. For digital signatures: ECDSA P-256, EdDSA Ed25519, or RSA-PSS with 3072-bit keys minimum. Long-term signature schemes increasingly require hybrid ML-DSA or SLH-DSA constructions. For key derivation: HKDF (RFC 5869) with SHA-256 or SHA-3. For password hashing: Argon2id (RFC 9106) or scrypt (RFC 7914). For random number generation: NIST SP 800-90A Rev. 1 DRBGs with SP 800-90B-validated entropy sources. The European Banking Authority's Guidelines on ICT and security risk management (EBA/GL/2019/04) explicitly reference "leading market practices" for cryptography, and the EBA has issued opinions during 2024 and 2025 that reference the post-quantum migration. For the underlying NIST standards, see [NIST FIPS Guide](../../blog/nist-fips-guide.html). For the algorithm details, see [ML-KEM Explained](../../blog/ml-kem-explained.html) and [ML-DSA vs SLH-DSA](../../blog/mldsa-vs-slhdsa.html). ## Incident Reporting Under DORA Articles 17 to 23 establish the incident reporting framework. Article 19 requires financial entities to report "major" ICT-related incidents to their competent authority. Article 20 establishes the timelines: - Initial notification: as soon as possible but not later than 4 hours after classification as a major incident, with a maximum hard limit of 24 hours from awareness; - Intermediate report: 72 hours after the initial notification; - Final report: not later than one month after the initial notification. Commission Delegated Regulation (EU) 2024/1772 specifies the criteria for classifying incidents as "major." A cryptographic compromise affecting a primary control, an unauthorised disclosure of personal data protected by cryptography that is suspected to have been compromised, or a key management failure that affects the confidentiality of payment data can all qualify. ## Threat-Led Penetration Testing Articles 24 to 27 introduce mandatory advanced testing for "significant" financial entities. The testing framework, known as TLPT, builds on the TIBER-EU framework that several Member States have run since 2018. Tests must be conducted at least every three years, must use threat intelligence relevant to the entity, and must cover production systems. Cryptographic implementations are within the scope of TLPT. A test might attempt to exploit weak random number generation, downgrade attacks against TLS, key exposure in cloud environments, or compromised certificates. ## Critical ICT Third-Party Providers Articles 28 to 44 cover ICT third-party risk. Article 28 requires financial entities to manage ICT third-party risk as an integral component of overall ICT risk. Article 30 specifies contractual provisions including monitoring rights, audit rights, and termination rights. Article 31 designates "critical" ICT third-party service providers. Designated CTPPs are subject to direct oversight by the relevant European Supervisory Authority (EBA, ESMA, or EIOPA depending on sector). Microsoft, AWS, Google Cloud, and several SaaS providers are in scope. For cryptography, this matters because the CTPP regime brings the supplier's cryptographic posture into the financial entity's risk picture. A bank that relies on a cloud provider for key management must be able to demonstrate that the provider's cryptographic implementation is state of the art and that the provider has a credible post-quantum migration plan. ## Penalties Article 50 of DORA empowers competent authorities to impose administrative penalties and remedial measures. Penalty levels are set at the Member State level, but Article 50(2)(b) requires that they be "effective, proportionate, and dissuasive." Some Member State implementations have set penalty caps comparable to GDPR, with administrative fines reaching the higher of EUR 10 million or 2 percent of total annual turnover. ## Practical Compliance Roadmap Inventory cryptography. Article 6 of the RTS requires it. Capture algorithm, key length, key custodian, system, data category, and data lifetime. Map to data lifetimes. Mortgage data may need confidentiality for 25 years. Life insurance for 50 years. Pension data for the lifetime of the beneficiary plus heirs. Retail banking transaction data for 7-10 years. Identify post-quantum exposure. Any data with confidentiality lifetime extending past 2035 is at material risk under the harvest-now-decrypt-later threat model. See [Mosca's Theorem Worked Examples](../../blog/moscas-theorem-worked-examples.html). Build a hybrid migration plan. Hybrid ML-KEM with classical ECDH for key establishment, hybrid ML-DSA with classical for signatures, AES-256-GCM for symmetric. See [Hybrid Encryption](../../blog/hybrid-encryption.html). Update contracts with CTPPs. Require post-quantum readiness commitments and audit rights covering cryptographic implementation. Test. TLPT cycles should include cryptographic attack scenarios. ## FAQ **Is DORA the same as NIS2?** No. DORA is a regulation that applies directly to financial entities. NIS2 is a directive that requires national transposition and applies to a broader set of sectors. Where they overlap, DORA is generally lex specialis for financial entities. **Does DORA require post-quantum cryptography?** Article 6 of the RTS on ICT risk management requires financial entities to consider quantum computing risks when designing cryptographic solutions. This is a planning obligation today and is increasingly being read as a deployment obligation for systems handling long-lived data. **What is the deadline?** DORA was directly applicable from 17 January 2025. There is no further grace period. **How do I report incidents?** Major incidents are reported to the competent authority designated under each Member State, in the format specified by Commission Delegated Regulation (EU) 2024/1772 and ITS for incident reporting templates. **Are non-EU banks affected?** Non-EU financial entities operating in the EU through a branch or subsidiary are within scope. Non-EU ICT third-party service providers can be designated as critical and subjected to direct oversight. ## Sources - Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 (DORA), https://eur-lex.europa.eu/eli/reg/2022/2554/oj - Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 (RTS on ICT risk management), https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj - Commission Delegated Regulation (EU) 2024/1772 (RTS on classification of major incidents), https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj - European Banking Authority Guidelines on ICT and security risk management EBA/GL/2019/04, https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-ict-and-security-risk-management - BSI Technical Guideline TR-02102-1, https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-02102/tr-02102.html - NIST FIPS 203, FIPS 204, FIPS 205 (August 2024), https://csrc.nist.gov/projects/post-quantum-cryptography ## Related Articles - [NIS2 Directive Cryptography](../../blog/nis2-directive-cryptography.html) - [GDPR PQC Alignment](../../blog/gdpr-pqc-alignment.html) - [PQC Financial Services](../../blog/pqc-financial-services.html) - [Hybrid Encryption](../../blog/hybrid-encryption.html) - [NIST FIPS Guide](../../blog/nist-fips-guide.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)