Why do acquisition-heavy enterprises struggle to standardize authentication quickly?

Why migration pace, not just policy, slows standardisation

Acquisition-heavy enterprises usually inherit multiple authenticators, directory boundaries, recovery flows, and admin cultures at once. That means the barrier is rarely the authentication method alone, it is the time needed to align ownership, exception handling, and recovery across the new estate. The result is a long period where the business wants one control model, but the operating model still behaves like several.

Phishing-resistant authentication helps because it creates a trust baseline that does not depend on every legacy password practice being normalised first. It is easier to impose a common sign-in expectation than to harmonise every local process, especially when some acquired teams still rely on older help desk workflows, shared admin habits, or inconsistent enforcement of multifactor prompts.

In practice, standardisation slows when each acquired environment carries different assumptions about who can reset accounts, approve exceptions, or access privileged systems. Those assumptions are often invisible until an integration starts, and they can make one identity team look “behind” when it is really negotiating with multiple inherited control models at once. A common phishing-resistant method reduces that drift, but it does not remove the need to reconcile local privilege and recovery rules.

What makes passwords and privileged access the hardest part to unify

Passwords are hard to govern consistently because they sit at the intersection of user convenience, help desk support, and emergency access. In an acquisition, teams often discover that what one company treats as a temporary exception another treats as normal practice. That creates friction around resets, shared accounts, break-glass access, and admin elevation, especially when the combined enterprise has different standards for privileged accounts versus ordinary users.

Privileged access is usually the first place where inconsistency becomes operationally dangerous. If acquired environments keep separate admin boundaries for too long, the enterprise may end up with uneven authentication strength for the people who can change the most. That is why standardisation is not just a login project, it is also an access governance project, because the trust model for administrators must converge before the whole directory estate is fully merged.

Phishing-resistant authentication is useful here because it narrows the attack surface of those privileged sign-ins and makes the new standard less dependent on password quality. For practitioners, the real challenge is sequencing: the enterprise must decide which roles move first, which exceptions remain temporary, and which legacy paths are too risky to leave in place during the transition.

How to standardise earlier without waiting for perfect directory consolidation

The practical route is to standardise the highest-risk populations first, then expand outward. Start with privileged users, remote access, and recovery paths, because those are the areas where inconsistent authentication creates the most leverage for attackers and the most friction for governance. That approach lets the enterprise establish a common trust layer even while directories, application entitlements, and local support models are still being rationalised.

Current guidance from NIST supports using stronger authenticators and phishing-resistant methods where assurance matters most, especially when an enterprise needs a repeatable baseline across mixed environments. For implementation detail on assurance levels and phishing-resistant authentication, see NIST SP 800-63 Digital Identity Guidelines. For a broader practitioner view of rollout trade-offs, the Workforce Identity Security Guide explains why recovery, SSO, and federation must be planned alongside the new sign-in method.

When acquisition timelines are messy, the key decision is whether a control can be enforced before full consolidation. If it can, it should usually move ahead of directory rationalisation; if it cannot, it should be treated as a temporary exception with a clear expiry and owner. That sequencing is what turns authentication standardisation from a merger aspiration into an enforceable control model.

Risk and Threat Considerations

Acquisition complexity creates a long window where inherited logins, recovery processes, and admin exceptions coexist. That gap is attractive to attackers because it gives them multiple ways to find the weakest trust path, especially where one acquired business still allows older authentication patterns or lighter privileged-access scrutiny.

Failure mechanism: Inconsistent authentication policy across merged environments leaves legacy accounts, recovery flows, or privileged paths available longer than intended, which can let attackers exploit the weakest inherited practice instead of the intended enterprise standard.

Impact: The likely result is delayed standardisation, higher phishing and account-takeover exposure, and a larger blast radius if a privileged account in one acquired environment remains easier to compromise than the enterprise policy assumes.

Practitioner Guidance

What to prioritise: Standardise privileged users, remote access, and account recovery first. Those are the controls that most quickly reduce risk while still giving the enterprise a common authentication baseline across acquired entities.

What to verify: Confirm that the new method is enforceable across every inherited directory, help desk process, and exception path, not just in the target enterprise tenant. If an acquired team can still bypass the intended flow for admin access or resets, the standard is not yet real.

Decision rule: If a control protects high-impact access before directory merger is complete, implement it early and treat remaining legacy paths as time-bound exceptions. If it cannot be enforced consistently, finish the supporting governance work first.

Practitioner takeaway: The blocker is usually not the choice of authenticator, it is the enterprise’s ability to impose one trust model across many inherited operating models without leaving privileged exceptions behind.

Related resources from NHI Mgmt Group

• When should enterprises review their extension policies?
• Why do legacy PAM programs struggle with cloud authentication?
• Why do SAP authentication and perimeter issues increase enterprise risk so quickly?
• Why do employee authentication problems become security problems so quickly?