The Digital Operational Resilience Act reads like financial regulation, which means most of the people who have to comply with it are lawyers and risk officers, and most of what has been written about it is legal commentary. That is a problem, because the parts of DORA that will actually trip up a financial entity are operational. They land on the teams that run certificate renewals, manage HSMs, rotate keys, and answer the pager when TLS stops negotiating. Those teams rarely read the regulation, and the regulation rarely speaks their language.
This post translates DORA’s cryptographic expectations into the operations they imply. It does not restate the articles. It asks a simpler question: if a supervisor walked into your operation tomorrow and asked you to demonstrate that your cryptography is under control, what would you have to show, and what would quietly fail. DORA applies broadly across the EU financial sector, from banks and insurers to trading venues and the ICT providers that serve them, so the operational burden described here is not narrow.
What DORA Actually Expects of Cryptography
DORA sits on a framework of ICT risk management, incident reporting, resilience testing, and third-party oversight. Cryptography threads through all four. The regulation and its technical standards expect a financial entity to have a policy for cryptographic controls, to manage keys across their full lifecycle, to keep that cryptography current against emerging risk, and to treat a cryptographic failure as the operational incident it is.
Stripped of the legal framing, that becomes a short list of things an operation must be able to do:
- Know every cryptographic key and certificate it depends on, and who owns each one.
- Manage each one through its whole lifecycle, from generation to destruction, with controls at every stage.
- Detect and respond to a certificate or key failure as a reportable ICT incident, within defined timelines.
- Extend the same expectations to the ICT third parties that hold or use cryptography on the entity’s behalf.
- Demonstrate all of the above to a supervisor, with evidence, on request.
Each of those is an operational capability, not a document. A policy that says keys are rotated regularly is worthless at examination if the operation cannot produce the rotation history. This is where the gap between legal compliance and operational compliance opens, and it is wider than most programs assume.
Compliance Gap: Required vs. Actual Certificate Coverage
What frameworks require vs. what organizations typically demonstrate
The average enterprise demonstrates 35% certificate coverage against framework requirements that expect 85-95%. This gap is where audit findings live.
Key Management as a Lifecycle, Not a Policy
DORA’s technical standards expect cryptographic keys to be managed across their entire lifecycle, with controls appropriate to each stage. Translated into operations, that means a financial entity has to be able to account for a key from the moment it is generated to the moment it is destroyed, and prove that each transition happened under control.
The lifecycle stages map to concrete operational obligations:
| Lifecycle Stage | Operational Obligation | Evidence a Supervisor Expects |
|---|---|---|
| Generation | Keys created with approved algorithms and sufficient entropy, in controlled environments | Generation records, HSM logs, algorithm policy |
| Distribution | Keys moved only through protected channels | Transport mechanism, access records |
| Storage | Private keys protected, ideally in hardware | HSM or key vault attestation |
| Usage | Keys used only for their intended purpose by authorized systems | Access control, usage logs |
| Rotation | Keys replaced on a defined schedule or on compromise | Rotation history with timestamps |
| Revocation | Compromised or retired keys invalidated promptly | Revocation records, CRL or OCSP evidence |
| Destruction | Retired key material securely destroyed | Destruction confirmation |
The recurring failure is not having a policy for these stages. It is being unable to produce the evidence for a specific key when asked. An operation that rotates keys on a schedule but keeps no durable history of rotations satisfies the policy and fails the examination. DORA’s operational demand is for a system of record that answers “show me the lifecycle of this key” without a scramble.
The Algorithm Currency Problem
DORA also expects cryptography to stay current against emerging risk, and the emerging risk regulators are now explicitly naming is quantum. The operational implication is that a financial entity cannot treat its algorithm choices as settled. It needs to know which of its keys and certificates use algorithms that are weakening, and it needs a path to migrate them. An operation that cannot enumerate its RSA-2048 and ECDSA usage cannot demonstrate it is managing the emerging risk DORA asks it to manage. The inventory that key lifecycle management requires is the same inventory a post-quantum migration will need.
Certificate Governance as Operational Resilience
Certificates are where DORA’s operational-resilience intent meets most organizations’ weakest control. A certificate is a key with an expiry date and a trust chain, and its failure modes are precisely the operational disruptions DORA exists to prevent. An expired certificate on a payment gateway is not a compliance paperwork issue. It is an outage, which is exactly the resilience event the regulation targets.
Certificate governance under DORA means an operation can answer, continuously:
- What certificates exist, and where. A complete, current inventory, not a spreadsheet updated quarterly. Unknown certificates cannot be governed, and the ones that cause outages are almost always the ones nobody knew about.
- When each one expires, and who renews it. Ownership and expiry tracking with enough lead time that renewal is routine rather than an emergency.
- Whether any have failed or are about to. Monitoring that surfaces impending expiry and detects failures fast enough to meet incident timelines.
- How renewals and revocations are controlled. Change control over certificate operations, because an uncontrolled renewal is as much a resilience risk as a missed one.
The resilience framing changes how to prioritize this. A certificate on a critical payment or trading function is a higher-impact resilience risk than one on an internal tool, and DORA’s proportionality expects controls scaled to impact. An operation that governs all certificates uniformly, or governs none of them systematically, is misaligned with what the regulation actually asks.
ICT Third-Party Risk: Cryptography You Do Not Control
DORA’s third-party provisions are among its sharpest, and cryptography is deeply embedded in them. A financial entity remains accountable for operational resilience even when the ICT function sits with a provider. For cryptography, that means the entity is responsible for cryptographic controls it does not directly operate.
Operationally, this raises questions most vendor management programs have never asked:
- Does the provider manage the cryptographic keys that protect our data to a standard equivalent to our own lifecycle controls?
- Can the provider tell us which algorithms and key sizes protect our workloads, and are any of them weakening?
- If a certificate or key the provider manages fails, how and how fast will we be told, and does that meet our own incident-reporting obligations?
- Can we obtain evidence of the provider’s cryptographic controls, or are we trusting an assertion?
The hard cases are the providers who cannot answer. A financial entity that cannot get cryptographic transparency from a critical provider has a DORA gap it does not fully control, and closing it means either extracting that transparency contractually or treating the opacity as a documented, owned risk. The regulation does not accept “the vendor handles it” as the end of the entity’s responsibility.
When Crypto Fails: Incident Reporting
DORA’s incident-reporting regime is where cryptographic operations meet a clock. A major ICT-related incident must be reported to the competent authority within defined timelines, with an initial notification early, an intermediate update as understanding develops, and a final report once the incident is resolved and its root cause understood.
A certificate expiry that takes down a customer-facing service, a key compromise that forces emergency revocation, a failed rotation that breaks authentication across a system, each of these can be a major incident under DORA’s classification. The operational consequence is that cryptographic failures must be detected fast enough to start the reporting clock on time, classified correctly against DORA’s thresholds, and documented well enough to produce the root-cause analysis the final report requires.
This is where weak certificate and key operations become a regulatory liability rather than merely an availability problem. An operation that learns about an expired certificate from a customer complaint has already lost the detection time DORA’s timeline assumes. One that cannot reconstruct why a key failed cannot produce the final report. The incident regime effectively mandates the monitoring and the system of record that good cryptographic operations would have anyway, and penalizes the absence of them when something breaks.
Closing the Gap Before an Examination
The through-line of DORA’s cryptographic expectations is that each one demands an operational capability backed by evidence, and the capabilities reinforce each other. A complete certificate and key inventory supports lifecycle management, which supports incident detection, which supports timely reporting, which is exactly what a supervisor examines. An entity that builds the inventory and the system of record once satisfies most of the regulation’s cryptographic surface at the same time.
The entities that will struggle at examination are not the ones with imperfect policies. They are the ones whose operations cannot produce evidence on demand: the rotation that happened but was never recorded, the certificate that renewed but whose history is gone, the provider whose cryptographic controls are an assertion rather than an artifact. DORA rewards operations that can show their work, and the way to be ready is to run cryptography as a governed, recorded, monitored lifecycle before anyone asks to see it.
FAQ
Q: Does DORA actually mention certificates and keys, or am I reading that in? DORA and its regulatory technical standards require a policy on cryptographic controls and management of cryptographic keys across their lifecycle, and the broader framework treats ICT disruptions, which an expired certificate plainly is, as the resilience events it governs. The operational reading is not an interpretation stretch; it is what the controls require you to be able to do in practice.
Q: Is a cryptographic policy document enough to comply? No. DORA is a resilience regulation, and resilience is demonstrated operationally. A policy that cannot be backed by evidence, the rotation history, the inventory, the revocation records, the incident timeline, fails at examination even if the document is immaculate. The regulation expects you to show the capability, not just assert it.
Q: How does DORA affect cryptography handled by our cloud or ICT providers? The entity stays accountable for resilience even when a provider operates the ICT function. For cryptography that means obtaining transparency into the provider’s key and certificate controls, establishing how provider-side cryptographic failures are communicated within your reporting timelines, and either securing evidence of those controls or documenting the opacity as an owned risk.
Q: Can a certificate expiry really be a reportable incident? Yes, if it causes a disruption that meets DORA’s major-incident thresholds. A certificate failure that takes down a customer-facing or critical service can trigger the reporting obligations and their timelines, which is why detection speed and root-cause documentation for cryptographic failures are operational necessities, not nice-to-haves.
Q: Where does the quantum threat fit into DORA? DORA expects cryptography to stay current against emerging risk, and quantum is the emerging risk regulators now name. Operationally this means maintaining an inventory of which keys and certificates use weakening algorithms and having a migration path. The same inventory that lifecycle management requires is the one a post-quantum migration will draw from.
About QCecuring
QCecuring helps financial entities turn DORA’s cryptographic expectations into operations that can withstand an examination. Our platform maintains a continuous inventory of every certificate and key, records the full lifecycle of each one, monitors for failures fast enough to meet incident timelines, and extends that visibility to the cryptography your ICT providers manage on your behalf.
Align your cryptographic operations with DORA
Tags: DORA, Compliance, Certificate Lifecycle Management, Key Management, Financial Services, ICT Risk, Third-Party Risk, Incident Reporting, Operational Resilience, HSM, Certificate Governance, EU Regulation, Post-Quantum Cryptography