Ownership should sit with the business or system team that granted the access, with IAM or IGA providing the control framework and verification. Compliance teams can track whether the process happened, but they should not be the only line of defence for revocation. Clear ownership is what keeps offboarding from becoming a paper exercise.
Why This Matters for Security Teams
Third-party access removal is a governance problem until it becomes a breach problem. If the team that approved or consumed the access does not also own revocation, offboarding becomes fragmented across compliance, IAM, procurement, and operations. That fragmentation is especially risky for secrets, service accounts, API keys, and partner integrations that outlive the business need that created them.
This is why NHI Management Group treats removal ownership as a control design issue, not a reporting issue. The Ultimate Guide to NHIs shows how common it is for credentials to remain valid long after they should have been revoked, and why lifecycle controls must be tied to the team closest to the access request. External guidance also points in the same direction: the OWASP Non-Human Identity Top 10 frames unmanaged non-human access as a recurring exposure, not a one-time cleanup task.
In practice, many security teams encounter stale third-party access only after a vendor exit, contract dispute, or incident review has already exposed the gap.
How It Works in Practice
Best practice is to assign revocation ownership to the business owner, product owner, or system owner that approved the third-party access in the first place. IAM or IGA should provide the workflow, evidence trail, and policy checks, but they cannot reliably infer whether a token, API key, or integration is still needed. Compliance can monitor completion, but it should not be the last accountable party.
Operationally, that means every third-party entitlement needs a named owner, a purpose, an expiry or review date, and a documented offboarding trigger. For non-human identities, the control should also include secret rotation and credential invalidation, because removal is not just deleting a record in a ticketing system. NHI Management Group research highlights the lifecycle gap clearly: the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs emphasises that revocation must be part of the same lifecycle that granted the access.
- Business or system owner approves and later confirms removal.
- IAM or IGA enforces the workflow, evidence capture, and escalation path.
- Security validates that secrets, tokens, certificates, and service accounts were actually invalidated.
- Compliance verifies that the process happened on time and with retained evidence.
For control design, the NIST Cybersecurity Framework 2.0 supports the idea that governance, identity, and access responsibilities must be assigned, tracked, and measured across the organisation. These controls tend to break down when third-party access is embedded in shared platforms or automation pipelines, because no single team can see the full blast radius.
Common Variations and Edge Cases
Tighter removal ownership often increases coordination overhead, requiring organisations to balance accountability against speed during offboarding. That tradeoff becomes sharper when third parties operate through delegated admin roles, embedded integrations, or machine-to-machine workflows, where one vendor may control multiple technical identities across several systems.
There is no universal standard for this yet, but current guidance suggests the same principle: the party that created the risk should help retire it. In practice, that may mean the business owner owns the decision, the technical platform owner executes revocation, and security performs verification for high-risk access. For shared services, a central IAM team may coordinate the workflow, but it should not absorb business accountability.
Two common edge cases deserve special handling. First, emergency terminations may require immediate security-led revocation with retrospective business confirmation. Second, partner integrations that cannot be cut off cleanly may need staged removal, short-lived credentials, or compensating controls until replacement access is established. NHI programmes should also use breach lessons to reinforce ownership discipline, including the patterns described in 52 NHI Breaches Analysis and the broader lifecycle guidance in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.
The policy should be explicit: compliance can evidence removal, but only the access-owning team can attest that the third-party relationship is truly finished.
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 and CSA MAESTRO address the attack and risk surface, while 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-07 | Covers lifecycle and revocation gaps for third-party non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Supports managed access rights and timely removal of unnecessary access. |
| CSA MAESTRO | Agentic and third-party workflows need accountable ownership across lifecycle events. |
Map third-party offboarding to access review, approval, and revocation workflows with evidence.
