DORA exposes identity as the core resilience control in finance

At a glance

What this is: This is an analysis of how DORA turns identity into a resilience control, with the key finding that fragmented IAM, NHI, and vendor-access practices become compliance and operational risk under audit scrutiny.

Why it matters: It matters because financial institutions need one governance model that spans human access, non-human identities, and third-party access if they want DORA-ready evidence, traceability, and incident response.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Unosecur's analysis of how DORA changes identity governance in finance

Context

DORA makes identity a resilience issue because every privileged login, service account, vendor federation, and API key can become part of the operational control surface. In practice, many financial entities still manage these assets as isolated IAM tasks rather than as evidence-backed controls that must survive audit, incident response, and regulatory challenge.

The failure mode is familiar: lifecycle steps are inconsistent, privilege decisions are hard to justify, and third-party access is treated as a relationship problem instead of a governed identity problem. Once DORA is applied, those weaknesses stop being hygiene issues and become structural resilience gaps.

This article is about that gap and why a unified identity security posture and identity threat detection approach matters for financial entities that need traceability across human, machine, and vendor identities.

Key questions

Q: How should financial institutions use identity governance for DORA and NIS2 compliance?

A: They should use identity governance as the evidence layer for access approval, review, and removal. The practical goal is to show that every entitlement has an owner, a business reason, and a lifecycle path. That makes compliance traceable and reduces the chance that stale access becomes an audit finding or operational weakness.

Q: Why do non-human identities create compliance risk even when policies exist?

A: Policies fail when machine credentials are created faster than teams can inventory and review them. NHIs often live in code, automation, and integrations that sit outside normal access review workflows, so the organisation can appear controlled while hidden access persists. The real risk is not missing paperwork but missing enforcement.

Q: What breaks when third-party access is not included in identity governance?

A: Auditability breaks first, followed by containment. Supplier accounts can remain active across multiple systems without clear ownership, which makes it difficult to prove who authorised access, whether it was still needed, and whether privileged activity was monitored throughout the relationship.

Q: Who is accountable when identity controls fail under DORA?

A: 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.

Technical breakdown

Why DORA exposes identity governance gaps

DORA does not prescribe a single identity architecture, but it assumes that access can be traced, justified, and reviewed across the full ICT environment. That is where many programmes break down. If entitlements live in spreadsheets, if access reviews are disconnected from policy, or if third-party identities are not inventoried, the organisation cannot prove resilience even when controls exist in fragments. Identity becomes the evidence layer for resilience, not just the authentication layer.

Practical implication: Practitioners should map every identity control to a DORA evidence requirement before the next audit cycle.

How overprivilege turns into resilience debt

Overprivilege accumulates when legacy roles, emergency access, and cross-cloud permissions are allowed to persist after the original need has passed. In regulated environments, that creates resilience debt because an account can be both operationally convenient and governance-poor at the same time. Behaviour-based privilege scoring helps surface these drifts, but the underlying issue is that privilege is often assigned faster than it is rationalised. The result is an access model that expands quietly and is difficult to unwind under audit pressure.

Practical implication: Inventory standing privilege and tie every elevated entitlement to a documented business or operational need.

What machine identities change in a DORA programme

Machine identities behave like infrastructure, but under DORA they must be governed like access subjects. Service accounts, API keys, and workload credentials often outnumber human accounts and frequently lack ownership, rotation, or telemetry. That creates a resilience blind spot because the most powerful credentials are also the least visible. If machine identities cannot be inventoried, rotated, and traced back to a control owner, they undermine both incident response and audit readiness.

Practical implication: Treat machine identity inventory and rotation as core resilience controls, not optional hardening tasks.

Threat narrative

Attacker objective: The attacker seeks durable access that can survive normal operational controls long enough to move, persist, or exfiltrate without immediate detection.

1. Entry occurs through identity sprawl, where a vendor account, service credential, or stale entitlement creates a path into regulated systems.
2. Escalation follows when excessive privilege or weak lifecycle governance allows the same identity to reach multiple systems, roles, or cloud boundaries.
3. Impact appears as delayed incident containment, incomplete audit evidence, and a resilience failure that cannot be explained cleanly to regulators.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 governance is now part of operational resilience, not a separate IAM workstream. DORA effectively collapses the distinction between access administration and resilience evidence because auditors will judge whether identity decisions can be traced, justified, and reviewed. The implication is that programmes built around siloed IAM tickets, periodic reviews, and informal vendor access will not produce the control narrative DORA expects.

