DORA exposes the identity visibility gap in financial resilience

At a glance

What this is: This is a DORA-focused brief arguing that financial resilience depends on granular identity authorization visibility across human, third-party, NHI, and AI agent access.

Why it matters: It matters because financial institutions cannot evidence operational resilience, third-party risk control, or recovery readiness if they cannot see what each identity can actually do.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.

👉 Read Veza's brief on aligning identity visibility with DORA

Context

DORA makes operational resilience a regulated requirement for financial institutions, and that shifts identity from an administrative function to a resilience control. If an organisation cannot see which users, vendors, service accounts, and AI agents can perform which actions, it cannot confidently demonstrate control over ICT risk, incident response, or recovery.

The core gap is not identity volume alone. It is authorization opacity, the point where traditional IAM, IGA, and PAM reporting stops at entitlements and does not fully reveal effective access across third parties, non-human identities, and delegated execution paths. For DORA-aligned programmes, that gap becomes a compliance and resilience problem at the same time.

Key questions

Q: How should financial institutions govern privileged access for DORA compliance?

A: They should treat privileged access as part of resilience design, not a separate admin function. That means inventorying elevated accounts, enforcing session controls, preserving audit trails, and proving that access can be revoked and reissued during recovery exercises. The goal is evidence of control effectiveness under stress, not just policy alignment.

Q: Why do non-human identities make DORA harder to meet?

A: Because service accounts, API keys, certificates, and delegated automation often sit outside the visibility of traditional IAM and PAM reporting. If those identities are over-privileged, dormant, or unmanaged, financial institutions lose control over the access paths that DORA expects them to evidence.

Q: How should security teams govern third-party access under DORA?

A: They should treat third-party access as a regulated identity path, not an exception. That means explicit entitlement scope, named internal ownership, session logging, rapid revocation, and evidence that access remains justified throughout the vendor relationship. If an external user can reach systems without a clear owner and revocation trail, the control is not DORA-ready.

Q: Who is accountable when identity visibility is too weak to support resilience testing?

A: Accountability sits with the institution that must demonstrate operational resilience, even if access is granted through vendors or automation. Under DORA, teams need evidence that critical identities, permissions, and recovery paths are governed well enough to withstand disruption and audit scrutiny.

Technical breakdown

Why authorization visibility matters more than inventory for DORA

DORA asks financial entities to prove they can manage ICT risk, respond to incidents, test resilience, and govern third-party dependencies. A simple inventory of users, roles, and groups is not enough because effective risk sits in what identities can actually execute across systems. Authorization visibility connects identity to action, revealing toxic permissions, dormant access, over-privileged vendors, and machine identities that traditional reports may flatten or miss.

Practical implication: build access evidence around effective permissions and action paths, not just account counts.

Third-party and NHI access create hidden resilience dependencies

Third-party credentials and NHI credentials often persist longer than the business relationship or operational need that justified them. That is a DORA issue because external access can become an untracked operational dependency, especially when service accounts, API keys, and certificates are reused across environments. Without lifecycle control, the institution inherits access it cannot easily validate during incident recovery or vendor oversight.

Practical implication: map external and machine access to business dependencies and offboarding triggers.

AI agent identities widen the gap between policy and execution

AI agent identities change the governance problem because access may be invoked dynamically at runtime, through tools and delegated actions, rather than through static human workflows. That makes authorization evidence more fragile if the identity layer only records who logged in rather than what the agent could do during execution. In a DORA context, the control challenge becomes proving that autonomous or semi-autonomous actions remain bounded under stress, failure, or compromise.

Practical implication: review whether your identity controls can evidence runtime authorization for agent-driven actions.

NHI Mgmt Group analysis

Authorization visibility is now a resilience control, not an IAM reporting feature. DORA requires institutions to show control over ICT risk, incident handling, testing, and third-party exposure. If the identity plane cannot reveal effective access, financial organisations are left with incomplete evidence for resilience decisions. Practitioners should treat authorization visibility as part of the control environment, not as a dashboard metric.

Third-party NHI sprawl creates a regulated dependency that most programmes still under-model. Vendor access often enters through service accounts, API keys, certificates, and shared automation paths that outlive the original use case. That matters because DORA does not only care whether access exists, but whether it can be governed across the full lifecycle. The practical conclusion is that external identity governance belongs in resilience planning, not after an audit finding.

