Who is accountable when identity controls fail under DORA?

Accountability sits with the institution, not just the IAM team. Financial firms must show that identity services, governance processes, and recovery paths were designed and tested as part of operational resilience, because DORA evaluates whether the business can withstand disruption, not whether a tool was installed.

Why This Matters for Security Teams

Under DORA, identity control failure is not treated as a narrow IAM defect. It is an operational resilience issue that can interrupt authentication, privileged access, incident response, and recovery workflows at the same time. That means accountability extends beyond the tool owner to the institution that must prove controls were designed, governed, tested, and recoverable under stress.

This is especially important for NHIs because service accounts, API keys, and agent identities often sit in the path of critical business services. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames the audit problem clearly: the issue is not whether credentials existed, but whether ownership, rotation, revocation, and recovery were operating as a managed control set. In practice, many security teams encounter control gaps only after a production outage, failed recovery, or privilege abuse has already forced the question of who owned the failing identity path.

How It Works in Practice

DORA accountability is assigned at the institution level, but operational ownership is distributed. Security, IAM, infrastructure, application, risk, and business continuity teams each contribute evidence that identity controls can survive disruption. For NHIs, that evidence should show who approves access, who rotates secrets, who monitors anomalous use, and who can revoke or replace credentials during an incident.

Current guidance suggests treating identity as part of resilience engineering, not just access administration. That means documenting service ownership, mapping critical identities to business services, and testing whether recovery remains possible when a key provider, vault, directory, or federation path fails. It also means demonstrating that secrets are not only stored, but retrievable, replaceable, and revocable within recovery time objectives. NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the pattern: identity failures usually become material when they are embedded in production dependencies, not when they appear in policy documents.

• Assign a named business and technical owner to each critical NHI.
• Test secret rotation, revocation, and fallback access during resilience exercises.
• Keep evidence that IAM dependencies were included in incident and recovery plans.
• Ensure privileged access paths remain observable during degraded operations.

For regulatory interpretation, EU Digital Operational Resilience Act (DORA) emphasizes resilience outcomes rather than tool deployment, so the institution must be able to show control effectiveness under disruption. These controls tend to break down when identity services are tightly coupled to a single vault, directory, or cloud control plane because recovery becomes dependent on the same service that failed.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance resilience evidence against speed of change. That tradeoff is real in firms with many application teams, outsourced operations, or hybrid estates where no single group controls the full identity lifecycle.

There is no universal standard for this yet, but best practice is evolving around shared accountability: the institution owns compliance, service owners own the identities embedded in their systems, and control operators own the mechanics of rotation, monitoring, and recovery. Edge cases appear when a third-party platform manages the identity store, when break-glass access is undocumented, or when an NHI is reused across multiple business services. In those situations, DORA scrutiny will usually focus on whether the firm can still demonstrate governance, traceability, and restoration capability if the control plane is partially unavailable.

NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it distinguishes the identity object from the operating context. That distinction matters: a single leaked secret, such as those highlighted in DeepSeek breach, can become a resilience event if revocation, replacement, and monitoring are not already established.

Related resources from NHI Mgmt Group

• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
• Who is accountable when identity controls fail under NIS2?
• Who is accountable when identity controls fail under NYDFS?
• Who is accountable when an AI agent or workflow executes privileged actions under a forged identity?