DORA compliance and identity resilience: what practitioners need

At a glance

What this is: This is an overview of DORA compliance and its intersection with identity threat detection and response, with a central finding that identity resilience is now part of operational resilience.

Why it matters: It matters because IAM and NHI controls are no longer supporting controls alone. They are now part of the evidence financial entities and ICT providers must be able to show under DORA.

By the numbers:

• The regulation may require periodic penalty payments of 1% of average daily global turnover for up to 6 months.

👉 Read Semperis's analysis of DORA compliance and identity resilience

Context

DORA is a compliance regime for operational resilience, but the identity angle is where many programmes will feel the pressure first. In practice, that means access controls, recovery procedures, and the ability to prove that identity systems can survive disruption all become part of the regulatory conversation, not just internal security best practice.

For IAM and NHI practitioners, the hard part is that identity infrastructure is both control plane and dependency. If Active Directory, delegated access, service accounts, or recovery pathways fail, the business can lose both authentication and the ability to restore it. That is why the topic belongs in governance planning, not only in incident response. The starting position described in the source is common, not exceptional.

DORA also pushes teams to treat third-party and fourth-party exposure as part of the same risk surface. That matters for NHI governance because service accounts, secrets, and authentication dependencies often cross organisational boundaries faster than teams can map them.

Key questions

Q: How should organisations prepare identity controls for DORA compliance?

A: They should treat identity systems as regulated dependencies and build evidence around them. That means mapping critical services to directory, privileged access, and machine identity dependencies, then proving those services can be restored through realistic drills. The goal is not just access control. It is recoverable access control under disruption.

Q: Why do identity systems matter so much under DORA?

A: Identity systems matter because they determine whether a firm can authenticate users, authorise actions, and restore access after disruption. If Active Directory, delegated access, or machine credentials fail, operational resilience fails with them. Under DORA, identity is part of the business continuity problem, not a separate technical layer.

Q: What is the difference between compliance testing and identity recovery testing?

A: Compliance testing checks whether controls exist and are documented. Identity recovery testing checks whether access, privilege, and authentication actually return during a real outage or cyber event. For DORA, the second matters more because the regulation is interested in proven resilience, not policy existence.

Q: Should teams include NHI governance in DORA programmes?

A: Yes, because machine identities often sit inside the same authentication and access pathways that DORA expects firms to protect and recover. Service accounts, API keys, and privileged automation can become single points of failure if they are not inventoried, rotated, and recoverable. DORA-ready programmes should govern NHI alongside human access.

Technical breakdown

How DORA turns identity infrastructure into a regulated dependency

DORA frames ICT risk as a documented, testable management problem. For identity teams, that means the authentication layer, directory services, delegated administration, and recovery tooling are no longer just operational conveniences. They become regulated dependencies because they determine whether critical services can be restored after disruption. The practical challenge is not only protecting identity systems, but proving that they can be monitored, recovered, and governed under stress. In NHI environments, that includes service accounts, privileged roles, and machine credentials that may be embedded in business workflows. If those identities are not visible and recoverable, operational resilience claims are weak.

Practical implication: Map identity services into the regulated dependency set and test their recovery under realistic failure conditions.

Why live drills matter for Active Directory and privileged access

The source emphasises live drills because paper recovery plans do not show whether identity dependencies actually work. Active Directory and similar systems are especially sensitive because they manage authentication, authorisation, and resource allocation at once. If recovery is only partial, or if dependent systems are excluded from the test, the organisation can pass a checklist while failing in practice. For NHI governance, this creates a specific requirement: recovery must include service account continuity, credential validity, and privilege restoration. Otherwise, the organisation may restore infrastructure while still being unable to authorise critical workloads or administrators.

Practical implication: Include service accounts, delegated access, and privilege restoration in every identity recovery drill.

Zero Trust fails when delegation and identity hygiene drift

Zero Trust depends on continuous verification, but the source correctly notes that identity compromise undermines even strong perimeter assumptions. In directory-heavy environments, configuration creep, over-permissioned groups, and unmanaged delegation create paths for privilege escalation that bypass design intent. For NHI practitioners, the issue is broader than human authentication. Machine identities often accumulate standing permissions, long-lived secrets, and unclear ownership, which makes them hard to verify continuously. That is why zero trust and identity hygiene must be managed together. Without control over delegation and machine credentials, Zero Trust becomes a policy statement rather than an enforceable model.

