DORA exposes identity governance gaps in financial resilience controls

At a glance

What this is: This analysis links DORA compliance to identity governance, showing that financial resilience depends on continuous visibility, monitoring, and third-party access control.

Why it matters: It matters because IAM and PAM teams in financial services now have to treat access governance as part of operational resilience, incident readiness, and supplier oversight, not just internal policy enforcement.

Context

DORA makes operational resilience a governance problem as much as a technology problem. In financial environments, the question is no longer whether access exists, but whether firms can continuously explain who has it, why it exists, and whether it still matches the risk posture of the service, data, or supplier involved.

The identity angle is real because DORA’s requirements on ICT risk management, incident reporting, resilience testing, and third-party oversight all depend on access control evidence. For IAM, IGA, PAM, and NHI programmes, the challenge is shifting from periodic certification to continuous governance across internal users, external parties, service accounts, and other non-human access paths.

Key questions

Q: What breaks when access governance is still based on periodic reviews under DORA?

A: Periodic reviews miss access that changes between certification cycles, especially in organisations with suppliers, delegated administration, and machine identities. That creates blind spots in audit evidence and incident response because the current control state is unknown when an issue appears. Under DORA, that is a resilience failure, not just an IAM weakness.

Q: Why does third-party access raise operational resilience risk in financial services?

A: Third-party access raises resilience risk because external identities often sit outside the organisation’s direct day-to-day control, yet they can still reach critical data and services. If those paths are not tightly scoped and continuously monitored, a supplier issue becomes an operational incident. DORA makes that governance gap visible and consequential.

Q: What signs show that identity governance is too weak for DORA compliance?

A: Common signs include stale vendor entitlements, unclear ownership of integration accounts, inconsistent review evidence, and no live view of who can reach critical systems. If access changes cannot be traced quickly, the organisation will struggle to support incident reporting and resilience testing. Those are control failures, not documentation issues.

Q: Which controls matter most when DORA testing includes third parties and identities?

A: Access controls, privileged account governance, and recovery validation matter most because they determine whether compromise stays contained or propagates across internal and external dependencies. Identity paths are often the weakest link in resilience testing, especially where service accounts or delegated access are not explicitly scoped and verified.

Technical breakdown

Why periodic access reviews fall short under DORA

Periodic access reviews assume the control state is stable long enough for a scheduled attestation to be meaningful. In modern financial environments, access changes through role churn, delegated third-party relationships, inherited permissions, and machine or service identities that are easy to overlook. DORA raises the bar because resilience depends on knowing the current access picture, not just the last certified one. Identity governance therefore has to operate as a live control plane for access evidence, not a quarterly paperwork exercise.

Practical implication: replace review-only governance with continuous access discovery and exception detection across human and non-human identities.

How third-party access becomes a resilience issue

Third-party access is not only a supplier-management concern under DORA. It becomes a resilience issue when vendors, contractors, and integration partners retain access that is broader, longer-lived, or less visible than internal access. That creates blind spots in incident response, audit evidence, and operational recovery because the organisation cannot quickly isolate or explain external privilege paths. The governing problem is lifecycle control, including provisioning, review, and offboarding for every external identity path.

Practical implication: map every external access path to an owner, a purpose, and a termination condition before relying on it in critical services.

Access intelligence as the control layer for audit evidence

Access intelligence is the capability to reconstruct who can reach what across systems, applications, and data in near real time. For DORA, that matters because evidence has to support governance, incident reporting, and resilience testing, not just annual audit requests. In NHI terms, the same logic applies to service accounts, tokens, API keys, and other machine identities that may sit inside supplier integrations or critical workflows. Without that visibility, organisations cannot prove control effectiveness when it matters most.

Practical implication: build a continuously updated permissions map that supports both audit evidence and operational containment.

Threat narrative

Attacker objective: The objective is to exploit unmanaged or overextended access paths to reach sensitive financial data or critical ICT services without immediate containment.

1. Entry occurs through broad or poorly governed third-party access into financial systems, often via integration accounts, delegated permissions, or inherited entitlements.
2. Privilege is then abused through access paths that remain active longer than necessary, allowing an external party or compromised identity to reach sensitive systems or data.
3. Impact follows when the organisation cannot rapidly explain, constrain, or revoke those access paths during an incident, increasing resilience and reporting risk.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.

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

