Accountability should sit with the business owner, the identity governance function, and the third-party risk owner together, because the failure is lifecycle control, not just technical access. If a vendor identity remains active after the relationship or scope changes, the organisation has allowed a known blast radius to persist. Ownership must force revocation.
Why This Matters for Security Teams
When third-party access stays active too long, the issue is usually not a missing ticket. It is a control failure across ownership, review, and revocation. NHI Management Group’s Ultimate Guide to NHIs shows that only 20% of organisations have formal offboarding and revocation processes for API keys, which helps explain why expired vendor access often survives relationship changes. The risk is amplified because third parties frequently hold broad, persistent access into production paths.
This is also why the answer cannot sit with IT alone. The business owner defines whether the access is still needed, the identity governance function enforces lifecycle control, and the third-party risk owner validates whether the vendor relationship still justifies exposure. Security teams should treat lingering access as a standing blast-radius problem, not a housekeeping issue. The patterns documented in 52 NHI Breaches Analysis show how stale non-human access often becomes the easiest path to wider compromise. In practice, many security teams encounter this only after a vendor contract has changed or an incident has already exposed the gap.
How It Works in Practice
Accountability works best when it is assigned to the party that can actually force change. The business owner confirms the operational need, identity governance executes the access review and revocation workflow, and third-party risk management ensures the vendor’s role, scope, and contractual terms still justify access. That division matters because access rarely expires on its own. It must be removed when a project ends, a supplier is replaced, a scope narrows, or a system is decommissioned.
Practically, this means tying vendor identities to a named internal sponsor, a renewal date, and a review cadence. The most effective programs combine access recertification with automated expiry, so the default state is temporary rather than permanent. Current guidance from the OWASP Non-Human Identity Top 10 aligns with this approach: non-human credentials should be treated as governed lifecycle objects, not static entitlements. That pairs naturally with NHIMG’s observation that 91.6% of secrets remain valid five days after notification, which shows how slow remediation can be once access is left to manual follow-up.
- Require an internal owner for every third-party identity.
- Set explicit expiry dates for all vendor accounts and tokens.
- Review access at contract renewal, scope change, and offboarding.
- Revoke by default when ownership is unclear or a review is overdue.
Where organisations have stronger maturity, they also link vendor access to privileged access management, secrets rotation, and CMDB or contract records so no one has to infer whether the account should still exist. These controls tend to break down when third-party relationships are managed in procurement systems that are disconnected from identity governance and actual runtime access.
Common Variations and Edge Cases
Tighter third-party controls often increase operational overhead, requiring organisations to balance faster delivery against stronger revocation discipline. That tradeoff becomes visible in environments with many short-term vendors, managed service providers, or integration partners that touch multiple systems.
There is no universal standard for this yet, but current guidance suggests the safest model is to assign dual accountability: the business owner owns the need, while identity governance owns the control. In highly regulated environments, third-party risk may also require evidence that access was removed as part of offboarding, not just marked inactive in a spreadsheet. For shared service accounts, the edge case is even harder: a single credential may support multiple suppliers, so revocation must be coordinated to avoid breaking legitimate operations.
Teams should also be careful not to confuse review with revocation. A periodic attestation that says access is still valid does not reduce risk if no one can trigger immediate removal. The most common failure is letting vendor access persist because no one owns the cleanup after a contract ends or a system migration closes the original use case. That gap is exactly where stale access becomes invisible until it is exploited.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses lifecycle control failures for non-human identities and stale third-party access. |
| NIST CSF 2.0 | PR.AC-4 | Supports controlled access management for third-party identities and least privilege enforcement. |
| NIST CSF 2.0 | ID.SC-2 | Covers supplier risk oversight, which is central when third-party access outlives its purpose. |
Assign owners, set expiry, and revoke vendor identities automatically when scope or relationship changes.
Related resources from NHI Mgmt Group
- Who is accountable when third-party remote access is overused in public safety environments?
- Who is accountable for third-party access after a campaign or project ends?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when a user grants a risky third-party app access?