Practical implication: Review delegation paths, standing privilege, and machine credentials as part of every Zero Trust programme.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity resilience is now a compliance control, not an adjacent security goal. DORA changes the interpretation of identity from an internal technical dependency to a regulated operational asset. That shift matters because access recovery, directory health, and credential governance now influence whether an organisation can demonstrate resilience. Practitioners should treat identity controls as evidence-bearing controls, not only preventative ones.

Durable compliance will depend on reducing identity blast radius. The practical problem is not only whether an organisation can recover, but what it must recover from after a failure. Excess privilege, unclear ownership, and long-lived credentials expand the blast radius of identity incidents and complicate recovery tests. The field should expect stronger emphasis on least privilege, lifecycle management, and recovery scope. Teams should design for smaller failure domains, not just faster restore times.

Third-party ICT dependencies make NHI governance a supply chain issue. DORA explicitly reaches beyond the financial entity itself, which means machine identities used by vendors and service providers come into scope through the same resilience lens. That widens the accountability problem: if a contractor, platform provider, or managed service depends on opaque credentials, the regulated entity still owns the risk. Practitioners should inventory external identity dependencies as rigorously as internal ones.

Configuration drift is the hidden control failure behind many identity resilience gaps. The source repeatedly points to manual error, delegation creep, and brittle recovery assumptions. Those are not isolated hygiene issues. They are signs that identity has become too dynamic for static governance. The discipline now required is continuous validation of roles, groups, backups, and recovery pathways. Teams should expect auditors to ask how drift is detected, not whether a policy exists.

DORA is accelerating the convergence of IAM, PAM, and NHI governance. The regulation does not let organisations separate user access, privileged access, and machine access into unrelated programs. In resilience terms, they are one control problem with different identity types. Practitioners should align those functions around a common recovery and assurance model so that service accounts, admin access, and authentication infrastructure are governed consistently.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For lifecycle controls and remediation planning, see Ultimate Guide to NHIs and Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Identity resilience will increasingly be measured as a business continuity capability, not a back-office control. For security teams, that means recovery objectives must extend to authentication, delegation, and privileged access paths. If those paths cannot be rebuilt quickly, the programme is not DORA-ready, regardless of how mature the incident response plan looks on paper.

Configuration drift is becoming a governance signal, not just an operations nuisance. When identity state changes faster than teams can review it, both compliance and resilience degrade. Practitioners should expect more scrutiny on how quickly service accounts, groups, and delegated permissions can be reconciled after change.

With 91.6% of secrets still valid five days after notification, remediation latency is already long enough to widen blast radius before teams can respond. That makes identity inventory, rotation, and recovery verification central to DORA programme design.

For practitioners

• Inventory identity-dependent critical services Map which business services rely on directory services, delegated access, service accounts, and authentication recovery. Include external dependencies so the team can see where a single identity failure could stop a regulated service.
• Test identity recovery with live drills Run recovery exercises that include realistic privilege restoration, credential validation, and dependent system recovery. Do not treat directory restoration as successful until access and authorisation are working end to end.
• Reduce standing privilege across human and machine identities Review privileged groups, service account entitlements, and admin delegation paths. Remove unnecessary standing access and document who can restore access during an incident.
• Bring third-party identities into scope Include ICT vendors, managed service providers, and outsourced identity functions in the same risk and recovery model. Ask whether external credentials, admin access, and recovery steps are testable by the regulated entity.

Key takeaways

• DORA pulls identity systems into the centre of operational resilience because access recovery now affects regulatory evidence.
• The biggest gap is not policy language but recoverability, especially for directory services, privileged access, and machine identities.
• Teams that can inventory, test, and restore identity dependencies will be better positioned than teams that rely on static compliance artefacts.

Key terms

• Digital Operational Resilience Act: DORA is an EU regulatory framework that requires financial entities and their critical ICT providers to prove they can withstand, respond to, and recover from disruption. For identity teams, it turns authentication, access, and recovery into evidence-bearing controls rather than background IT functions.
• Identity Threat Detection and Response: ITDR is the practice of detecting abuse of identity systems and responding before access paths are used for deeper compromise. In NHI environments, it extends beyond human accounts to service accounts, tokens, delegated access, and machine credentials that can be misused at scale.
• Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
• Delegation Drift: Delegation drift is the gradual accumulation of excessive or outdated access in groups, roles, and admin pathways. It weakens governance because identity state changes faster than teams review it, creating privilege escalation paths that are easy to miss during normal operations.

Deepen your knowledge

DORA compliance and identity resilience are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from a similar starting point, it is worth exploring.

This post draws on content published by Semperis: DORA Compliance and ITDR Identity Threat Detection & Response. Read the original.