Identity separation in divestitures: Splitting Tenants, Accounts and NHIs Without Leftover Access

When part of a business is sold, its identities, applications and machine credentials are tangled through the parent's directory, and every one left behind or copied across is access nobody intended to keep. Identity separation in a divestiture means deciding what leaves with the divested business, moving it to a new environment, running a controlled transition period and then cutting every remaining path between the two organisations. This guide gives a separation runbook for Microsoft Entra ID and Microsoft 365, Okta and AWS, with particular attention to service accounts, app registrations, API keys and signing keys, which are the identities most often forgotten. It is for identity architects, IAM and cloud platform leads and M&A integration managers on the seller's side. For acquisitions and the general transition services agreement (TSA) model, see the Identity Integration in M&A Guide; this page goes deeper on the carve-out itself.

Key takeaways

• Separation is three moves, not one. Allocate identities and data, migrate them, then sever every trust, credential and sync that still links the two organisations.
• Non-human identities decide the risk. Service principals, CI tokens, shared API keys with suppliers and certificate private keys can be copied, so separation means rotation, not just reassignment.
• Domains and tenants have hard platform rules. A custom domain can be verified in only one Microsoft Entra tenant, and an AWS account changing organisation keeps any IAM role the old management account could assume unless you delete it.
• The TSA is temporary third-party access. Give it scoped groups, its own conditional access, separate logging and a fixed end date per service.
• Prove the cut. Finish with evidence: sign-in logs showing no cross-organisation access, credential inventories showing rotation, and written confirmation from both sides.

Allocation: deciding what leaves

Start from an inventory, not from the org chart. Every identity object needs one of four outcomes: transfer, clone and rotate, retain, or delete.

Use the inventory from your NHI programme as the baseline; the Service Account Inventory Template lists the fields you need, including owner, business unit and credential type. Where business unit is unknown, use sign-in and API activity over the last 90 days to infer it.

Microsoft Entra ID and Microsoft 365

1. Set TSA access: if the divested business gets its own tenant early, use cross-tenant access settings. Inbound settings control which external users reach your resources, organisational settings override defaults for one partner, and inbound trust settings decide whether you accept their MFA and compliant device claims. Defaults allow B2B collaboration, block B2B direct connect and do not trust external MFA or device claims. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.
2. Migrate mailboxes: cross-tenant mailbox migration requires a Cross Tenant User Data Migration licence per user, a multi-tenant app with the Mailbox.Migration permission in the target, an organisation relationship in each tenant scoped by a mail-enabled security group in the source, and target MailUsers with matching ExchangeGUID and x500 addresses. Batches are limited to 2,000 mailboxes. Mailboxes on hold cannot move, Teams chat and Microsoft 365 Groups do not migrate, and the source mailbox is removed after the move, so agree eDiscovery and retention obligations first.
3. Re-register applications: create new app registrations in the target with new credentials; do not export client secrets. Remove the divested unit's apps from the source after cut-over and review any multi-tenant apps that were consented in both tenants.
4. Remove the domain from the source: a custom domain can be verified in only one Entra tenant. Before deletion, no user name, email or proxy address, group address or application ID URI may reference it. ForceDelete renames references to the onmicrosoft.com domain but is limited to fewer than 1,000 references. Deletion is asynchronous and can take up to 24 hours, so schedule it inside the cut-over window and verify in the target immediately after.
5. Close the TSA: remove organisational cross-tenant settings, delete guest accounts, revoke sessions and remove any cross-tenant synchronisation configuration.

On-premises Active Directory adds forest trusts and Entra Connect or Cloud Sync scope. Remove the divested OUs from sync scope only after target accounts exist, and delete any forest trust created for the transition. See the Microsoft Entra Connect and Cloud Sync Hardening Guide.

Okta

• Transition federation: Okta Org2Org lets a source org authenticate users into a target org and optionally provision them, in a hub and spoke model where the hub is the target. Federation can use OIDC, which Okta recommends, or SAML. During a divestiture the divested business's new org can be the target while the seller's org is the source for the transition.
• Provisioning: Org2Org can push users and groups, create, update and deactivate them, and sync passwords. Secure the connection with OAuth 2.0, Okta's preferred option, rather than an API token, and record the integration as an NHI with an owner and end date.
• Exit: deactivate the Org2Org app and the identity provider in the target, revoke any API tokens created for migration, and review admin role assignments for accounts from the other organisation. See the Okta Security Hardening Guide.

AWS accounts and organisations

1. Check prerequisites: the account must be active, a created member account must be at least 4 days old, the destination organisation at least 7 days old, and the Seller of Record must match. Deregister the account as a delegated administrator for any service first.
2. Remove the old organisation's reach: delete IAM roles the old management account can assume, such as OrganizationAccountAccessRole, because they are not removed automatically. Change the root user email and remove root MFA devices if ownership changes, then register new ones.
3. Move: the new organisation's management account sends an invitation and the migrating account accepts it; the account lands at the root of the new organisation.
4. Replace governance: the old organisation's SCPs stop applying and the new ones start, so replicate required guardrails before the move, and update IAM and resource policies that reference the old organisation ID through aws:PrincipalOrgID.
5. Handle the rest separately: AWS's migration page does not cover IAM Identity Center, organisation CloudTrail trails or AWS RAM shares; review each, because access through them ends or changes when the account leaves. Back up billing and cost reports, which leave with the organisation.

