Blog · Regulation
DORA Article 9(4)(d): Evidence or Process?
Article 9(4)(d) of Regulation (EU) 2022/2554 asks for strong authentication mechanisms and protection of cryptographic keys. A supervisory review asks a harder question: when it matters, can the control produce evidence, or can it only produce process?
Requirement One: Strong authentication
Article 9(4)(d) requires financial entities to implement strong authentication mechanisms. Most production implementations satisfy this at the session boundary. A person authenticates once, strongly, and a session inherits that strength for everything that follows.
The regulation's text is satisfied. The regulation's intent is tested later, when a privileged action inside a valid session is exactly what an incident review has to explain. A per-action, hardware-bound biometric signature moves the strength to where the risk is: the action.
Requirement Two: Protection of cryptographic keys
The same provision requires protection of cryptographic keys. A key held in application memory is protected by policy. A key generated inside the Secure Enclave or StrongBox is protected by construction: it is non-exportable, it cannot be exercised without the enrolled human's biometric, and a change to the biometric enrollment destroys it.
On the verification side the keys are published, so any examiner can check a proof without trusting the entity or the vendor.
The supervisory question
A supervisory review does one thing repeatedly: it asks how you know. How do you know who authorized the privileged change. How do you know the log was not edited afterward. A process answer points at a policy document. An evidence answer produces an artifact.
A hash-chained ledger is that artifact: every authoritative action chained to the prior one, daily anchors, and a property a reviewer can test directly, because altering one record breaks every record after it.
Independent verifiability closes the loop. The examiner verifies ES256 signatures against a published key, on their own machine, with no trust in the audited party.
What DORA does not require
Stated plainly: DORA does not mandate per-action proof. Nothing in Article 9 names a signature per transaction, and a compliant program can exist without one.
The argument here is narrower and economic. When the review asks how you know who authorized a specific action, a per-action, hardware-bound signature is the cheapest answer that is evidence. Every alternative answer is a process, and processes are argued while artifacts are checked.
Common questions
Does DORA require per-action signatures?
No. The regulation requires strong authentication and key protection; it does not prescribe the mechanism. The claim is that per-action proof is the least expensive way to make the evidence question boring.
What does an examiner actually review?
Artifacts: the hash-chained ledger, its chain integrity, and proof signatures verified against a published key. None of it requires trusting the entity's own tooling.
Does this replace our ICT risk-management framework?
No. It supplies the evidence layer inside the framework you already run. Policies, testing, and governance stay yours.
Keep reading
See it on your own flow.
Your app, your call, our SDK.