DORA (Digital Operational Resilience Act) is the EU’s answer to a financial sector that runs on interconnected digital systems but lacks consistent operational resilience standards. Effective January 17, 2025, it applies to virtually every financial entity in the EU — banks, insurers, investment firms, payment providers, crypto-asset service providers, and critically, the ICT third-party providers that serve them.
For cryptography and certificate management teams, DORA introduces specific requirements around encryption, key management, data integrity, and the resilience of cryptographic systems. This isn’t another checkbox exercise — DORA has teeth, with supervisory authorities empowered to impose penalties and restrict operations.
Who DORA Applies To
| Entity Type | Examples | Applies? |
|---|---|---|
| Credit institutions | Banks, building societies | Yes |
| Investment firms | Brokers, asset managers | Yes |
| Insurance/reinsurance | Insurers, pension funds | Yes |
| Payment institutions | Payment processors, PSPs | Yes |
| E-money institutions | Digital wallet providers | Yes |
| Crypto-asset service providers | Exchanges, custodians | Yes |
| Central counterparties | Clearing houses | Yes |
| Trade repositories | Transaction reporting | Yes |
| ICT third-party providers | Cloud providers, SaaS, managed services | Yes (oversight framework) |
| Credit rating agencies | Rating agencies | Yes |
Key point: DORA applies to ICT third-party service providers that serve financial entities. If you provide cloud hosting, managed PKI, certificate management, or key management services to EU financial institutions, DORA’s oversight framework applies to you.
DORA’s Cryptographic Requirements
DORA doesn’t prescribe specific algorithms (unlike PCI DSS). Instead, it mandates outcomes — resilient, tested, documented cryptographic controls. The requirements are spread across several articles:
Article 9: ICT Risk Management Framework
Financial entities must implement cryptographic controls as part of their ICT risk management:
| Requirement | Cryptographic Implication |
|---|---|
| Protect data in transit and at rest | TLS certificates on all systems, disk encryption |
| Ensure data integrity | Digital signatures, MACs, hash verification |
| Maintain confidentiality | Encryption key management, access controls |
| Implement access controls | Certificate-based authentication, mTLS |
| Detect anomalous activities | Certificate monitoring, key usage auditing |
Article 10: Detection
Article 11: Response and Recovery
| Requirement | Crypto Implementation |
|---|---|
| Activate response plans for ICT incidents | Certificate revocation procedures, key compromise response |
| Estimate impact of incidents | Cryptographic asset inventory (CBOM) to assess blast radius |
| Communicate to stakeholders | Documented key custodians and certificate owners |
| Restore ICT systems | Key backup/recovery, CA disaster recovery |
| Conduct post-incident reviews | Root cause analysis for crypto-related incidents |
Article 12: Backup and Restoration
| Requirement | Crypto Implementation |
|---|---|
| Backup ICT systems and data | Encrypted backups with managed keys |
| Test restoration regularly | Key recovery testing, CA rebuild procedures |
| Ensure backup integrity | Signed backups, hash verification |
| Separate backup from production | Separate key management for backup encryption |
Article 15: ICT Third-Party Risk
Financial entities must assess the cryptographic practices of their ICT providers:
- What encryption does the provider use for data at rest and in transit?
- How does the provider manage encryption keys?
- What happens to encryption keys when the contract ends?
- Can the entity access its data if the provider fails?
- Does the provider use FIPS-validated cryptographic modules?
Implementing DORA Cryptographic Controls
1. Cryptographic Asset Inventory
DORA requires knowing what cryptographic assets you have. A Cryptographic Bill of Materials (CBOM) provides this:
# DORA-compliant cryptographic inventory structure
cryptographic_assets:
certificates:
- id: "cert-001"
system: "Internet Banking Portal"
type: "TLS Server"
algorithm: "ECDSA P-256"
ca: "DigiCert"
expiry: "2026-08-15"
owner: "Platform Team"
criticality: "Critical"
data_classification: "Customer PII"
encryption_keys:
- id: "key-001"
system: "Core Banking Database"
type: "AES-256-GCM (TDE)"
kms: "AWS KMS"
rotation_period: "365 days"
last_rotated: "2026-02-01"
owner: "Database Team"
criticality: "Critical"
signing_keys:
- id: "sign-001"
system: "Payment Processing"
type: "RSA-4096"
hsm: "Thales Luna"
purpose: "Transaction signing"
owner: "Payments Team"
criticality: "Critical"2. Key Management Lifecycle (NIST SP 800-57 Aligned)
DORA expects key management aligned with recognized standards:
| Lifecycle Stage | DORA Requirement | Implementation |
|---|---|---|
| Generation | Secure, auditable key generation | HSM-based generation, ceremony documentation |
| Storage | Protected key storage | HSM, KMS, encrypted at rest |
| Distribution | Secure key transport | Key wrapping, TLS for transit, no plaintext |
| Use | Controlled, monitored usage | RBAC, usage logging, anomaly detection |
| Rotation | Regular key rotation | Automated rotation per crypto period |
| Archival | Secure long-term storage | Encrypted archives, access controls |
| Destruction | Irreversible destruction | Cryptographic erasure, documented |
3. Certificate Lifecycle Automation
4. Resilience Testing (Article 26-27)
DORA requires regular testing of ICT systems, including cryptographic controls:
| Test Type | Crypto Focus | Frequency |
|---|---|---|
| Vulnerability scanning | Weak ciphers, expired certs, protocol issues | Continuous |
| Penetration testing | Certificate validation bypass, key extraction | Annual |
| Scenario testing | CA compromise, mass certificate revocation | Annual |
| Threat-led testing (TLPT) | Advanced attacks on crypto infrastructure | Every 3 years |
| Disaster recovery | CA rebuild, key recovery from backup | Semi-annual |
DORA vs Other Financial Regulations
| Aspect | DORA | PCI DSS 4.0 | SOX | EBA Guidelines |
|---|---|---|---|---|
| Scope | All EU financial entities | Card payment processors | US public companies | EU banks |
| Crypto specificity | Outcome-based | Prescriptive (algorithms, key sizes) | Controls-based | Outcome-based |
| Key management | Required (no specific standard) | NIST SP 800-57 referenced | Documented controls | Required |
| Testing | TLPT every 3 years | Quarterly scans, annual pentest | Annual audit | Stress testing |
| Third-party | Oversight framework | Vendor compliance | SOC reports | Outsourcing guidelines |
| Incident reporting | 4-hour initial, 72-hour full | 72 hours (breach) | Material weakness | 2-4 hours |
| Penalties | Up to 1% of annual turnover | Up to $100K/month | Criminal liability | Supervisory measures |
| Effective | January 2025 | March 2025 | 2002 (ongoing) | Various |
Compliance Checklist
| # | Control | Evidence Required | Tool/Process |
|---|---|---|---|
| 1 | Cryptographic asset inventory | Complete list of all keys, certs, algorithms | CBOM / CLM platform |
| 2 | Encryption of data in transit | TLS configuration on all systems | Certificate monitoring |
| 3 | Encryption of data at rest | Key management documentation | KMS audit logs |
| 4 | Key lifecycle management | Rotation schedules, destruction records | KMS/HSM audit trail |
| 5 | Certificate lifecycle management | Automated renewal, expiry monitoring | CLM platform |
| 6 | Access controls for crypto operations | RBAC, approval workflows | IAM + audit logs |
| 7 | Incident response for crypto events | Revocation procedures, key compromise playbook | Documented runbooks |
| 8 | Third-party crypto assessment | Vendor encryption practices documented | Due diligence records |
| 9 | Resilience testing | Pentest results, DR test results | Test reports |
| 10 | Backup encryption | Key management for backups | Separate KMS/key hierarchy |
FAQ
Q: When does DORA enforcement begin?
DORA entered into force on January 16, 2023, with a compliance deadline of January 17, 2025. Financial entities should already be compliant. Regulatory Technical Standards (RTS) providing detailed implementation guidance were published throughout 2024.
Q: Does DORA require specific encryption algorithms?
No. Unlike PCI DSS, DORA doesn’t prescribe specific algorithms or key sizes. It requires “state of the art” cryptographic controls appropriate to the risk. In practice, this means following NIST or ENISA recommendations — AES-256, RSA-3072+, ECDSA P-256+, TLS 1.2+.
Q: How does DORA affect cloud service providers?
ICT third-party providers serving EU financial entities fall under DORA’s oversight framework. They must: (1) cooperate with supervisory authorities, (2) provide audit access, (3) maintain documented security practices including cryptography, (4) support data portability and exit strategies.
Q: What’s the penalty for DORA non-compliance?
Supervisory authorities can impose periodic penalty payments of up to 1% of average daily worldwide turnover. For critical ICT third-party providers, the Lead Overseer can impose fines up to €5 million (or 1% of turnover). Beyond fines, authorities can restrict operations or require remediation.
Q: Does DORA require a CBOM (Cryptographic Bill of Materials)?
Not explicitly by name, but Article 9’s requirement for ICT asset management and Article 11’s requirement to assess incident impact effectively mandate a cryptographic inventory. A CBOM is the structured way to satisfy these requirements.
Q: How does DORA interact with GDPR encryption requirements?
They’re complementary. GDPR Article 32 requires “appropriate technical measures” including encryption. DORA adds operational resilience requirements on top — not just “encrypt the data” but “ensure the encryption system is resilient, tested, and recoverable.” Meeting DORA’s crypto requirements generally satisfies GDPR’s encryption expectations.
Related Reading: