The business team that depends on the integration should own revocation, with security and IAM providing policy and oversight. Third-party non-human access should not be left to vendor assumptions alone, because active tokens and OAuth grants can outlive the business need that created them.
Why This Matters for Security Teams
Third-party non-human access is easy to approve and hard to unwind. The real risk is not just that a vendor has credentials, but that tokens, OAuth grants, service accounts, and API keys remain valid after the business relationship or integration need has changed. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes revocation ownership a governance issue, not a technical footnote. The operational lesson is simple: the team that depends on the integration is best positioned to judge when access is no longer required, while security and IAM provide the control plane.
This is especially important because third-party access often spans SaaS, CI/CD, and automation layers that are invisible to a single central team. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both frame lifecycle control as a core risk area, because revoked business need and revoked credentials are not the same event. In practice, many security teams discover stale vendor access only after an integration outage, a contract change, or a breach review has already exposed the gap.
How It Works in Practice
Ownership should be split, but not blurred. The business owner of the integration initiates revocation, confirms that the third party no longer needs access, and validates downstream dependencies. Security defines the policy for what must be revoked, how quickly, and under what approval thresholds. IAM or platform teams execute or automate the technical removal across identity providers, secret stores, SaaS apps, and API gateways.
A workable model usually includes:
- Named business ownership for every third-party NHI, including a service or product owner.
- Documented trigger events such as contract termination, vendor risk findings, project completion, or scope reduction.
- Revocation playbooks that cover OAuth grants, refresh tokens, API keys, service accounts, and certificates.
- Short validation windows so the owner can confirm no critical workflow breaks before final disablement.
- Logging and evidence capture so security can prove revocation was completed and not just requested.
Current guidance suggests that revocation should be tied to business workflow, not annual access review alone. For high-risk integrations, organisations should also prefer 52 NHI Breaches Analysis-style lessons learned: stale credentials tend to persist after human handoffs because no one owns the final shutdown step. Standards guidance from the OWASP Non-Human Identity Top 10 also aligns with runtime lifecycle control, not just initial issuance.
This approach works best when third-party identities are inventoried centrally and linked to a business service owner. These controls tend to break down when vendors self-manage their own credentials across multiple environments because the enterprise loses sight of what was issued, what was rotated, and what still has authority.
Common Variations and Edge Cases
Tighter revocation control often increases coordination overhead, requiring organisations to balance faster shutdown against the risk of breaking production workflows. That tradeoff becomes sharper when the third party supports customer-facing services, shared infrastructure, or emergency operations.
There is no universal standard for this yet, but current guidance suggests a few common variations. For low-risk, low-dependency integrations, security may authorise broad revocation rules and allow the platform team to automate disablement. For high-risk or regulated access, the business owner should be required to sign off before and after revocation, with IAM holding the technical kill switch. In mature environments, this is often paired with time-bound access and just-in-time issuance so revocation is the default end state rather than an exception.
Edge cases include shared vendor accounts, embedded credentials in CI/CD pipelines, and delegated access through OAuth consent that survives even after a service account password is changed. Those cases require explicit discovery because a contract termination does not automatically remove active grants. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how lifecycle gaps and poor visibility amplify third-party exposure. The practical rule is to assign revocation ownership to the team closest to business need, while keeping security accountable for policy and proof.
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-01 | Third-party access governance depends on clear ownership and lifecycle controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review applies directly to revoking stale vendor access. |
| NIST AI RMF | Governance and accountability are needed when automated systems use external access. |
Assign each vendor identity a business owner and require formal revoke triggers tied to service end.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern human and non-human access in the same programme?
- How should IAM teams respond when Office 365 identity sprawl spans human and non-human access?
