What happens when two organisations combine privileged access without reconciling NHIs?

What the merged estate inherits when privilege is combined without NHI reconciliation

When two organisations merge access estates without first reconciling non-human identities, the result is usually not a clean union but an accumulation. Service accounts, API credentials, automation tokens, and inherited entitlements often overlap in ways neither side documented well enough to expose. That creates immediate uncertainty about who, or what, can still reach critical systems.

The practical issue is not only excess access, but mismatched access models. One organisation may use vaulting and rotation while the other relies on long-lived credentials, so the combined estate can preserve the weakest patterns from both sides. In merger terms, that means the inherited environment often starts life with hidden reach, stale privilege, and no shared baseline for control.

That is why established NHI inventories and ownership records matter before access consolidation. A merger review that starts from privileged access alone will miss the underlying machine and service identities that actually hold the authority. NHIs can outlive people, so their permissions, dependencies, and trust paths need separate treatment from human admin accounts. Ultimate Guide to NHIs — What are Non-Human Identities and Service Account Security Guide are useful reference points for that inventory step.

Why overlapping permissions become toxic in a merged environment

Overlapping privilege is dangerous because it can create unexpected effective access, especially where one identity can authenticate into another control plane, vault, or admin boundary. A credential that looked harmless in one estate may become powerful after routing, trust, or role inheritance changes. In practice, the combined environment can expose paths to production data, identity stores, or management planes that neither organisation intended to keep open.

That risk grows when the merge preserves duplicate admin channels, shared service accounts, or broad cloud roles. The result can be toxic combinations, where a low-friction automation path plus a privileged management role equals a direct escalation route. Privileged Access Management Guide, Cloud PAM and CIEM Guide, and Just-in-Time Access and Zero Standing Privilege Guide all speak to the controls that reduce that blast radius.

What makes this especially difficult in a merger is that the bad combinations are not always visible in the source systems. They emerge only when entitlements are evaluated together across directories, cloud platforms, vaults, and third-party tools. That is why reconciliation has to consider effective access, not just named roles.

How to decide what to fix first after the consolidation

The first priority is to map all privileged NHIs to business function and system reach, then identify which identities can still act across both estates. A merger clean-up should focus on credentials with production access, cross-environment reach, or authority over other identities before it tries to optimise the rest of the access model. That sequencing is what prevents “unknown but still working” access from surviving the integration.

What to verify: Confirm ownership, last-use evidence, and rotation status for every privileged service account, token, key, or certificate that survived the merger. If you cannot explain why an NHI still exists, what it can reach, and who can revoke it, treat it as active exposure rather than dormant history.

Decision rule: If a non-human identity can reach a production control plane, a secrets store, or an administrative API, reconcile and constrain it before broader role harmonisation. If it only supports a low-risk integration, it can usually wait until the high-impact paths are closed.

Practitioner takeaway: Mergers fail on hidden continuity, not just visible duplication, so the winning move is to collapse effective privilege first and normalise identities second.

Risk and Threat Considerations

Unreconciled NHIs create a fast path to compromise because attackers do not need to break the merger, they can exploit the inherited trust gaps it leaves behind. Overlapping permissions, stale credentials, and duplicated admin routes make it easier to move laterally, impersonate automation, or abuse cross-domain trust before defenders understand the new boundary set.

Failure mechanism: The merger combines trust relationships without revalidating which non-human identities still need them, so old access paths remain live and can be chained into higher privilege or broader lateral movement.

Impact: Attack surface expands immediately, privileged actions become harder to attribute, and a single compromised NHI can now expose both organisations' critical systems, secrets, and management planes.

Practitioner Guidance

What to prioritise: Start with the identities that can change configuration, read secrets, or impersonate other systems. Those are the ones most likely to turn merger complexity into real compromise.

What to measure: Track the count of privileged NHIs with unclear ownership, long-lived credentials, or cross-environment reach. If that number is not falling quickly after integration, the consolidation is still increasing risk.

Common mistake: Treating merged access as an HR or directory clean-up rather than a privilege and trust problem. The visible user merge may finish quickly while the non-human access graph remains dangerous.

Practitioner takeaway: In a merger, every retained NHI should be justified by current business need and bounded by the smallest effective privilege, otherwise the combined estate becomes more privileged than either predecessor.

Related resources from NHI Mgmt Group

• What happens when organisations rely on two-factor authentication without stronger password and access policies?
• What happens when healthcare organisations grant privileged access without strong session monitoring and audit trails?
• What happens when organisations try to meet NIS 2 without controlling privileged access?
• What happens when organisations try to meet GDPR obligations without strong privileged access governance?