Third-party access is the hardest trust test in regulated environments. Vendor identities are often the least visible and the least consistently offboarded, yet they can retain material reach into financial systems long after the original business need changes. That is not just a control gap, it is a trust model failure that DORA makes explicit. Financial entities should expect third-party identity governance to become a board-level assurance topic.

Machine identities are the hidden superusers of DORA scope. They are often created for speed, inherited across environments, and left outside ordinary lifecycle discipline. Under a resilience lens, that means the most operationally critical credentials may have the weakest ownership and the least evidence. Practitioners need to treat machine identity governance as a core part of regulated resilience, not an adjacent technical task.

Identity evidence is becoming as important as identity control. DORA rewards organisations that can show why access existed, when it changed, and who approved it. That changes the governance conversation from access enforcement alone to provable control lineage. The practical conclusion is that any identity programme without durable evidence paths will struggle to satisfy both operational and regulatory scrutiny.

Unified identity posture management is the right label for this problem space. The article points to a combined ISPM and ITDR model because visibility, policy, lifecycle, and detection are now interdependent. The implication is simple: a financial entity cannot govern resilience if identity posture, identity behaviour, and audit evidence live in separate tools and separate teams.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation windows are still too slow for real-world exposure.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs gives practitioners the lifecycle lens needed to close rotation, revocation, and ownership gaps.

What this signals

Lifecycle latency is the hidden DORA problem. When credentials outlive the events that created them, financial entities end up with a resilience model that looks compliant on paper but remains exposed in practice. That is why the control question is no longer whether access exists, but whether its creation, review, and removal can keep pace with business change and incident response.

The strongest programmes will converge identity posture, detection, and evidence into a single operating model. For teams already building DORA readiness, that means using internal resources such as Ultimate Guide to NHIs , Key Challenges and Risks alongside the NIST Cybersecurity Framework 2.0 to anchor governance, detection, and recovery in one control narrative.

For practitioners

• Map identity controls to DORA evidence requirements Build a control matrix that links joiner-mover-leaver workflows, privileged access, vendor identities, and machine credentials to auditable artefacts. Use it to test whether each control can be proven during an incident or supervisory review, not just whether it exists on paper.
• Inventory third-party identities as regulated assets Create a complete inventory of federated vendor accounts, service accounts, and externally managed credentials. Assign ownership, review cadence, and revocation triggers so that contract changes or access anomalies can be acted on before risk becomes embedded.
• Rationalise standing privilege across cloud and SaaS estates Review legacy entitlements, emergency access, and role drift across AWS IAM, Entra, GCP, and key SaaS systems. Remove permissions that no longer map to an approved business purpose and require documented justification for any privilege that persists.
• Extend lifecycle governance to machine identities Apply ownership, rotation, and offboarding discipline to API keys, service accounts, and workload credentials. Make sure every non-human identity has a named control owner, an expiry or review trigger, and a revocation path that works in practice.
• Consolidate identity telemetry for faster incident proofing Unify access logs, role changes, vendor activity, and anomalous identity behaviour into one investigative view. The goal is not only faster containment but also durable evidence that explains what happened without reconstructing the timeline from fragmented systems.

Key takeaways

• DORA turns identity from an IT hygiene issue into a resilience control that must be provable under audit.
• Third-party access, machine identities, and overprivilege create the largest evidence and governance gaps in financial environments.
• Financial entities need lifecycle governance, telemetry, and traceable control ownership if they want identity to support operational resilience.

Key terms

• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Control-by-control mapping of identity issues to DORA expectations across human, machine, and third-party access
• Practical examples of ISPM and ITDR workflows for regulated identity environments
• Vendor-specific evidence paths and automation examples for lifecycle governance and access review
• How Unosecur describes continuous privilege rationalisation and cross-cloud identity monitoring

👉 Unosecur's full blog details the nine identity risks, evidence paths, and governance workflows behind its DORA analysis.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.