Who should be accountable for third-party NHI access?

Why This Matters for Security Teams

Third-party NHI access is easy to approve and hard to unwind, which makes accountability the real control point. The risk is not only over-privileged service accounts, but also unclear ownership when vendors, integrators, and internal platform teams all touch the same identity. NHI management research consistently shows that lifecycle failures and exposed secrets are common, and the 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding.

Security teams often focus on whether the token works, but accountability requires answering who requested it, who approved it, who monitors it, and who removes it when the relationship changes. That is especially important for vendor-run automations, support integrations, and data exchange pipelines where the external party may not see the downstream exposure they create. Current guidance from the OWASP Non-Human Identity Top 10 treats ownership and lifecycle control as core NHI hygiene, not optional process overhead. In practice, many security teams encounter broken vendor access only after a contract has ended or an incident has already exposed the missing offboarding step.

How It Works in Practice

Accountability should be assigned to the business owner who can justify the relationship, plus the technical owner who can enforce the control. For third-party NHI access, that means every identity needs a named owner, a defined purpose, a review date, a revocation path, and a documented dependency on the external party that receives the access. The business owner explains why the access exists. The technical owner ensures the identity is created, scoped, monitored, and removed according to policy.

In mature programs, third-party access is treated as a time-bound entitlement rather than a permanent integration. A practical control pattern is:

• issue the NHI only for a specific service, tenant, or workflow
• scope access to the minimum system, API, or dataset required
• attach a renewal date and an explicit offboarding trigger
• rotate or revoke secrets when the contract, application, or vendor relationship changes
• log the approver, owner, and last review outcome in the inventory

This is where standards help. The OWASP NHI Top 10 and NIST AI Risk Management Framework both reinforce that accountability must be traceable, especially when automation and delegated access blur who is actually operating the identity. NHIMG’s 52 NHI Breaches Analysis shows the same pattern repeatedly: identities are created for a valid business need, then left behind after the need disappears. These controls tend to break down when vendor access is embedded in application code or shared across multiple internal teams because no single owner can prove when removal is safe.

Common Variations and Edge Cases

Tighter ownership usually improves security, but it also increases coordination overhead, so organisations have to balance control with operational speed. There is no universal standard for third-party NHI governance yet, which means some environments will need stricter approval gates than others.

One common edge case is managed services, where the vendor runs the workflow but the enterprise still owns the data and the risk. In that model, accountability should not shift to the vendor by default. Another case is embedded SaaS integrations, where the external identity is created by a platform team but used by multiple business units. In those situations, best practice is to assign a primary business owner and a secondary technical custodian, then require periodic recertification.

For high-risk access, use the same thinking recommended in the CISA Zero Trust Maturity Model: assume the access will outlive its original need unless a named owner actively proves otherwise. Where vendor access touches production systems, there should also be a clear exception process for emergency access and a documented sunset date. NHIMG’s Top 10 NHI Issues is a useful reminder that lifecycle drift is usually a process failure first and a technical failure second.

Related resources from NHI Mgmt Group

• Who should be accountable for third-party access removal?
• Who is accountable when third-party or guest device access is over-extended?
• Who should own third-party access removal in compliance programmes?
• Who is accountable for SaaS security when third-party apps are involved?