What should organisations verify before treating acquisition identity integration as complete?

They should verify that phishing-resistant authentication is deployed consistently, highly privileged accounts have been rationalised, and the same governance standards apply across each inherited environment. If any of those remain split, the identity programme is still exposed.

Why This Matters for Security Teams

Acquisition identity integration is not complete when accounts are merely “connected” to a target directory. Security teams still need to verify that authentication is phishing-resistant, that privileged access has been rationalised, and that inherited environments are governed to the same standard. Until those checks are done, the organisation has merged directories but not reduced risk. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, which means acquisition-driven sprawl often expands the attack surface instead of shrinking it.

This is where inherited technical debt becomes a security issue. A newly integrated estate may still contain legacy MFA gaps, service accounts with broad rights, stale secrets, or local exceptions that bypass central policy. The same pattern appears in post-merger environments and vendor-led migrations: identity coverage can look complete on paper while the most sensitive pathways remain untouched. Current guidance in NIST SP 800-207 Zero Trust Architecture reinforces that trust should be continuously evaluated, not assumed after consolidation. In practice, many security teams discover the remaining gaps only after an inherited account is used for lateral movement or privilege escalation, rather than through a planned integration review.

How It Works in Practice

Organisations should treat acquisition identity integration as a control verification exercise, not a directory-merger milestone. That means proving that each inherited environment now enforces the same authentication, privilege, and governance standards as the parent organisation. The practical sequence usually starts with authentication, because phishing-resistant methods provide a higher assurance baseline than passwords or uneven MFA deployments. It then moves to privilege rationalisation, where access is reviewed account by account, service principal by service principal, and role by role to remove standing excess.

At the governance layer, the question is whether policy is truly uniform. If one environment still permits local admins, unmanaged service accounts, or exceptions for legacy apps, the acquisition is only partially integrated. The same applies to secrets and machine identities: imported systems may contain API keys, certificates, or automation tokens that were never brought into the central lifecycle. NHI Mgmt Group’s 52 NHI Breaches Analysis and Top 10 NHI Issues both illustrate how identity sprawl and weak governance persist long after a transaction closes.

• Verify phishing-resistant authentication for all privileged and administrative paths, not only for standard workforce accounts.
• Inventory inherited privileged accounts, service accounts, and automation identities, then remove duplicates and dormant access.
• Apply one governance model for access review, secret rotation, logging, and exception handling across all environments.
• Validate that inherited systems are enrolled in the same monitoring and incident response workflow as the core estate.

These controls tend to break down when the acquired environment still depends on embedded local credentials, unsupported platforms, or one-time carve-outs that were never removed.

Common Variations and Edge Cases

Tighter acquisition controls often increase integration time and operational friction, requiring organisations to balance risk reduction against business continuity and migration deadlines. That tradeoff is real, especially when the acquired business runs critical systems that cannot be remediated immediately. Current guidance suggests prioritising the highest-risk identity paths first, then sequencing lower-risk remediation behind them.

There is no universal standard for this yet, but the practical test is whether the organisation can show consistent enforcement across exceptions, not just within the cleanest parts of the estate. Some inherited systems may temporarily retain compensating controls, such as segmented access, monitored break-glass accounts, or shorter secret lifetimes, while the long-term remediation plan is executed. Others may need a formal risk acceptance until a legacy application can be modernised or retired. The important point is that acquisition completion should be measured against identity equivalence, not only migration completion. Until the same authentication, privilege, and governance rules apply everywhere, the identity programme remains incomplete.

Related resources from NHI Mgmt Group

• What should organisations verify before relying on self-service identity features?
• How should organisations govern vendor access as part of identity management?
• How should organisations govern SaaS discovery across finance, identity, and endpoint data?
• What breaks when organisations treat SSO as complete access governance?