The accountable organisation is the one that allowed the external identity to retain access without an offboarding process. Third-party machine identities should have explicit owners, review dates, and revocation criteria so access does not outlive the relationship or the operational purpose.
Why This Matters for Security Teams
When a third-party integration keeps a non-human identity active after the business need ends, the issue is not just delayed cleanup. It is an ownership failure that turns a temporary trust decision into standing access. That breaks offboarding, weakens least privilege, and can keep secrets valid long after the relationship should have closed. NHIMG research shows 92% of organisations expose NHIs to third parties, which makes supplier lifecycle control a real supply chain issue, not a niche IAM problem. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the control expectations behind that risk.
Accountability should sit with the organisation that approved the integration and failed to revoke it, even if a vendor or partner technically operated the system. In practice, many security teams encounter this only after a dormant API key, service account, or token is reused outside its intended purpose, rather than through intentional lifecycle management.
How It Works in Practice
The practical answer is to treat every third-party NHI as a governed workload identity with an explicit owner, an expiry condition, and a revocation path. That means the business owner, system owner, and security team all need a shared record of why the identity exists, which system uses it, and what event ends access. Current guidance suggests aligning this with Top 10 NHI Issues and the lifecycle controls in Ultimate Guide to NHIs — What are Non-Human Identities, because unmanaged third-party access is one of the most common sources of persistence.
A workable operating model usually includes:
- an owner named in the CMDB, contract, or service register
- review dates tied to renewal, release, or contract termination
- short-lived secrets or JIT credentials where the integration supports it
- automated revocation when the business purpose ends
- logs showing who approved the access and who confirmed removal
For control language, security teams can map this to the governance expectations in OWASP Non-Human Identity Top 10 and use breach patterns from 52 NHI Breaches Analysis to show how persistent credentials become incident paths. The 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, which is a strong signal that lifecycle controls are often documented but not executed. These controls tend to break down when the third party is embedded in production pipelines and no one owns the final revocation step because the integration is treated as a technical dependency rather than a security-managed identity.
Common Variations and Edge Cases
Tighter third-party control often increases operational overhead, requiring organisations to balance integration speed against revocation certainty. That tradeoff is especially visible in SaaS-to-SaaS automations, MSP-managed tools, and long-lived service accounts where vendors insist that a static credential is the simplest option. Best practice is evolving, but the direction is clear: where possible, use workload identity, scoped tokens, or policy-enforced delegation instead of reusable secrets that survive contract changes.
There is no universal standard for this yet, but practitioners should assume the accountable organisation is still the one that accepted the risk and failed to sunset it. If a vendor hosts the identity on behalf of the business, responsibility may be shared operationally, but accountability for the control failure remains with the organisation that owned the service relationship. That is consistent with the governance emphasis in the OWASP Non-Human Identity Top 10 and the broader lifecycle guidance in Ultimate Guide to NHIs.
One useful exception is emergency access during migration or incident response, where a temporary extension may be justified if it is time-boxed, documented, and reviewed. Outside those cases, dormant third-party NHIs should be treated as a revocation defect, not an acceptable operational residue.
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-03 | Addresses lifecycle, rotation, and revocation of non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access management for external identities. |
| NIST AI RMF | Useful for accountability and governance of autonomous external systems. |
Document accountability and approval paths for third-party identities in AI and automation workflows.
Related resources from NHI Mgmt Group
- Who is accountable for third-party access after a campaign or project ends?
- Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
- How should security teams make NHI best practices usable across the business?
- How can organisations reduce blast radius after a third-party integration compromise?
