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.