They should revoke access, disable related integration users, rotate any shared secrets, and confirm that no secondary apps still depend on the same trust relationship. Offboarding must be treated as a complete lifecycle event, not a single token revocation step.
When a Third-Party NHI Is No Longer Trusted, What Has to Happen?
Trust loss should be treated as a lifecycle failure, not a narrow credential issue. If a third-party NHI is compromised, over-privileged, abandoned, or simply no longer acceptable, the organisation should remove its access path, remove any local dependencies, and make sure the trust relationship cannot still be used indirectly by other applications or integrations.
What the Offboarding Scope Needs to Include
The first job is to identify every place that trust was established, including direct logins, API credentials, federated tokens, OAuth grants, certificates, secrets, and any integration users that were created to support the third party. The control point is broader than the token itself: a trust relationship can persist through reused secrets, hidden service accounts, delegated access, or downstream apps that copied the same credential model. NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks and the Top 10 NHI Issues both reinforce that lifecycle control fails when organisations focus on one secret and ignore the surrounding access estate.
In practice, the organisation should revoke the trust at the source, then verify that no alternate path still allows the third party to act. If the integration was built around a shared service account or a reused key pair, simply changing one secret is not enough because the same trust model may still exist elsewhere. That is why offboarding needs dependency mapping, not just a revocation ticket.
What Good Offboarding Looks Like in Practice
Good offboarding removes the third-party identity from active use, disables any related integration accounts, rotates the shared material that could still authenticate the old path, and checks for connected systems that are silently depending on the same trust relationship. NHIMG’s Service Account Security Guide is useful here because many third-party NHIs behave like service accounts in operational terms, even when they are managed outside your perimeter. The same applies to SaaS-to-SaaS and OAuth App Governance Guide when the trust path is a connected application or grant that can survive after the vendor relationship changes.
Where the trust relationship is part of a broader integration chain, the cleaner approach is to remove it from the environment in stages: first stop active access, then rotate or replace shared secrets, then confirm that dependent apps fail closed rather than continuing on a stale trust assumption. If a downstream app still works after the supposed offboarding, the offboarding is incomplete.
Why Third-Party Trust Loss Can Turn Into a Broader Exposure
A third-party NHI often sits inside a wider ecosystem of accounts, API connections, and automation. If the organisation leaves any part of that ecosystem active, the former partner may retain indirect reach even after the original login is revoked. That creates residual access risk, hidden coupling, and the possibility that an attacker who later obtains the old secret can still pivot through a forgotten integration path. The same issue shows up in breach analysis across compromised OAuth tokens and SaaS-to-SaaS trust chains, which is why NHIMG’s 52 NHI Breaches Report and Salesloft OAuth token breach are relevant examples of why token revocation alone is not a complete control.
Failure mechanism: The organisation revokes the obvious credential but leaves a shared secret, delegated grant, or integration user active somewhere else in the chain, so the trust relationship remains usable.
Impact: Former third-party access can persist, downstream applications may keep operating on stale trust, and a later compromise of the residual material can reopen access without warning.
Risk and Threat Considerations
Third-party NHI offboarding is high-risk because residual trust is often invisible until it is abused. A stale integration user, shared secret, or lingering OAuth grant can become an easy re-entry point if the original vendor account is later compromised or the credential is reused elsewhere.
Failure mechanism: The environment still accepts an old authentication path, so the trust break is only partial and the attacker can exploit the leftover dependency rather than the original account.
Impact: Unauthorized access can continue after the relationship is supposed to have ended, and the organisation may not notice until data access, automation misuse, or lateral movement has already occurred.
Practitioner Guidance
What to prioritise: Remove active access first, then chase every dependent system that could still honour the same secret, token, certificate, or grant.
What to measure: Offboarding is not complete until every related trust artifact is either revoked, rotated, or proven unused.
Practitioner takeaway: Treat third-party NHI offboarding as a containment problem, because the real risk is not the departing vendor, it is the unseen trust residue they leave behind.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Directly covers ending third-party NHI trust and revoking residual access paths. |
| NHI-02 — Secret Leakage | Shared secrets and tokens can preserve trust after the relationship ends. | |
| NHI-09 — NHI Reuse | Reused trust material can keep other apps reachable after a third party is offboarded. | |
| Recommendation — Revoke every related credential, grant, and integration path before closing the offboarding event. Rotate exposed secrets and verify no stale copies still authenticate anywhere. Inventory and eliminate reused credentials or grants across all dependent systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central when a trusted third-party NHI is withdrawn. |
| AC-2 — Account Management | Integration users and related accounts must be disabled or removed during offboarding. | |
| AC-6 — Least Privilege | Residual access from overbroad third-party permissions magnifies offboarding risk. | |
| Recommendation — Rotate or revoke authenticators and validate that retired ones no longer work. Disable or remove the third-party-related accounts once trust ends. Reduce third-party entitlements to the minimum before and after revocation. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be removed when a third party is no longer trusted. |
| Recommendation — Withdraw third-party access rights promptly and confirm removal across all systems. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud integrations often rely on third-party identities, grants, and shared secrets. |
| Recommendation — Govern third-party identities centrally and verify offboarding across connected cloud services. | ||
Practitioner Guidance
What to verify: Confirm that revocation happened at every trust layer, not just the primary login. You should be able to show the credential or grant was disabled, the integration account was removed or frozen, and any shared secret was rotated everywhere it was used.
Decision rule: If the third party ever had the ability to authenticate to production, treat offboarding as a change event that needs dependency validation, not a mailbox-level or ticket-level closeout.
What practitioners underestimate: The most common miss is secondary dependency reuse, where another application, script, or automation still depends on the same trust path even after the vendor relationship has ended.
Practitioner takeaway: When trust is lost, the objective is not to “revoke access” in the abstract, but to eliminate every surviving route by which the old third-party NHI could still be accepted anywhere in the environment.
Related resources from NHI Mgmt Group
- What breaks when a trusted third-party NHI behaves like a threat actor?
- What happens when organisations allow third-party apps to keep OAuth access after the user no longer needs it?
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What is the difference between runtime protection and NHI lifecycle management?