Subscribe to the Non-Human & AI Identity Journal
Home FAQ Cyber Security What fails when third-party access is not tied…
Cyber Security

What fails when third-party access is not tied to identity governance under DORA?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 11, 2026 Domain: Cyber Security

The control gap is usually not the supplier contract, but the unmanaged credentials and privileges that remain after the business relationship changes. If third-party accounts, service keys, and delegated access are not lifecycle-managed, the organisation can no longer prove who had access, when it changed, or whether revocation actually happened.

Why This Matters for Security Teams

Under DORA, third-party access is not just a supplier management issue. It becomes an identity governance problem as soon as external users, service accounts, API keys, or delegated workflows can reach systems that support critical or important functions. If those identities are not tied to ownership, approval, expiry, and review, the organisation loses the ability to demonstrate control over access, which is central to auditability and operational resilience.

The practical failure is that teams often focus on the contract, the onboarding questionnaire, or the security clause, while the actual access path remains live in IAM, PAM, SaaS consoles, or a cloud control plane. That gap creates risk during supplier changes, incident response, and offboarding. DORA expects more than policy language; it expects evidence that access is knowable, reviewable, and revocable. The broader control logic aligns with the NIST Cybersecurity Framework 2.0, which emphasises governance, identity, and access control as part of resilience.

In practice, many security teams encounter the access problem only after a supplier relationship has already changed, rather than through intentional lifecycle control.

How It Works in Practice

Effective third-party access governance starts with identity inventory, not vendor inventory. Every external human user, service account, machine credential, and integration token should be attributable to a named supplier, a business owner, a purpose, and a defined expiry or review period. That is where identity governance, PAM, and NHI controls converge. The question is not merely whether access was approved, but whether the organisation can continuously prove that the approval is still valid and that revocation will actually remove access.

In practice, this means linking third-party identities to lifecycle workflows that cover onboarding, periodic recertification, privilege elevation, and offboarding. It also means distinguishing between interactive access and non-human access. Supplier automation often uses secrets that outlive staff changes, making them harder to govern unless they are treated as first-class identities. Guidance from the OWASP Non-Human Identity Top 10 is especially relevant here because unmanaged service credentials are a common blind spot.

A practical control stack usually includes:

  • Central ownership for every third-party identity and secret.
  • Time-bound access with explicit renewal, not indefinite entitlements.
  • Segregation between human supplier users and non-human service access.
  • Automated deprovisioning on contract end, termination, or scope change.
  • Evidence capture for approvals, reviews, and revocation events.

Where higher-risk access is involved, organisations often map these controls to NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement and accountability. These controls tend to break down when supplier access is scattered across shadow SaaS, unmanaged API keys, and locally administered accounts because no single system owns the full lifecycle.

Common Variations and Edge Cases

Tighter third-party access governance often increases operational overhead, requiring organisations to balance resilience against onboarding speed and supplier flexibility. That tradeoff becomes more visible in fast-moving environments where engineering teams provision access directly to cloud services, CI/CD pipelines, or data platforms.

There is no universal standard for this yet, but current guidance suggests treating some supplier access as NHI governance rather than traditional user access review. That matters when a vendor runs scheduled jobs, maintains integrations, or uses shared automation accounts. In those cases, the access owner may be a business function, while the actual credential sits in a secrets manager, a cloud role, or a SaaS token store. If the organisation cannot map those credentials back to a person, contract, and purpose, recertification becomes performative.

Edge cases also appear during subcontracting and emergency support. A primary supplier may claim access is limited, while a subcontractor actually holds the privileged credentials. Under EU Digital Operational Resilience Act (DORA), that still needs governance evidence, because accountability does not disappear when access is delegated. The same is true for break-glass accounts, where speed is useful but standing privilege must still be tightly controlled. In regulated environments, the failure usually appears when audit teams ask for a complete access trail and the organisation can only produce a procurement record, not an identity record.

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 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and DORA define the regulatory obligations.

FrameworkControl / ReferenceRelevance
DORADORA requires controlled ICT third-party access and evidence of oversight.
NIST CSF 2.0PR.ACAccess control and identity governance underpin resilient third-party access.
NIST SP 800-53 Rev 5AC-2Account management is the core control for provisioning and deprovisioning.
OWASP Non-Human Identity Top 10Non-human identities are often the hidden persistence layer for vendor access.
NIST AI RMFIf suppliers operate AI systems, governance must cover their access and outputs.

Use account lifecycle controls to ensure supplier access is approved and removed.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org