How should organisations prepare identity controls for DORA compliance?

Why This Matters for Security Teams

DORA changes the question from “can identity be controlled?” to “can identity-dependent services keep operating, recover, and prove it under stress?” That is a much harder test. Identity is not a sidecar to resilience planning; it is part of the regulated service chain. If directory services, PAM, certificate issuance, secrets storage, or machine identity infrastructure fail, the business may lose access even when the application stack is healthy.

The practical risk is that many organisations still assess identity as a policy issue instead of a continuity dependency. Current guidance suggests that non-human identities are already a major exposure area: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities, while the 52 NHI Breaches Analysis is useful for understanding how quickly machine credentials become an operational issue once attackers reach them. For DORA, the relevant control question is whether those identity services are mapped, monitored, and recoverable in a way that supports critical functions.

That is why identity teams should align with resilience, not sit beside it. The EU Digital Operational Resilience Act (DORA) expects firms to demonstrate operational resilience, while NIST Cybersecurity Framework 2.0 reinforces the need to understand dependencies and restore services after disruption. In practice, many security teams discover their identity recovery gaps only after an outage or audit exception has already exposed them.

How It Works in Practice

Start by treating identity services as tier-one dependencies for each critical business service. Map which services rely on directory lookups, privileged access workflows, federation, secrets managers, certificate authorities, and workload identities. Then define recovery objectives for each identity component, not just for the application that consumes it. A service may be “up” but unusable if its token issuer is down or its break-glass path is not recoverable.

For DORA evidence, the key is to show that identity controls are both preventive and recoverable. That means documenting who can approve emergency access, how privileged roles are restored, how service accounts are reissued, and how secrets are rotated after disruption. It also means proving that your fallback paths are tested. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for lifecycle discipline, while the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps translate identity work into audit-ready evidence.

• Map critical services to identity dependencies, including admin access, machine identity, and secrets storage.
• Define recovery steps for each dependency, including reissue, rotation, and break-glass access.
• Test restore paths with realistic drills, not tabletop assumptions alone.
• Keep evidence of approvals, timings, and post-drill remediation for audit review.

Where this guidance breaks down is in environments with tightly coupled legacy directories or unmanaged service accounts, because recovery often depends on undocumented manual steps and credentials that cannot be safely reconstituted.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, so organisations must balance resilience against speed of recovery. That tradeoff becomes more visible when the business runs hybrid estates, shared admin models, or high-churn cloud workloads. There is no universal standard for identity recovery design yet, so best practice is evolving around evidence, repeatability, and short-lived access rather than fixed process templates.

One common edge case is machine identity sprawl. Service accounts, API keys, and certificates can outnumber human identities by a wide margin, which makes manual recovery unreliable. Another is third-party access, where an external dependency may be critical to restoration but outside direct control. In these cases, the control objective should be explicit: know which external identities can affect your critical services, how quickly they can be revoked or replaced, and what fallback exists if federation fails.

For organisations using automation or agentic systems, identity design should also account for autonomous behaviour. That means preferring short-lived credentials, strong workload identity, and runtime policy checks over static permissions that assume predictable use. The practical lesson is simple: if a credential or token can persist beyond the service event it supports, it is also a resilience risk. The Top 10 NHI Issues and DORA both point toward the same operational reality: identity must be designed for continuity, not just admission. In many real estates, the failure mode is not a policy gap but an expired assumption that emergency access will work when the usual control plane is already impaired.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• When should organisations prioritise NHI security over other identity work?
• When should organisations review external data shares as part of identity governance?
• How should security teams govern non-human identities for compliance?