Accountability sits with the organisation that grants and oversees access, even when contractors, partners, or service providers are involved. DORA expects firms to control third party risk, log privileged activity, and maintain evidence for reporting and review. Delegating access does not delegate responsibility for governance, monitoring, or regulatory outcome.
Why This Matters for Security Teams
Under DORA, third party privileged access is not a vendor-only problem. The organisation that grants the access remains accountable for oversight, evidence, and outcomes, even when the work is performed by contractors or service providers. That means privileged sessions, approval chains, logging, and review evidence must be governed with the same discipline as internal access. Current guidance from EU Digital Operational Resilience Act (DORA) and the NIST Cybersecurity Framework 2.0 points toward continuous control, not periodic trust.
The practical failure is usually not that a third party has access, but that no one can prove who approved it, what they did, whether it was constrained, or how quickly it was revoked. In NHI environments, that becomes harder because privileged access is often mediated by API keys, OAuth grants, service accounts, and shared operational tooling. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as an auditability problem as much as an identity problem, and the issue is magnified when third parties connect through machine credentials that outlive the business need. In practice, many security teams encounter accountability gaps only after a control failure, not through intentional access review.
How It Works in Practice
DORA does not require firms to ban third-party privileged access. It requires them to govern it. The accountable organisation should define the access purpose, approve the scope, enforce least privilege, monitor use, retain logs, and be able to evidence those controls during challenge or incident review. That operational model aligns with the control themes in OWASP Non-Human Identity Top 10, especially where credentials, tokens, and service accounts are used to extend privileged reach beyond human operators.
- Require named business ownership for every third party privileged pathway.
- Use time-bounded approvals and remove standing access where possible.
- Log both the grant decision and the privileged activity itself.
- Review OAuth apps, service accounts, and API tokens as part of third party oversight.
- Keep revocation and evidence retention under the firm’s control, not the supplier’s convenience.
For NHI-heavy environments, the control question is not only “who is the vendor?” but “what identity was used, what was it allowed to do, and how quickly can it be shut off?” NHIMG’s 52 NHI Breaches Analysis repeatedly shows that credential exposure and weak lifecycle governance create outsized blast radius when access is shared, overused, or insufficiently monitored. If organisations cannot tie privileged activity back to a specific accountable owner and a specific approved purpose, then the DORA control fails even if the supplier operated the session. These controls tend to break down in federated environments where multiple business units and outsourcers reuse the same privileged NHI, because ownership and logging get fragmented across systems.
Common Variations and Edge Cases
Tighter third-party control often increases operational overhead, requiring organisations to balance faster delivery against stronger evidence and revocation discipline. That tradeoff is real, especially for managed service providers, emergency break-glass access, and cross-border support models. Best practice is evolving, but there is no universal standard for this yet on whether a supplier may retain any standing privileged capability, or whether all such access should be customer-issued and customer-revocable.
Edge cases usually involve shared admin platforms, outsourced SOC functions, and integrations where a third party operates through an NHI rather than a human login. In those situations, accountability still sits with the regulated firm, but the control design may need to extend to token rotation, delegated admin scoping, session recording, and attestation of every privileged workflow. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs are useful references when mapping these exceptions to audit evidence. Where vendors insist on opaque access models, the risk is not just weaker security, but an inability to demonstrate DORA-aligned governance after an incident or supervisory request.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Clarifies who owns and governs third party privileged access. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Privileged NHI lifecycle control is central to third party access governance. |
| CSA MAESTRO | IAC-02 | Third party agent and workload access needs strong identity and approval controls. |
| NIST AI RMF | Accountability and oversight are core AI governance concerns for autonomous access paths. | |
| NIST Zero Trust (SP 800-207) | SC.AU-3 | Zero trust requires continuous verification and logging for third party privileged activity. |
Assign explicit owners for third party privileged pathways and document governance responsibilities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