See the AWS Organizations and SCPs Guide and the Cross-Account and Cross-Tenant Access Guide.

Where identity fits: separating non-human identities

Human accounts get disabled at exit; machine credentials are where leftover access hides. In the Microsoft Midnight Blizzard breach, a legacy test tenant without MFA and a legacy OAuth application with elevated access to the corporate tenant were the path in. Carve-outs create exactly these leftovers: test tenants, migration apps and transition integrations that nobody owns once the project ends.

• Rotate, do not reassign: any secret the divested staff or systems could read, including vault paths, CI variables and configuration files, must be rotated on the seller's side after cut-over.
• Migration identities are temporary NHIs: the mailbox migration app, Org2Org integration, sync accounts and data transfer roles need owners, least privilege and a deletion date.
• Supplier and SaaS integrations: OAuth grants and API keys issued by SaaS vendors to the parent must be split by the vendor, not copied; see the Vendor Offboarding and Termination Guide for the exit pattern.
• Certificates and signing keys: issue new code signing, TLS and SAML signing certificates to the divested business; revoke any certificate whose key was exportable by the departing team.
• Decommission properly: follow the NHI Offboarding and Decommissioning Guide for each NHI the seller retires.

How to implement

1. Before signing: agree in the separation agreement which identities, apps and data transfer, the TSA services and end dates, and incident notification duties in both directions.
2. Inventory (weeks 1 to 4): tag every account, group, app, service account, key and certificate with business unit, using activity data where ownership is unclear.
3. Stand up the target: new tenant or org, conditional access baseline, admin accounts with phishing-resistant MFA, logging into the buyer's SIEM.
4. Pilot: move one team end to end, mailbox, files, apps and service accounts, and check what breaks. Keep source accounts disabled rather than deleted for a rollback window.
5. Waves: migrate in batches, rotating NHI credentials as each workload moves.
6. TSA exit per service: on each end date remove access, revoke sessions, delete guest and federation objects, rotate shared secrets.
7. Close-out: 30 days after final exit, review sign-in and audit logs for any cross-organisation access, then delete disabled accounts and migration identities.

Decision guidance

• Move the account or rebuild: transfer AWS accounts or subscriptions when the workload is self-contained; rebuild when it shares networks, identities or data with retained workloads.
• Buyer has an existing IdP: migrate straight into the buyer's tenant or org and skip a standalone NewCo directory, if the TSA is short.
• Standalone NewCo: create a clean tenant rather than cloning the parent's configuration, then apply a hardened baseline.
• Small carve-outs: a few dozen users can often be recreated manually with mail export; the NHI and key rotation steps still apply in full.

Detection and measurement

• Cross-organisation sign-ins after TSA exit: count of sign-ins by the other party's accounts to your tenant, apps or AWS accounts; target zero.
• NHI rotation completion: percentage of credentials exposed to the divested business rotated by cut-over.
• Orphaned migration identities: migration apps, tokens and roles still active after close-out.
• Policy references to the old organisation: remaining aws:PrincipalOrgID or tenant ID references after the move.
• TSA services past end date: number still active beyond the agreed date.

Common failure patterns

• Copying secrets to the new environment: both organisations now share a credential neither can rotate alone.
• Leaving OrganizationAccountAccessRole behind: the seller's management account can still assume a role in the sold account.
• Forgetting the domain dependency: users, groups or app ID URIs still reference the domain, so it cannot be removed on cut-over night.
• TSA without an end date: guest access and federation remain for years.
• Migration tooling never removed: the migration app with mailbox permissions and its client secret outlive the project.
• Ignoring supplier-held credentials: a SaaS vendor still has one integration serving both companies.

Framework mapping

Practitioner checklist

• Every identity object tagged with business unit and an outcome: transfer, clone and rotate, retain or delete.
• TSA access through dedicated groups and organisational cross-tenant settings, with an end date per service.
• Domain references cleared before cut-over night and removal scheduled in the window.
• AWS accounts checked for old management roles, root contacts, SCP replacements and org ID references.
• Org2Org or similar integrations using OAuth 2.0, owned and dated.
• Every secret, key and certificate exposed to the divested business rotated or revoked.
• Migration apps, tokens and roles deleted at close-out.
• Post-exit log review showing no cross-organisation access, confirmed in writing by both sides.

Standards and references

• Microsoft Learn: Cross-tenant mailbox migration
• Microsoft Learn: Manage custom domain names in Microsoft Entra ID
• Microsoft Learn: Cross-tenant access overview
• Okta Help: Integrate Okta Org2Org with Okta
• AWS: Migrating a member account to another organization
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Identity Integration in M&A Guide, Cyber Due Diligence in Mergers and Acquisitions Guide, Joiner-Mover-Leaver Guide, NHI Offboarding and Decommissioning Guide.