DORA Article 9 & cryptographic resilience: why it starts with a crypto inventory

A practical guide for security and GRC teams at EU financial entities.

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied to EU financial entities since January 2025. Most teams have read the headline requirements on ICT risk management, incident reporting and third-party risk. Fewer have worked out what DORA means concretely for their cryptography — and that gap is where audits get uncomfortable.

What Article 9 actually asks for

Article 9 (“Protection and prevention”) sits inside DORA’s ICT risk-management framework. It requires financial entities to design and implement policies and controls that protect the security of information and ICT systems — including the confidentiality, integrity and availability of data in transit, in use and at rest. In practice, that means cryptographic controls: encryption, signing, certificate and key management.

The detail lives in the Regulatory Technical Standards (Commission Delegated Regulation (EU) 2024/1774). The RTS expects a documented policy on encryption and cryptographic controls, driven by data classification and risk assessment, with cryptographic key management — and, crucially, a requirement to account for the state of the art and to plan for updating cryptographic techniques “where relevant.” That last clause is the regulatory hook for crypto-agility and post-quantum migration.

You cannot write — or evidence — a credible cryptographic-controls policy for an estate you have never inventoried.

The inventory is the missing foundation

Every downstream obligation assumes one thing nobody has by default: a reliable, current map of where cryptography lives across your code, certificates and live TLS endpoints. Which algorithms? Which key sizes and curves? Which are already weak (MD5, SHA-1, RSA-1024), which are quantum-vulnerable (RSA, ECDSA, ECDH), and which are at risk under harvest-now-decrypt-later (HNDL) because the data they protect must stay confidential for a decade or more?

Without that inventory you cannot:

• demonstrate to an auditor what cryptography you operate and where;
• classify exposure by data sensitivity and confidentiality lifetime;
• prioritise remediation by risk rather than by guesswork;
• produce a defensible migration roadmap to post-quantum standards.

CBOM: the inventory in a standard format

A Cryptographic Bill of Materials (CBOM) — the CycloneDX 1.6 Crypto-BOM — is the emerging standard for expressing this inventory in machine-readable form. It is to cryptography what an SBOM is to software dependencies: a portable, tool-agnostic artefact your GRC platform can ingest and your auditors can read. Because it is an open standard, it does not lock you into any single vendor, and the evidence outlives the tool that produced it.

Beyond DORA: NIS2, the CRA and FIPS 203/204/205

The same inventory serves more than one regulation. NIS2 (Article 21) expects risk management measures including cryptography and encryption. The EU Cyber Resilience Act pushes cryptographic accountability into products. And on the technical side, NIST has finalised the post-quantum standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) — which define the algorithms your migration roadmap will target. One inventory, mapped once, feeds all of these.

A practical first step

You do not need a multi-year platform rollout to start. Pick one critical application domain, run discovery against its code, certificates and endpoints, and produce a first CBOM plus a risk-scored, wave-based migration roadmap. That single baseline is usually enough to turn an abstract DORA requirement into a concrete, defensible plan.

This article is informational and reflects a practitioner reading of DORA and its RTS; it is not legal advice. Always confirm obligations with your compliance and legal teams.

← All resources · Home