How should organisations rebuild identity governance after a carve-out or similar infrastructure separation?

Why This Matters for Security Teams

A carve-out breaks the assumptions that identity governance was built on. Group memberships, delegated admin rights, shared vaults, and inherited service accounts often cross the new boundary even when the infrastructure is split cleanly. That creates immediate risk: access can remain valid after business ownership changes, and offboarding logic may still point to the old parent organisation. NHI Mgmt Group research shows that only 20% of organisations have formal processes for revoking API keys and even fewer rotate them consistently, which is exactly why carve-outs become identity events, not just IT projects. See the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for the baseline control model.

The practical mistake is assuming that directory synchronization and firewall segmentation are enough. Identity governance must be re-authored for the new legal entity, including who approves access, who owns privileged roles, where secrets live, and how exceptions are reviewed. In practice, many security teams discover stale trust relationships only after a vendor integration, automation job, or privileged service account has already bridged the separated environments.

How It Works in Practice

Start by rebuilding the identity control plane in the same order you would rebuild a production dependency map: inventory, classify, sever, reissue, and validate. That inventory must include human accounts, service accounts, API keys, certificates, vault entries, federated trust links, break-glass access, and third-party integrations. For NHI-heavy environments, the first pass should also identify which identities are embedded in CI/CD, infrastructure automation, and application code, because those are the hardest to see and the slowest to retire. The lifecycle approach in the Ultimate Guide to NHIs aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access enforcement, auditing, and account lifecycle governance.

• Separate administrative domains first, so the new entity can approve and revoke access without relying on the parent.
• Reissue credentials under the new boundary instead of copying old entitlements forward.
• Rebuild RBAC and approval workflows from business ownership, not from the legacy org chart.
• Rotate secrets, tokens, and certificates immediately where trust was inherited.
• Review machine-to-machine trust chains, including SSO, SCIM, LDAP, CI/CD, and cloud roles.

Good carve-out governance also means validating that offboarding works end to end. If the parent company can still revoke, approve, or audit access in the separated environment, the boundary is not real. The same applies to shared vaults and inherited privileged roles. Organisations that want a cleaner operating model should map every entitlement back to a named owner and a documented business justification, then test removal and escalation paths before the separation is declared complete.

These controls tend to break down when shared directories, domain trusts, or DevOps automation still depend on the old parent tenancy because the technical dependency survives longer than the legal separation.

Common Variations and Edge Cases

Tighter identity separation often increases operational overhead, requiring organisations to balance security certainty against business continuity. That tradeoff is especially visible when the carve-out includes shared SaaS platforms, centralised secrets management, or legacy applications that cannot support rapid federation changes. In those cases, current guidance suggests using compensating controls rather than accepting inherited access by default: time-bound exceptions, additional monitoring, and explicit sign-off for every remaining trust relationship.

There is no universal standard for how quickly every identity should be reissued after a carve-out, but the safest approach is to prioritise privileged human access, then machine identities that can reach production, then lower-risk accounts. The most common failure mode is leaving “temporary” cross-boundary access in place long after go-live. That is why the Top 10 NHI Issues and the 52 NHI Breaches Analysis are useful references when deciding where inherited trust is most likely to persist.

Carve-outs that involve regulated workloads, critical infrastructure, or complex multi-cloud estates usually need more than a one-time remediation. They need a standing identity governance operating model for the new entity, with periodic entitlement review, secret rotation, and ownership attestation. Without that, the organisation has separated its infrastructure but not its authority model.

Related resources from NHI Mgmt Group

• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• How should organisations evaluate identity governance programmes when they need both compliance control and measurable cost reduction?
• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
• Why do organisations struggle to keep identity governance effective during rapid growth?