The organisation that granted the access remains accountable, even when the relationship was initiated through a vendor, app, or integration. If third-party access is not tied to ownership, offboarding, and periodic review, it becomes an unmanaged extension of the identity perimeter rather than a bounded exception.
Why This Matters for Security Teams
Third-party access that outlives its intended use is not just a vendor-management problem. It is an identity lifecycle failure that leaves the granting organisation responsible for privileges that were never truly retired. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, while 92% expose NHIs to third parties, creating a broad supply chain exposure surface. That combination is exactly how temporary integrations become standing access.
Security teams often assume the relationship owner, procurement, or the external provider will clean up access when a project ends. That assumption fails because the access is usually embedded in scripts, service accounts, API tokens, and app-to-app connections that do not expire on their own. Current guidance from the OWASP Non-Human Identity Top 10 treats this as a lifecycle and governance issue, not a one-time onboarding task.
In practice, many security teams discover the stale access only after a contract ends, an integration breaks, or a breach review reveals that the trusted third party never lost its keys.
How It Works in Practice
Accountability stays with the organisation that granted the access because that organisation controls the identity, the entitlements, and the revocation path. The practical question is not who requested the access, but who owns its lifecycle. That means every third-party connection needs an internal owner, a purpose statement, an expiration trigger, and a verified offboarding step. NHI Mgmt Group’s Ultimate Guide to NHIs highlights why this matters: 71% of NHIs are not rotated within recommended time frames, which shows how easily temporary access becomes permanent when no one is accountable for renewal or retirement.
In operational terms, strong programs tie access to a business service or ticket, not to a person’s memory or a vendor promise. Common controls include:
- Assigning a named internal owner for each vendor token, API key, or service account.
- Using time-bound approvals with renewal required before access continues.
- Separating onboarding approval from offboarding verification so the same team can validate removal.
- Logging every revocation event and checking for orphaned credentials in code, vaults, and CI/CD systems.
- Reviewing high-risk integrations on a fixed cadence, especially where secrets can be copied or reused.
Where possible, teams should prefer short-lived credentials and workload identity over static secrets, because revocation is only reliable when there is a clean technical control to revoke. Standards such as OWASP Non-Human Identity Top 10 and identity guidance in the broader NIST identity management body both point toward traceable ownership, least privilege, and periodic review as the minimum baseline. These controls tend to break down when third-party access is embedded in long-lived automation that nobody inventories, because revocation then depends on finding every copy of the credential first.
Common Variations and Edge Cases
Tighter access governance often increases operational overhead, requiring organisations to balance vendor convenience against the cost of continuous review. That tradeoff is real, especially where many integrations support production systems or cross-company workflows.
There is no universal standard for every third-party scenario yet, but current guidance suggests treating high-impact access differently from low-risk access. A customer-support app with read-only data access is not the same as a payment processor key, a CI/CD deployment token, or a partner-managed service account. The higher the privilege and blast radius, the stronger the case for named ownership, shorter TTLs, and mandatory offboarding checks.
Edge cases often appear when the third party never had direct administrative control, but the access still persists through delegated trust, OAuth grants, shared secrets, or embedded automation. In those cases, accountability still sits with the organisation that allowed the grant to exist. The 52 NHI Breaches Analysis shows how compromised or overlooked non-human access repeatedly becomes a post-incident discovery rather than a managed lifecycle event. For teams building governance around this problem, the right question is not whether the vendor behaved responsibly, but whether the internal control owner had a reliable way to prove access was removed.
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 and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers lifecycle and revocation failures in third-party non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management applies to stale third-party permissions. |
| NIST AI RMF | GOV-1 | Governance requires accountable ownership for automated and delegated access. |
Define an accountable owner for each external access path and track it through lifecycle controls.
