Why do identity systems matter so much under DORA?

Why This Matters for Security Teams

DORA treats identity as an operational dependency because authentication, authorisation, and recovery all sit on the same resilience path. If credentials fail, access review lags, or delegated admin breaks, the firm may still have infrastructure but lose the ability to use it safely. That is why identity systems matter so much: they are the control plane for continuity, not just an access layer.

The risk is amplified by non-human identities. NHI Management Group research shows that 52 NHI Breaches Analysis and the Ultimate Guide to NHIs both point to over-privileged service accounts, leaked secrets, and weak rotation as repeat failure modes. Under DORA - Digital Operational Resilience Act, those weaknesses are not isolated hygiene issues. They become business continuity problems when restore, failover, or emergency access depends on identities that were never designed for disruption.

In practice, many security teams discover identity fragility only after a recovery exercise exposes broken admin paths, stale secrets, or missing break-glass access rather than through intentional testing.

How It Works in Practice

Identity under DORA should be handled as part of resilience engineering. That means mapping which identities are required for core services, which ones are needed to restore them, and which ones can be revoked or narrowed during an incident. Human accounts, machine identities, API keys, service accounts, and privileged automation all need separate treatment because they fail differently and recover differently.

Current guidance suggests that firms should combine EU Digital Operational Resilience Act (DORA) expectations with identity controls such as privileged access management, rotation, and offboarding discipline. For NHIs, the practical model is to maintain visibility into where credentials exist, how long they remain valid, and who or what depends on them. The Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references for linking those controls to audit evidence.

• Use least privilege for both human and non-human identities, then validate it against recovery scenarios.
• Rotate secrets on a schedule that matches operational risk, not convenience.
• Document break-glass access and test it during resilience exercises.
• Track service accounts, API keys, and delegated admin paths as recovery-critical assets.

Where teams are moving toward agentic automation, static role models also become brittle. Autonomous workloads may need just-in-time access, workload identity, and runtime policy checks rather than broad standing permissions. These controls tend to break down when legacy directories, hard-coded secrets, and unmanaged third-party integrations still depend on long-lived credentials.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance recovery speed against governance discipline. That tradeoff is real for DORA programmes because emergency access, regulatory evidence, and system restoration often compete under pressure.

One common edge case is third-party and outsourced access. If vendors hold privileged accounts, DORA resilience testing must verify not only internal recovery but also whether external identities can be disabled, reissued, or constrained quickly enough. Another is environments with heavy automation: CI/CD pipelines, orchestration tools, and AI agents may need ephemeral secrets or runtime-issued tokens, but there is no universal standard for this yet. Best practice is evolving toward context-aware authorisation, short-lived credentials, and workload identity rather than persistent shared secrets.

For regulated firms, the operational question is not whether identity is important, but whether identity can be restored under stress without widening exposure. That is why practitioners should treat identity dependencies as part of incident response, backup planning, and control testing, not as a separate IAM project. In the field, weak identity design usually shows up first during a failed failover, a stuck privilege change, or an emergency login that nobody can validate quickly enough.

Related resources from NHI Mgmt Group

• How should organisations prepare identity controls for DORA compliance?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• Why do dashboards matter in NHI governance?