AI agent identities widen the DORA problem because execution can be dynamic even when policy looks stable. Traditional IAM assumes access can be described cleanly at provisioning time, but agentic execution can change which tools are used and when. That creates a gap between policy intent and runtime behaviour that financial institutions must now account for. The implication is that identity governance must evolve from static entitlement control to runtime authorization assurance.

Granular permission mapping is the missing bridge between resilience testing and operational recovery. DORA testing is only credible when institutions know which identities can perform which actions under pressure. If dormant accounts, toxic roles, and delegated machine access are not visible, recovery exercises can produce false confidence. Financial teams should treat action-level entitlement visibility as the evidence layer that links governance, incident response, and recovery readiness.

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 , Lifecycle Processes for Managing NHIs.
• Another finding from the Ultimate Guide to NHIs shows that 92% of organisations expose NHIs to third parties, which turns external access into a governance and resilience dependency.
• For a broader view of lifecycle, visibility, and zero trust controls, NHI Lifecycle Management Guide is the next resource to anchor remediation planning.

What this signals

DORA will keep pushing financial institutions toward evidence-based identity governance. The practical shift is away from static entitlement reporting and toward proof that access can be explained, bounded, and revoked across users, vendors, service accounts, and emerging agent identities. That is why authorization visibility now belongs in resilience planning, not only in IAM operations.

Authorization blast radius: the useful measure is no longer how many identities exist, but how far any one identity can move if it is abused. When service accounts, third-party accounts, and automation are over-privileged, recovery exercises become optimistic exercises rather than defensible controls. The next maturity step is to make access graphs and lifecycle evidence part of incident and resilience governance.

Financial teams should expect auditors and regulators to ask harder questions about delegated access paths and the evidence behind them. Programmes that already use the NIST Cybersecurity Framework 2.0 can map these concerns into access control, detection, and recovery outcomes, but only if identity telemetry is complete enough to support those functions.

For practitioners

• Map effective access, not just entitlements Trace what each identity can actually do across critical systems, including third-party accounts, service identities, and delegated automation paths. Use action-level evidence to identify toxic permission combinations that traditional role reports miss.
• Extend lifecycle controls to external and machine identities Require joiner-mover-leaver and offboarding workflows for vendors, service accounts, tokens, and certificates. Tie revocation to contract changes, system decommissioning, and role changes so access does not outlive the business need.
• Test resilience using identity failure scenarios Include dormant accounts, over-privileged vendor access, and broken secrets in incident and recovery exercises. Verify whether incident teams can still answer who has access to what when the environment is partially degraded.
• Review agent access as a separate governance class If AI agents can select tools or execute actions at runtime, assess their access separately from human user access. Record the actions they can initiate, the systems they can reach, and the approval assumptions that no longer hold.

Key takeaways

• DORA turns identity visibility into a resilience obligation because financial institutions must prove who can do what across critical systems.
• The largest governance gap is not account sprawl alone but hidden effective access across third parties, NHIs, and emerging AI agent identities.
• Teams that tie lifecycle control, authorization evidence, and recovery testing together will be better positioned to satisfy DORA scrutiny.

Key terms

• Access Visibility: Access visibility is the ability to see, in one place, which identities can reach which data, applications, and services. For IAM and data security teams, it is the difference between reviewing isolated permissions and understanding real blast radius across environments.
• Security Technical Debt: Security technical debt is the accumulation of unresolved security issues created by fast delivery, weak controls or repeated exceptions. In IaC environments, one bad template or policy gap can be multiplied across many deployments, making the debt both visible and systemic.
• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• 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.

What's in the full article

Veza's full brief covers the operational detail this post intentionally leaves for the source:

• How ServiceNow Veza aligns specific identity visibility capabilities to DORA's core pillars.
• The operational framing for ICT risk management, incident management and reporting, operational resilience testing, and third-party risk management.
• The brief's positioning on how granular authorization visibility is used to support financial resilience discussions.
• The source article's summary of the identity security technical debt that sits beneath traditional IAM, IGA, and PAM reporting.

👉 Veza's full brief covers the DORA mapping, identity technical debt, and the four resilience pillars in more detail.

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 a resilient identity programme across IAM, PAM, and NHI scope, it is worth exploring.