How should security teams standardise identity after an acquisition?

Security teams should begin with an inventory of inherited directories, authentication methods, and privileged accounts, then set one target identity standard for the merged estate. The goal is to remove duplicated trust models early, especially where admin access crosses business boundaries. Without that consolidation, identity sprawl becomes a permanent integration cost.

Why This Matters for Security Teams

Identity standardisation after an acquisition is rarely just an IAM cleanup exercise. It is a control-plane decision that determines whether inherited users, service accounts, API keys, and admin pathways can be governed consistently across the merged estate. When multiple directories, MFA methods, and privilege models remain in place, security teams inherit duplicated trust and inconsistent enforcement. That is where attack paths multiply, especially across business units that were never designed to trust one another.

For NHI-heavy environments, the risk is amplified because machine identities often outnumber human identities by orders of magnitude, and their secrets are frequently embedded in code, CI/CD, or unmanaged vaults. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, while 97% of NHIs carry excessive privileges. That is the baseline problem an acquisition inherits, not an edge case. Current guidance from NIST Cybersecurity Framework 2.0 supports standardising governance around risk and control consistency, but the operational challenge is making that consistent across two or more identity estates at once.

In practice, many security teams discover the real identity sprawl only after a legacy admin account or service credential has already bridged the two organisations.

How It Works in Practice

The standard approach is to define one target identity architecture for the combined organisation and map every inherited identity source to it. That means deciding which directory becomes authoritative, what MFA and conditional access rules apply, how privileged access is brokered, and which accounts must be converted to managed service identities, federation, or decommissioning. The goal is not to preserve every historical control. The goal is to reduce trust translation layers that attackers can exploit.

A practical sequence usually looks like this:

• Inventory directories, identity providers, PAM tooling, and local admin domains.
• Classify identities as human, machine, vendor, break-glass, or legacy.
• Identify cross-boundary privileges, especially where one acquired business can administer another.
• Set the merged standard for authentication, federation, rotation, and logging.
• Migrate high-risk credentials first, starting with privileged and externally exposed accounts.
• Retire duplicated trust paths only after dependencies are mapped and tested.

For machine access, the same logic applies but the controls differ. Standardisation should favour short-lived credentials, workload identity, and central policy evaluation rather than copying human IAM patterns onto services. The Top 10 NHI Issues research is a useful reminder that rotation gaps, exposed secrets, and over-privileged accounts are persistent failure modes after mergers. NIST’s identity guidance also reinforces that authentication strength and assurance should be aligned to the risk of the transaction, not to organisational habit. Where possible, teams should use federation and just-in-time privileged access rather than create new static credentials during the integration period.

These controls tend to break down when the acquired environment depends on unmanaged local accounts, embedded secrets in application code, or mutually trusted directories that cannot be cleanly federated.

Common Variations and Edge Cases

Tighter standardisation often increases short-term disruption, requiring organisations to balance integration speed against outage risk and business continuity. That tradeoff is real, especially in acquisitions where critical systems cannot be replatformed immediately.

One common exception is a regulated subsidiary that must retain partial autonomy for legal or operational reasons. In that case, current guidance suggests standardising policy, logging, and privileged access even if directory consolidation is staged. Another edge case is a carve-out or divestiture, where identity standards should prioritise clean separation rather than full unification. Security teams should also distinguish between temporary coexistence and long-term dual trust. Coexistence is acceptable only if it has a sunset date and clear control ownership.

For NHI-heavy mergers, the hardest cases are service accounts tied to legacy applications, external integrations, and shared automation. Those accounts often cannot be merged cleanly without redesign. In those situations, best practice is evolving toward workload identity and scoped, short-lived credentials rather than preserving old static secrets indefinitely. That aligns with broader Ultimate Guide to NHIs — Standards guidance, but there is no universal standard for every acquired platform yet.

The safe rule is simple: standardise the policy layer first, then reduce the number of identity systems as dependencies allow.

Related resources from NHI Mgmt Group

• What do security teams get wrong about derived identity attributes?
• How should security teams handle disconnected applications that sit outside identity tooling?
• How should security teams handle identity features built inside product engineering teams?
• How should security teams reduce stale identity data in access reviews?