How should teams handle offboarding during a divestiture?

Why This Matters for Security Teams

Divestiture offboarding is one of the few identity events where speed, legal separation, and security correctness all collide. The main risk is not just whether an account is deleted, but whether the departing entity retains hidden trust paths through service accounts, shared automation, API keys, vault roles, or federation links. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong indicator that divestitures often inherit weak lifecycle discipline.

The challenge is broader than human account closure. NIST’s NIST Cybersecurity Framework 2.0 reinforces that identity, access, and asset management must support continuous governance, not just point-in-time deprovisioning. During a carve-out, teams must separate what is transferred, what is revoked, and what must be reissued under a new trust boundary. In practice, many security teams discover lingering machine access only after the business separation is already underway, rather than through intentional pre-close identity inventory.

How It Works in Practice

Handle divestiture offboarding as a revocation program with evidence, owners, and deadlines. Start by inventorying all NHIs tied to the separating business unit, including service accounts, CI/CD tokens, workload identities, vault leases, certificate chains, and third-party integrations. Then classify each identity into one of three buckets: transfer to the new entity, terminate entirely, or replace with a newly issued identity under the remaining organisation’s trust domain. The NHI Lifecycle Management Guide is useful here because it frames offboarding as a lifecycle control, not an administrative cleanup.

Operationally, the safest sequence is:

• Freeze new credential issuance for in-scope systems before separation execution.
• Revoke shared admin paths, break federation links, and disable inheritance from parent-group roles.
• Rotate secrets and certificates that may have been exposed to both entities.
• Confirm vault policies, API gateways, and CI/CD runners no longer trust the departing organisation.
• Validate revocation with logs, token introspection, and access tests from the outside.

This matters because lingering exposure is common. NHI Mgmt Group’s research links the lifecycle problem to widespread overprivilege and poor visibility, and the Entro Security findings in The 2025 State of NHIs and Secrets in Cybersecurity show that 91% of former employee tokens remain active after offboarding, which illustrates how easily stale trust persists when revocation is treated as a checklist item rather than a verification exercise. These controls tend to break down when the divestiture spans multiple clouds and shared vaults because ownership boundaries are unclear and revocation dependencies are hard to sequence.

Common Variations and Edge Cases

Tighter offboarding often increases business disruption, requiring organisations to balance fast separation against the risk of breaking production dependencies. That tradeoff is real when the departing entity still supports critical workloads, shared customers, or regulated records. Current guidance suggests using short-lived bridge access only where there is a documented transition need, with explicit expiry and monitoring, but there is no universal standard for this yet.

Edge cases usually involve credentials that cannot be cleanly transferred. Examples include certificates pinned in legacy applications, embedded API keys in code, shared secrets in unmanaged automation, and vendor-managed accounts tied to joint operations. In those cases, revocation should be paired with replacement: issue new identities, rebind trust, and prove that old credentials no longer authenticate. A second useful reference is Top 10 NHI Issues, which helps teams identify the most common hidden failure modes before legal separation closes.

For highly regulated environments, the hardest part is evidence. Security teams should preserve proof of revocation, rotation, and access testing so that audit, legal, and incident response can all confirm the former entity no longer has standing trust. Where shared infrastructure cannot be avoided, the remaining organisation should rebuild trust boundaries rather than inherit them.

Related resources from NHI Mgmt Group

• How should security teams handle NHIs exposed during employee offboarding?
• How should teams handle SaaS entitlements that also rely on service accounts or API keys?
• What do security teams get wrong about offboarding device access?
• What should teams get wrong about offboarding in SaaS environments?