DORA for banks: cryptography, post-quantum risk and what supervisors will ask
Why banks are first in line
- Long-lived confidential data. Customer identities, account histories, credit files and anti-money-laundering records must be kept for years after a relationship ends, and loan files can run for decades. Anything captured in transit today under RSA or elliptic-curve key exchange is exposed to harvest-now-decrypt-later attacks for that whole period.
- Long-lived infrastructure. Payment HSMs, card platforms, core banking systems and interbank connections are replaced on cycles measured in years, and each change needs certification, scheme approval or counterparty coordination.
- Dense interdependence. A bank cannot migrate alone: card schemes, payment systems, market infrastructures, cloud providers and fintech partners all sit on the other end of its cryptography.
- A regulation that names cryptography. DORA and its technical standards make encryption, cryptographic controls and key management explicit supervisory topics.
The financial sector’s own bodies have said as much. The G7 Cyber Expert Group published a statement in September 2024 urging financial institutions to start planning for quantum computing risks, and the EU post-quantum roadmap expects inventories by the end of 2026 and high-risk use cases migrated by the end of 2030. For a bank, most payment and customer-data flows are high-risk use cases.
What DORA requires for cryptography
DORA (Regulation 2022/2554) has applied since 17 January 2025. Its ICT risk-management chapter is made concrete by the RTS in Delegated Regulation 2024/1774. The provisions that bear on cryptography:
| Provision | What it means for cryptography | Evidence to prepare |
|---|---|---|
| DORA Art. 5 Governance | The management body is responsible for the ICT risk-management framework, so quantum risk is a board topic, not only a CISO one. | Board briefing on cryptographic and quantum exposure, with decisions and owners minuted. |
| DORA Art. 8 Identification | ICT assets and information assets must be identified, classified and documented. Cryptographic assets are part of that picture. | A cryptographic inventory linked to the ICT asset inventory and to data classification. |
| DORA Art. 9 Protection and prevention | Protect data at rest, in use and in transit; strong authentication; protection of cryptographic keys, with encryption based on data classification and risk assessment. | Mapping of data classes to the cryptography that protects them, with gaps listed. |
| RTS Art. 6 Encryption and cryptographic controls | A documented policy on encryption and cryptographic controls, driven by classification and risk, covering data at rest, in transit and in use, and providing for cryptographic technology to be updated as cryptanalysis develops. | The policy itself, plus a record showing how quantum cryptanalysis is monitored and what triggers a change. |
| RTS Art. 7 Cryptographic key management | Key management across the whole lifecycle, and a register of certificates and certificate-storing devices, at least for assets supporting critical or important functions, with timely renewal. | Key-management procedures and a current certificate register, ideally generated rather than maintained by hand. |
| DORA Art. 28 ICT third-party risk | Contractual arrangements and the register of information on ICT third-party providers. Much of a bank’s cryptography runs inside vendor products and services. | Supplier post-quantum roadmaps, tracked against the register, and PQC clauses in new contracts. |
| DORA Art. 24–27 Testing | Resilience testing, and threat-led penetration testing for designated entities, will test cryptographic weaknesses like any other control. | Findings on weak or deprecated cryptography closed or accepted with a documented rationale. |
The RTS clause on updating cryptographic technology as cryptanalysis develops is the regulatory hook for post-quantum migration and crypto-agility: a bank that cannot say where its RSA and elliptic-curve cryptography is, cannot show it is ready to update it. For the general reading of Article 9, see DORA Article 9 and the cryptographic inventory.
Where cryptography hides in a bank
- Payments and cards: payment HSMs, PIN and key-management processes, and card authentication, which relies on RSA certificates issued within the card schemes.
- Open banking and partner APIs: TLS endpoints and the eIDAS certificates used for PSD2 access, plus API signing and token keys.
- Interbank and market connections: messaging networks, clearing and settlement links, and the PKI and HSMs behind them.
- Digital channels: mobile and web banking, including app and code signing, device binding and customer authentication.
- Core banking and data platforms: database and backup encryption, key stores, batch file transfers and the internal service-to-service TLS that rarely appears in an architecture diagram.
- Cloud key management: keys held in cloud KMS services and the workloads that use them.
- Vendor products: cryptography inside packaged software and appliances, which you can only see through supplier disclosure, ideally a CBOM.
What supervisors are likely to ask
Significant institutions are supervised by the ECB under the Single Supervisory Mechanism; others by their national competent authority, such as the ACPR in France. In our reading of DORA and the RTS, a review of cryptographic controls will come down to a handful of questions:
- Show us your encryption and cryptographic-controls policy, and how it follows from data classification.
- Where is cryptography used for the systems that support critical or important functions, and how do you know?
- Show us the certificate register and how expiring certificates are caught.
- How do you monitor developments in cryptanalysis, including quantum computing, and what have you decided as a result?
- Which of your critical ICT third-party providers have a post-quantum roadmap, and where is it recorded?
- What did your last resilience or penetration test find about cryptography, and what happened next?
None of these needs a finished post-quantum migration. All of them need an inventory, a policy that refers to it and a plan. Our CISO readiness checklist covers the same ground in more detail.
A 90-day plan for a bank
| Weeks | Do | Output |
|---|---|---|
| 1–4 | Pick one critical or important function, for example card payments or online banking. Inventory its cryptography across code, certificates and endpoints. Collect supplier statements for the products it depends on. | A first CBOM and certificate list for that function; a supplier tracker. |
| 5–8 | Link findings to data classes and retention periods. Score each asset by quantum risk and HNDL exposure. Separate production cryptography from test code and vendored libraries. | A risk-ranked list, with the long-retention flows at the top. |
| 9–12 | Update the cryptographic-controls policy to reference the inventory and post-quantum monitoring. Draft a migration roadmap in waves. Brief the management body. Add PQC requirements to new contracts. | Updated policy, a wave-based roadmap, a board paper and contract clauses. |
Then extend function by function, and regenerate the inventory on every release so the evidence stays current. Our guide to estimating the blast radius of a migration covers how to turn the inventory into waves and effort.
Where CRYPTAGION fits
CRYPTAGION builds the inventory part of this evidence. It discovers cryptography in Python, JavaScript/TypeScript, Java, Go and C/C++ source code, X.509 certificates and live TLS endpoints, with the file and line or endpoint of every finding and a scope tag that separates production code from tests and vendored code. It scores each asset by quantum risk and HNDL exposure using a per-path sensitivity policy, exports a schema-validated CycloneDX 1.6 CBOM, and produces a board-ready PDF mapped to DORA, NIS2, the EU CRA and FIPS 203/204/205, with a wave-based roadmap. The Platform tier adds scans of AWS KMS, Azure Key Vault and GCP KMS, and a CI gate that stops new weak cryptography. It runs on-premises or air-gapped (deployment and data flow).
What it does not see: mainframe languages such as COBOL, cryptography configured inside HSMs, and binaries or container images, which are on our roadmap. Those parts of a banking estate need supplier disclosure and manual review alongside any tool; ask every vendor the same question, using our CBOM tool evaluation checklist.
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 5, 8, 9, 24–28
- Commission Delegated Regulation (EU) 2024/1774 (ICT risk-management RTS), Articles 6 and 7
- Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography
- G7 Cyber Expert Group, statement on planning for the opportunities and risks of quantum computing (September 2024)
This page reflects a practitioner reading of DORA and its RTS; it is not legal advice. Confirm obligations with your compliance and legal teams. CRYPTAGION supports compliance activities; using it does not by itself establish regulatory compliance.
See it on a banking-style stack
In a 30-minute demo we run CRYPTAGION live on a public repository that matches your stack and show the CBOM, the risk scores and the roadmap. No access to your code needed.
Request a free demo →