NHI Mgmt Group analysis

DORA turns access governance into a resilience control, not an audit afterthought. Financial firms cannot rely on periodic certification when access is dynamic, federated, and often inherited through suppliers or integrations. The control question is whether the organisation can show current access state fast enough to support incident response and continuity decisions. Practitioners should treat access governance as part of operational resilience architecture, not a separate IAM project.

Third-party access is the weakest resilience link when termination and oversight are not lifecycle managed. DORA’s emphasis on supplier oversight exposes a common governance gap: external access often outlives the business need that justified it. That leaves financial firms dependent on trust that is not continuously verified. The practical conclusion is that vendor access must be owned, scoped, and retired with the same discipline as any critical service dependency.

Access intelligence is becoming the named concept for resilience-grade identity governance. The article’s core message is that organisations need a real-time map of permissions, not a static inventory of users. That concept matters because resilience testing and incident classification both depend on knowing where privilege actually sits. Practitioners should align identity evidence with DORA reporting, continuity planning, and supplier controls.

Machine identities must be governed alongside human and third-party users if DORA controls are to hold. Service accounts, tokens, and API keys often carry the access that keeps financial workflows running, yet they are rarely governed with the same scrutiny as employee accounts. When those credentials sit inside vendor-managed integrations, the operational risk compounds. The practical conclusion is that NHI governance belongs inside resilience programmes, not beside them as a separate initiative.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

Access governance is now a resilience metric. Financial institutions should expect regulators, auditors, and internal risk teams to ask whether access can be explained continuously, not just certified periodically. That shifts the programme from entitlement recertification toward live control of critical access paths, including supplier-managed and machine-mediated ones.

Third-party access will be the hardest control to evidence under DORA. External identities create a governance boundary that is harder to monitor, revoke, and prove than internal access. Financial teams should prepare for tighter scrutiny of supplier onboarding, offboarding, and access ownership, especially where integrations depend on service accounts or tokens.

Access intelligence becomes the operational bridge between identity and resilience. Continuous visibility into permissions gives incident teams a faster containment path and gives GRC teams better evidence for DORA-aligned reporting. Practitioners who cannot show that bridge should expect more manual work, slower response, and weaker assurance.

For practitioners

• Implement continuous access discovery Maintain a live inventory of who and what can reach critical financial systems, including delegated and inherited permissions. Reconcile the inventory against business ownership and system criticality on an ongoing basis, not just during scheduled reviews.
• Map and govern third-party access lifecycles Assign an owner, purpose, review cadence, and offboarding trigger to every external access path. Require the same controls for contractor, supplier, and integration identities that you expect for internal accounts.
• Extend governance to machine identities Include service accounts, tokens, and API keys in identity governance workflows so supplier integrations and automated jobs are visible, reviewable, and revocable when risk changes.
• Use resilience evidence in incident reporting Pre-stage access evidence that can support DORA incident classification, audit trails, and containment decisions. If the organisation cannot explain current privilege quickly, it cannot demonstrate control effectiveness under stress.

Key takeaways

• DORA pushes identity governance into the resilience stack, where access visibility and revocation speed affect continuity and reporting.
• Third-party and machine identities are part of the same control problem because both can extend privilege outside normal review cycles.
• Financial teams need live access evidence, not just periodic certification, if they want governance that stands up under operational stress.

Key terms

• Access intelligence: Access intelligence is a runtime authorization approach that combines identity, context, and policy before granting or continuing access. It reduces the value of stolen credentials by requiring the request to still look legitimate at the moment of use, not just at the moment of approval.
• Third-Party Access Lifecycle: Third-party access lifecycle is the full sequence of granting, using, reviewing, and removing external access to internal systems. It matters because supplier credentials and remote sessions often outlive the business need, creating governance gaps that are difficult to detect without explicit offboarding and review.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

Build practical skills in NHI governance, IAM, and secrets management with the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and identity teams translate governance requirements into controls they can operate day to day.