The acquiring and divesting organisations both remain accountable until access separation is provable, because shared systems create overlapping control obligations. Regulatory teams will expect evidence that privileged access, orphaned accounts, and residual entitlements were identified and removed without breaking the remaining business. The practical answer is to assign explicit ownership and validate each removal step.
Why This Matters for Security Teams
Divestitures rarely cleanly separate identity and access on day one. Shared applications, directory groups, service accounts, API keys, and admin consoles can keep both organisations operational while the deal closes, but that same overlap makes accountability ambiguous. The control problem is not just who owns the system, but who can prove that access has been reduced without disrupting the carved-out business.
Security teams should treat this as a dual-obligation period. Until access separation is evidenced, both the acquiring and divesting organisations retain exposure for privileged access, orphaned accounts, and residual entitlements. That expectation aligns with OWASP Non-Human Identity Top 10 guidance on overprivileged non-human access, and with NHI Management Group’s reporting that Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes.
In practice, many security teams discover separation gaps only after deal integration teams have already reused shared credentials, rather than through intentional access governance.
How It Works in Practice
The practical answer is explicit ownership plus provable removal. Each shared system should have a named accountable party on both sides of the transaction, with a documented cutover plan for every identity type: human admin accounts, service accounts, machine-to-machine tokens, secrets stored in CI/CD, and delegated support access. The control objective is simple: no one should rely on inherited access after the separation date unless it is reapproved and traceable.
In mature programs, this is handled as a sequence of evidence-backed steps. First, inventory all identities and their entitlements. Then classify which access is required for the remaining business, which must be transferred, and which must be revoked. Next, rotate shared secrets, disable stale accounts, and reissue access through controlled channels. Finally, validate by testing that the divested entity can no longer authenticate, while the retained business can still operate. That approach maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls for access restriction and account management, and to the 52 NHI Breaches Analysis, which shows how credential reuse and poor lifecycle control turn routine access into breach material.
- Assign a deal-specific access owner for each shared platform and directory.
- Track privileged, non-human, and break-glass access separately from standard user access.
- Rotate secrets before and after cutover, not only after termination notices.
- Retain logs, approvals, and validation tests as evidence for regulators and auditors.
These controls tend to break down when shared infrastructure is deeply embedded in the surviving company because identity dependencies are hidden inside automation, scripts, and long-lived integrations.
Common Variations and Edge Cases
Tighter access separation often increases operational disruption, requiring organisations to balance clean entitlement removal against business continuity. That tradeoff is especially visible when a divested unit depends on the same IAM tenant, cloud landing zone, or secrets store as the retained business. Current guidance suggests separating access by function first, then by environment, because a forced full split can break critical workflows before replacements are ready.
There is no universal standard for this yet, but best practice is to treat temporary overlap as an exception with expiry dates, compensating monitoring, and explicit sign-off from both sides. Shared vendor-admin portals, outsourced operations, and inherited break-glass accounts deserve special scrutiny because they often survive formal cutover long after the transaction closes. For broader lifecycle control expectations, the NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference point, especially where excessive privileges and weak offboarding create residual exposure.
In these cases, accountability remains shared until the final evidence package shows that privileged access, secrets, and orphaned entitlements were either removed or reissued under the correct owner.
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, NIST SP 800-53 Rev 5 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 | Divestitures often leave stale NHI credentials and inherited access behind. |
| NIST CSF 2.0 | PR.AC-4 | Shared-system separation depends on restricting and reviewing access rights. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management governs creation, disablement, and removal during a divestiture. |
| NIST AI RMF | GOVERN | Accountability for access decisions requires clear governance and evidence. |
Inventory and revoke shared NHI credentials before cutover, then prove they no longer authenticate.
