How should security teams handle third-party NHI access offboarding?

Why This Matters for Security Teams

Third-party NHI offboarding is where lifecycle governance becomes operational. External integrators often hold OAuth grants, service account keys, API tokens, and webhook credentials that outlive the business need that justified them. If the vendor relationship ends, contract scope changes, or an application is retired, those secrets should be revoked immediately and verified, not left to expire someday. The risk is not abstract: Entro Security reports that 91% of former employee tokens remain active after offboarding in its 2025 State of NHIs and Secrets in Cybersecurity, which is a useful proxy for how weak offboarding discipline can become across identities of every kind. The control problem is broader than one token. It includes app consent, direct API keys, CI/CD secrets, and any delegated privilege path that a partner can still use. Current guidance from OWASP Non-Human Identity Top 10 aligns with the same idea: treat secrets and machine identities as high-value credentials with explicit lifecycle management. In practice, many security teams discover abandoned third-party access only after an incident review, not through deliberate offboarding checks.

How It Works in Practice

Offboarding should start with an inventory of every third-party NHI tied to the relationship, then move through revoke, rotate, and verify. That means identifying OAuth app consents, service accounts, machine-to-machine tokens, API keys, certificates, and any secrets shared through vaults or deployment pipelines. The best practice is to map each credential to an owner, a business purpose, and a termination trigger. When the trigger fires, revoke the credential, remove the app consent, invalidate refresh paths, and confirm that downstream systems no longer accept the identity. A practical sequence looks like this:

• Locate all third-party NHIs linked to the vendor or partner.
• Revoke access in the source system first, not just in a ticket.
• Rotate shared secrets if the credential may have been copied or cached.
• Check for shadow copies in code, CI variables, and vault replicas.
• Validate the revocation with a live test, not a status update.

This approach matches NHIMG lifecycle guidance in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where lifecycle ownership is treated as a control, not a documentation exercise. For governance, pairing this with identity and access principles from OWASP Non-Human Identity Top 10 helps teams focus on credential hygiene, privilege reduction, and revocation assurance. These controls tend to break down when the third party uses federated tooling across multiple SaaS platforms because consent, token refresh, and embedded secrets are each revoked on different schedules.

Common Variations and Edge Cases

Tighter offboarding often increases coordination overhead, requiring organisations to balance rapid revocation against the risk of breaking production integrations. That tradeoff is real, especially when a partner supports multiple services or when a shared service account backs legacy workflows. In those cases, best practice is evolving toward short-lived credentials, explicit expiry, and just-in-time access for the smallest viable window. If the vendor needs ongoing access for transition support, create a temporary exception with a fixed end date, a named approver, and a post-expiry revocation test. There is no universal standard for every offboarding scenario yet, but current guidance suggests separating three cases: loss of commercial relationship, end of technical need, and suspected compromise. Each case should trigger different urgency, yet all should end with verified revocation. Where autonomous tooling is involved, the same logic applies to workload identity and delegated machine access, not just human-held admin accounts. The 52 NHI Breaches Analysis shows how often failures cluster around lifecycle gaps rather than novel attack methods, and that is why offboarding needs a tested runbook, not a one-time checklist. For teams formalising the control set, Top 10 NHI Issues is a useful lens for prioritising revocation, rotation, visibility, and ownership. In shared platform environments, offboarding often fails when one remaining integration keeps the old secret alive through a hidden dependency or duplicate copy.

Related resources from NHI Mgmt Group

• How should security teams handle standing access for third-party vendors?
• How should security teams handle third-party access that looks legitimate after a supplier breach?
• How should security teams handle NHIs exposed during employee offboarding?
• How should security teams govern third-party AI agents that use OAuth access?