DORA cryptography requirements in one page: Article 9, RTS 2024/1774 Articles 6 and 7, third-party key custody and the evidence auditors ask for.
DORA cryptography requirements come from two texts. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) asks for protection of cryptographic keys and encryption based on data classification and ICT risk assessment (Article 9(4)(d)). The RTS on the ICT risk management framework (Delegated Regulation (EU) 2024/1774) turns that into a written policy on encryption and cryptographic controls (Article 6) and a key management policy covering the full key lifecycle (Article 7).
Both have applied to EU financial entities since 17 January 2025. DORA does not prescribe algorithms. It asks you to decide, document and prove who can use your keys, how they are managed, and how you will change cryptography when it weakens.
This page summarises what the texts require, where cloud and third-party key custody fits, and what evidence supervisors and auditors ask for. For an article-by-article walk-through of Articles 9 to 13 with a full checklist, see the DORA encryption technical checklist.
| Source | Requirement | What to have ready |
|---|---|---|
| DORA Art. 9(2) | ICT security policies, procedures, protocols and tools that protect availability, authenticity, integrity and confidentiality of data | An approved encryption policy, part of your ICT security policies |
| DORA Art. 9(4)(d) | Strong authentication and protection of cryptographic keys; encryption based on data classification and ICT risk assessment | Data classification with a key model per class |
| RTS Art. 6(2) | Encryption of data at rest and in transit, data in use where necessary, internal network connections and external traffic | Encryption coverage per asset class, with exceptions recorded |
| RTS Art. 6(3) | Criteria for selecting cryptographic techniques, based on leading practices and standards | Documented selection criteria and approved algorithm list |
| RTS Art. 6(4) | Provisions to update or change cryptographic technology as cryptanalysis develops | A crypto-agility process, including post-quantum migration |
| RTS Art. 6(5) | Mitigation and monitoring measures recorded with a reasoned explanation | A deviation register |
| RTS Art. 7 | Key management across the lifecycle: generation, renewal, storage, backup, archiving, retrieval, transmission, retirement, revocation, destruction | Key management policy, replacement procedure for lost or compromised keys |
| RTS Art. 7 | Register of certificates and certificate-storing devices, at least for assets supporting critical or important functions; renewal before expiry | A current certificate inventory with owners and expiry monitoring |
| DORA Art. 28 and 30 | Third-party risk: contracts covering data location and confidentiality, exit strategies for critical or important functions | A record of which provider can decrypt which data, and how you would leave |
DORA's text on cryptography is short. Chapter II (ICT risk management, Articles 5 to 16) requires an ICT risk management framework, and Article 9 ("Protection and prevention") is where cryptography appears:
The last clause matters most. Encryption under DORA is not "encrypt everything with anything": the strength of the control follows the classification of the data. Article 15 then mandated the European Supervisory Authorities to specify the detail, which became the RTS below.
Commission Delegated Regulation (EU) 2024/1774 is where auditors find testable requirements.
Financial entities must develop, document and implement a policy on encryption and cryptographic controls, based on approved data classification and ICT risk assessment. The policy sets rules for:
It must also set criteria for choosing cryptographic techniques based on leading practices and standards, provide for updating or changing cryptographic technology when cryptanalysis requires it, and record any mitigation measures with a reasoned explanation where the entity cannot follow those practices. That update clause is DORA's crypto-agility requirement, and the reason post-quantum migration belongs in a DORA programme.
The key management policy must cover the whole key lifecycle (generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking and destroying keys) and controls that protect keys against loss, unauthorised access, disclosure and modification. Entities must have a method to replace keys that are lost, compromised or damaged, keep a register of certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions, and renew certificates before they expire. In practice the register is a certificate inventory kept current by discovery and expiry monitoring.
DORA's third-party chapter (Articles 28 to 44) asks financial entities to manage ICT third-party risk, including concentration risk, and to keep exit strategies for services that support critical or important functions. Article 30 requires contracts to state where data is processed and to include provisions on the availability, authenticity, integrity and confidentiality of data.
Encryption keys sit at the centre of that question. If the same provider stores the data and holds the key that decrypts it, one party can unlock production, and the contract describes how it intends to behave rather than what it is able to do. Customer-held key models reduce that dependency:
| Model | Who can decrypt | DORA relevance |
|---|---|---|
| Provider-managed keys | The provider | Simplest; provider remains a single point of control |
| BYOK (key imported into the provider's KMS) | The provider, once the key is imported | Lifecycle control, but the provider holds the key |
| HYOK / external key store | The provider only through a live call to your key service | You see, log and can refuse each key use; supports exit and incident containment |
| Client-side encryption (e.g. Microsoft 365 Double Key Encryption) | Only you | Strongest separation; loses provider features such as search on that data |
Choose the model per data class, as Article 9(4)(d) requires. Most firms keep provider-managed keys for low-risk data and reserve HYOK or client-side encryption for the data behind critical or important functions.
Policies alone do not pass an audit. Useful artefacts include:
If these records only exist inside a cloud provider's console, the evidence is outsourced along with the infrastructure.
DuoKey is a Swiss key management platform. For DORA programmes it provides:
See the DORA compliance page for the full mapping.
Q: What are the DORA cryptography requirements?
DORA Article 9(4)(d) requires protection of cryptographic keys and encryption based on data classification and ICT risk assessment. Delegated Regulation (EU) 2024/1774 adds the detail: an encryption and cryptographic controls policy (Article 6) and a key management policy covering the full lifecycle, a key replacement method and a certificate register (Article 7).
Q: Does DORA require specific encryption algorithms?
No. Article 6 of the RTS requires criteria based on leading practices and standards, and a way to update cryptographic technology as cryptanalysis develops. Most firms refer to national and European guidance, such as NIST and ENISA publications, and record their approved algorithms in the policy.
Q: Does DORA require post-quantum cryptography?
Not by name. The obligation to update or change cryptographic technology when cryptanalysis develops (RTS Article 6(4)) means firms need a plan to replace algorithms that quantum computers will weaken, starting with an inventory of where RSA and elliptic-curve cryptography are used.
Q: Does DORA say who must hold encryption keys in the cloud?
No rule says keys must stay in-house. DORA does require managing ICT third-party and concentration risk and keeping exit strategies for critical or important functions. Holding keys outside the provider (HYOK or client-side encryption) is a common way to show that a single provider cannot unlock critical data alone.
Q: What is the certificate register required by DORA?
RTS Article 7 requires a register of certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions, and renewal before expiry. In practice this is a certificate inventory with owners, locations and expiry dates, kept current by discovery and monitoring.
Q: Since when do these requirements apply?
DORA and Delegated Regulation 2024/1774 have applied since 17 January 2025.
Geschrieben von
DuoKey
Related Resources
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
