For EU financial entities, the Digital Operational Resilience Act (DORA) cryptography is no longer a background technical detail. It is a binding legal obligation. Under DORA, encryption, key management, and certificate discipline are now controls that examiners can ask you to prove.
The stakes are concrete. DORA has applied since January 17, 2025, and it reaches roughly 22,000 entities across the EU. The most serious infringements can carry fines of up to 10% of an entity’s annual global turnover.
This guide walks through what DORA actually requires for cryptography and PKI, which articles matter, and what assessors probe. It is written for the security and compliance leaders who now have to turn these requirements into evidence.
What DORA is and why it exists
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, is the EU’s directly applicable regulation for managing ICT risk in the financial sector. Because it is a regulation rather than a directive, it applies uniformly across member states with no national transposition step.
DORA entered into force on January 16, 2023, and became applicable on January 17, 2025. You can read the full text on EUR-Lex.
The regulation is commonly described in terms of five pillars:
- ICT risk management
- ICT-related incident management, classification and reporting
- Digital operational resilience testing
- ICT third-party risk management, including direct EU oversight of providers designated as critical
- Information and intelligence sharing,
Cryptographic controls run through the first, third and fourth of these pillars, as a dedicated section of the ICT risk management Regulatory Technical Standard (RTS), as part of what resilience must cover, and as assurance questions about providers. PKI is the direct framing of how these obligations are met in practice.
Who DORA applies to
DORA reaches three broad audiences, and each has a distinct role in cryptographic compliance.
- Financial entities: roughly 22,000 organizations across 20 categories, including banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues, and central counterparties. Not all in scope are treated alike. Some small non entities may fall under a simplified framework, so it is important to know what are the exact requirements for your organization.
- Critical ICT Third-Party Providers (CTPPs): major technology suppliers, including hyperscale cloud platforms. EU authorities designated the first CTPPs in November 2025, bringing them under direct oversight.
- Management bodies: boards and senior leaders who approve the ICT risk management framework and bear ultimate responsibility for it.
That last point matters. Cryptographic governance is now a board-level accountability, not just an operational task.
Why DORA cryptography compliance matters now
Enforcement is intensifying. Beyond the 10% turnover ceiling on fines, national authorities began collecting annual Registers of Information on ICT third-party arrangements in 2025. Supervisors now have structured visibility into who provides your critical services.
The third-party dimension is the sharpest change. Because DORA extends cryptographic assurance to your vendors, your own compliance increasingly depends on evidence you can extract from them.
Readiness remains uneven. Many in-scope institutions are still not fully compliant, which leaves a meaningful gap between what DORA requires and what most programs can currently prove.
How DORA maps to cryptography and PKI
The core of DORA compliance is turning broad resilience language into specific cryptographic controls. The sections below walk through each control area with an answer-first view of what your entity must do.
DORA Article 9: strong authentication and key protection
Article 9(4)(d) requires strong authentication mechanisms and protection of the cryptographic keys that underpin them. In practice, this points toward phishing-resistant, certificate-based authentication rather than shared secrets.
The obligation has two halves. You must deploy strong authentication, and you must protect the keys and certificates that make it trustworthy.
RTS Article 6: the encryption and cryptographic controls policy
RTS Article 6 requires a documented, risk-based policy on encryption and cryptographic controls. The policy has to cover data at rest, data in transit, and, where feasible, data in use.
Crucially, the policy cannot stand alone. It must be tied to your approved data classification scheme and to the results of your ICT risk assessment, so protection scales with the sensitivity of the data.
Article 6(4) adds a forward-looking duty: the policy must provide for updating or changing cryptographic technology as cryptanalysis advances, and entities that cannot, must adopt mitigation and monitoring measures instead.
Article 6(5) requires those exceptions to be recorded with a reasoned explanation, that is, an auditable register of where your cryptography falls short of leading practice.
RTS Article 7: cryptographic key lifecycle management
RTS Article 7 requires formal management of cryptographic keys across their full lifecycle. Keys must be protected against loss, unauthorized access, and disclosure at every stage.
The article also demands operational readiness for failure. You need documented procedures to replace keys that are lost, compromised, or damaged, without disrupting critical services.
The certificate and key-storing device register
RTS Article 7(4) to (5) calls for a current register of every certificate and every certificate-storing device that supports critical or important functions. This is a living inventory, not a one-time spreadsheet.
The register also has to support automated renewal well ahead of expiry, so that an unnoticed expired certificate never becomes an operational outage. Article 7(5) requires propmt renewal of certificates in advance of expiry which, at the scale of modern certificate estate, automation is the only way to make that reliable and to evidence it for an auditor.
RTS Articles 20 and 21: access control and identity management
Together, Articles 20 and 21 require you to give every person and system a single verified identity, then grant it only the access it needs. Authentication strength, review frequency, and automation all scale with how critical the asset is.
Article 20 builds the identity. It requires one unique identity per account, covering both your own staff and your ICT providers’ staff, managed across a full lifecycle from creation to termination. It reaches systems as well as people, making it the strongest machine-identity hook in the RTS. It also requires identity records to survive reorganizations and the end of a contract.
Article 21 controls what that identity can reach. It requires least privilege, segregation of duties, no anonymous or shared accounts, and physical access controls. Its sharpest edges are a six-month review cycle for anything supporting critical or important functions, and four triggers for strong authentication: remote access, privileged access, critical or important functions, and publicly accessible assets.
DORA Articles 28 to 30: third-party cryptographic assurance
Articles 28 to 30 govern ICT third-party risk. For cryptography, that means building a component inventory that feeds vendor risk assessments and shapes the contractual provisions in your ICT agreements.
Those same agreements populate the Register of Information. When a supplier’s cryptographic controls are weak, that weakness becomes your compliance problem, so vendor evidence has to be part of the contract.
DORA Articles 24 to 27: resilience testing of cryptographic assets
Articles 24 to 27 bring cryptography into the scope of digital operational resilience testing. Certificate infrastructure and cryptographic controls should be tested, not assumed to work.
For significant entities, this extends to threat-led penetration testing (TLPT). Cryptographic assets are fair game for the same rigorous, intelligence-driven testing applied to the rest of your critical systems.
Preparing for a DORA examination: what assessors probe
DORA examinations are evidence-focused. Use this checklist to self-assess against the questions supervisors are most likely to ask.
- Encryption policy: Can you produce a documented, risk-based policy tied to data classification and risk assessment results?
- Key lifecycle: Can you show how keys are protected and replaced across their full lifecycle?
- Certificate register: Is your register of certificates and certificate-storing devices current, and does it drive automated renewal?
- Authentication: Do your authentication mechanisms meet the strength and phishing-resistance expectations for critical functions?
- Third-party assurance: Can you evidence cryptographic due diligence and contractual provisions for your ICT providers?
- Resilience testing: Do your testing and TLPT scopes include cryptographic and certificate infrastructure?
If any answer is “not yet,” that gap is where an examination will apply pressure.
Looking ahead: crypto-agility and post-quantum readiness
DORA does not mandate post-quantum cryptography today. But its crypto-agility expectations, expressed through the key and certificate discipline in RTS Articles 6 and 7, point toward the same foundation a future post-quantum migration will demand.
That foundation is a complete cryptographic inventory plus the ability to rotate and reissue keys and certificates at estate scale. Entities that build this discipline for DORA now will be far better positioned when quantum-safe migration moves from planning to execution.
In other words, the work you do to satisfy DORA today is the same work that de-risks your post-quantum transition tomorrow.
How Keyfactor can help
Keyfactor’s platform maps directly to the DORA cryptographic controls above, so the evidence you need comes from one place rather than a patchwork of tools.
- Keyfactor AgileSec: builds the third-party cryptographic inventory and assurance that Articles 28 to 30 require.
- EJBCA: supports cryptographic key lifecycle management and certificate-based strong authentication across devices, workloads, and users.
- Keyfactor Command: delivers identity management, policy visibility, and the certificate and key-storing device register DORA expects, with automated renewal ahead of expiry. This becomes an essential component in preparation for examinations and audits.
These capabilities unite in the Keyfactor Trust Control Plane, a single system of record that observes, analyzes, provisions, orchestrates, and governs cryptographic assets. When DORA evidence lives in one control plane, examinations become a reporting exercise rather than a fire drill.
Next steps:
DORA compliance is an ongoing operating capability, not a one-time project. The regulation applies now, enforcement is real, and cryptographic controls sit at the center of it.
If you are starting or maturing your program, four steps build durable momentum:
- Gain complete visibility into your cryptographic assets.
- Document a risk-based encryption and cryptographic controls policy.
- Formalize key lifecycle management, including replacement procedures.
- Build and automate your certificate and key-storing device register.
Ready to see where you stand? Request a Demo to assess your DORA cryptographic readiness with Keyfactor.
Got DORA cryptography questions? We’ve got answers.
When did DORA start applying to financial entities?
DORA entered into force on January 16, 2023, and has applied since January 17, 2025. Because it is directly applicable across all EU member states, there was no national transposition and no further transitional period.
Who does DORA apply to?
DORA covers roughly 22,000 financial entities across 20 categories, from banks and insurers to payment institutions and crypto-asset service providers. It also reaches Critical ICT Third-Party Providers and the management bodies that approve the ICT risk management framework.
What does DORA require for encryption?
Under RTS Article 6, entities need a documented, risk-based policy on encryption and cryptographic controls covering data at rest, in transit, and in use. That policy must be tied to approved data classification and ICT risk assessment results.
What does DORA say about cryptographic key management?
RTS Article 7 requires formal management of cryptographic keys across their full lifecycle, protecting them against loss, unauthorized access, and disclosure. It also requires documented procedures to replace lost, compromised, or damaged keys.
Do I need a certificate register under DORA?
Yes. RTS Article 7(4) to (5) calls for a current register of every certificate and certificate-storing device supporting critical or important functions. The register must support automated renewal well ahead of expiry.
What are the penalties for DORA non-compliance?
The most serious infringements can carry fines of up to 10% of an entity’s annual global turnover. Enforcement is intensifying, and national authorities began collecting annual Registers of Information on ICT third-party arrangements in 2025.
How does DORA affect my third-party providers?
DORA extends cryptographic assurance to ICT third parties under Articles 28 to 30, so your compliance depends on evidence you can extract from vendors. In November 2025, EU authorities designated the first Critical ICT Third-Party Providers subject to direct oversight, including major cloud platforms.
How does DORA connect to post-quantum readiness?
DORA’s crypto-agility expectations point toward the same foundation a future post-quantum migration will need: a complete cryptographic inventory and the ability to rotate keys and certificates at scale. Building that discipline now supports both DORA today and post-quantum migration ahead.
