Without that mapping, the organization can inherit an environment with unclear ownership, unknown account behavior, and incomplete access controls. That makes it harder to consolidate safely, increases the chance of overlooked risky accounts, and slows operational readiness. In practice, the team ends up managing the acquired environment with too little context to judge whether access is appropriate or suspicious.
Why a domain merge becomes harder once access is not mapped first
A merger is not just a directory cleanup exercise. If service accounts and user access are not inventoried before domains are combined, the acquiring team inherits unclear ownership, unknown dependencies, and access paths that may still be active but poorly understood. That creates immediate uncertainty about who can do what, where those permissions are used, and whether any account is now overextended.
The practical problem is that merger work depends on trust decisions. Without a pre-merge map, you cannot easily separate legitimate application behavior from stale access, shared credentials, or accounts that were granted for a temporary business need and never removed. That means the first days of integration often go to discovery and containment rather than controlled consolidation.
For organisations that want a structured baseline, the access and lifecycle issues here align closely with the OWASP Non-Human Identity Top 10 and the control expectations in CIS Controls v8, especially around account management, least privilege, and discovery.
What typically goes wrong during the merge
The first failure mode is ownership ambiguity. If the organisation cannot say which team owns a service account, whether it is tied to an application, or whether it still has a current business purpose, then revocation decisions become risky and slow. In a healthcare setting that often affects integration services, reporting jobs, interface engines, and vendor connections that are easy to overlook but difficult to reconstruct later.
The second failure mode is permission inheritance. When domains are joined before access is rationalised, accounts can retain broad rights from both environments, or keep access that was acceptable in one domain but excessive in the combined one. That expands the blast radius of any compromise and can leave the merged environment with hidden pathways into patient data, clinical systems, or administrative tools.
The third failure mode is operational drag. Teams end up validating accounts one by one after the fact, which delays cutover, troubleshooting, and steady-state support. A useful reference point is the NHI guidance on visibility and overprivilege in NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks, because the same patterns show up when inherited access has not been mapped in advance.
The control implication is straightforward: access mapping is not a documentation task, it is a prerequisite for safe consolidation. If the team cannot trace ownership, purpose, and effective permissions, the merge should be treated as an access-risk event rather than a routine directory change.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Discovery and Inventory | Inherited service accounts must be found before domain merge. |
| NHI-02 — Secrets and Credential Management | Merged environments can inherit stale credentials and hidden access paths. | |
| NHI-03 — Privileges and Access Control | Unmapped access can produce excessive permissions after merger. | |
| Recommendation — Inventory all service accounts and map their owners before consolidating domains. Rotate or revoke inherited credentials before allowing cross-domain access. Reassess effective permissions and reduce any access beyond stated business need. | ||
| CIS Controls v8 | 6.3 — Account Management | Account ownership and lifecycle must be validated before integration. |
| 6.5 — Access Rights Management | Domain merging changes effective permissions and requires revalidation. | |
| 5.3 — Account Inventory and Control | A merger needs a complete account inventory to avoid hidden access. | |
| Recommendation — Remove or disable accounts that cannot be tied to a current business owner. Review inherited access rights and strip any permissions no longer required. Build and maintain a complete inventory of user and service accounts before cutover. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Domain merger decisions depend on knowing who can access what. |
| ID.AM-01 — Physical Devices and Systems Inventoried | Merged environments need accurate asset and account inventory to control access. | |
| Recommendation — Verify identities and access paths before granting merged-domain connectivity. Maintain an up-to-date inventory of systems and accounts that the merger will inherit. | ||
Practitioner Guidance
What to prioritise: Start with the accounts that can authenticate to production systems, automation paths, and any access that bridges multiple environments. Those are the highest-value paths to validate before cutover because they create the largest hidden blast radius if they are wrong.
What to verify: Confirm for each non-human account and privileged user that there is a named owner, a documented business function, a current system dependency, and a revocation path. If any of those cannot be proven, treat the account as unresolved risk until the dependency is understood.
Common mistake: Teams often merge directories first and assume they can clean up later. In practice, later cleanup is slower and more dangerous because permissions, logs, and application dependencies have already been blended, making it harder to tell whether an account is legitimate or simply still active.
Practitioner takeaway: The safest merger is the one that can prove who owns each access path before it is consolidated, not the one that discovers risky accounts after the environments have already been joined.
Related resources from NHI Mgmt Group
- When do service accounts become a higher risk than ordinary user accounts?
- What happens when service accounts are left without ownership or access reviews?
- What happens when user access reviews are not automated for a system like Symitar?
- What happens when stale access in a directory service is left unreviewed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
