Who is accountable when third-party non-human identities cause a DORA incident?

Why This Matters for Security Teams

DORA changes the accountability model: the regulated financial institution remains responsible for ICT risk even when a third party provisions, runs, or monitors the non-human identities involved. That matters because external NHIs often sit inside shared automation, outsourced operations, and cloud service chains where ownership is easy to blur and privilege is easy to overextend. Guidance from the OWASP Non-Human Identity Top 10 and the EU Digital Operational Resilience Act (DORA) both point to the same operational truth: access, monitoring, and lifecycle control must be governed as if the institution itself will be judged on the outcome, because it will.

This is not just a contract issue. If a supplier’s service account is overprivileged, unmonitored, or left active after a change in service scope, the incident still lands in the institution’s resilience, reporting, and remediation workflow. NHIMG research shows the scale of the exposure: Ultimate Guide to NHIs — Why NHI Security Matters Now reports that 92% of organisations expose NHIs to third parties. In practice, many security teams discover the accountability gap only after a supplier identity has already been used to move laterally or trigger a reportable event, rather than through intentional third-party NHI governance.

How It Works in Practice

Operationally, accountability should be translated into control ownership, evidence, and escalation paths. The institution needs a clear register of third-party NHIs, the business service each identity supports, the data and systems it can touch, the approval basis for its privileges, and the conditions under which access must be revoked. That includes service accounts, API keys, certificates, federated tokens, and automation identities used by vendors, managed service providers, and SaaS platforms.

Security teams should require the supplier to provide evidence, but not outsource verification. Practical controls include least privilege, just-in-time access where possible, short token lifetimes, rotation, offboarding, and continuous monitoring for anomalous use. This aligns with standard control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, but for DORA the key point is evidentiary: the institution must be able to show who approved the access, what was monitored, and how quickly revocation occurred after a change or incident.

• Map each third-party NHI to a named internal owner and system owner.
• Enforce time-bound access with documented renewal and revocation triggers.
• Review vendor-generated secrets, tokens, and certificates on a scheduled basis.
• Log NHI activity centrally so incident triage is not dependent on the supplier’s timeline.

For incident response, the institution should define when the supplier must notify, who can disable access, and how evidence is preserved for regulatory reporting. These controls tend to break down in multi-tier outsourcing arrangements where the supplier is itself relying on sub-processors and identity propagation is opaque.

Common Variations and Edge Cases

Tighter third-party identity control often increases onboarding time and operational overhead, requiring organisations to balance resilience against supplier friction. The hardest cases are not the obvious admin accounts, but delegated automation, federated workloads, and embedded SaaS integrations where the supplier never exposes a traditional login. In those cases, current guidance suggests treating the identity as a governed workload entity rather than a human proxy, with the institution retaining approval authority for scope and duration.

There is no universal standard for this yet, but best practice is evolving toward evidence-based supplier oversight: identity inventory, privilege attestations, periodic access review, and rapid revocation testing. This is especially important when the supplier operates across regions or uses sub-contractors, because the regulated entity can still be accountable for the resilience impact even if the technical fault sits several layers down the chain. NHIMG’s 52 NHI Breaches Analysis and Reviewdog GitHub Action supply chain attack both illustrate how third-party identity misuse can cascade through trusted automation.

Where the supplier refuses transparency into token lifecycle, alerting, or revocation, the control model breaks down because the institution cannot evidence timely containment or demonstrate that access was constrained to the approved business purpose.

Related resources from NHI Mgmt Group

• Who is accountable for identity risk across employees, third parties, and non-human identities during a cyber incident?
• Who is accountable when stale non-human credentials are left exposed after a breach or third-party incident?
• Who is accountable when third party privileged access is not governed properly under DORA?
• Who is accountable when AI agents and other non-human identities make access decisions that create risk?