Should organisations unify policy or federate identity systems during M&A?

That depends on maturity, regulatory pressure, and operational complexity. Federation can preserve separation while linking trust, but it does not remove the need for shared NHI governance. If the organisation cannot enforce the same lifecycle rules in both estates, unification without policy alignment only hides the risk.

When to unify policy instead of leaving two identity estates separate

In M&A, unifying policy is usually the right move when the buyer needs consistent access decisions, auditability, and offboarding across both estates. Separate directories can coexist for a while, but policy divergence quickly becomes a governance problem if the same role, application, or privileged workflow is treated differently after the merger.

The practical test is whether the combined organisation can apply the same rules for joiner, mover, leaver, privilege approval, and exception handling. If it cannot, “federation plus loose local policy” often preserves technical separation while leaving entitlement risk unresolved.

Policy unification does not mean one platform on day one. It means one decision model for who can get access, under what conditions, and who owns the review cycle. In many deals, the safer sequence is to standardise policy first, then decide whether directory consolidation, trust federation, or application-by-application coexistence is still justified.

When federation is the better transition state

Federation is usually preferable when the organisations need to keep separate operating models, regulatory boundaries, or acquisition timelines intact. It allows each estate to keep its own identity source while creating a controlled trust relationship for selected applications, users, or partner workflows.

That makes federation useful when a rapid merger would disrupt critical services, or when the acquired company must retain autonomy for a period. The trade-off is that federation transfers trust across systems, so the security posture depends on token handling, session controls, assurance level, and the strength of the upstream identity provider.

A federated design should be treated as an interim operating model unless the organisations are intentionally maintaining separate governance. If the business wants one policy outcome but two policy engines, the result is usually inconsistent approvals, duplicated recertification, and slower incident response when accounts need to be revoked quickly.

For the underlying trust layer, teams should review the federation and single sign-on controls in the Identity Provider and SSO Security Guide, especially where M&A increases the attack surface around assertions, session tokens, and recovery paths.

What usually fails in M&A identity integration

The most common failure is assuming that directory integration equals governance integration. Two estates can authenticate through the same trust path and still enforce different lifecycle rules, different admin boundaries, and different exception processes. That creates hidden privilege drift rather than real convergence.

Another common failure is underestimating non-human access. Service accounts, API tokens, automation credentials, and other non-human identities often survive long after human access has been rationalised, which means the combined environment can inherit dormant access paths that are harder to inventory than employee accounts. The lifecycle problem is often more stubborn than the login problem, so teams should inspect machine and service access with the same rigor as workforce access, using an identity lifecycle view such as the NHI Lifecycle Management Guide.

There is also a trust concentration issue. If one side of the merger becomes the new identity control plane before policy and recovery are aligned, a compromise or outage in that control plane can affect both organisations at once. That is why many post-merger programmes start with identity discovery, entitlement cleanup, and staged federation rather than immediate consolidation.

For the mechanics of authentication and token-based trust in merged estates, OpenID Connect Core 1.0 is the relevant specification to anchor design choices around ID tokens, relying parties, and sign-in flows.

Practitioner Guidance

What to prioritise: Decide policy first, platform second. If the merged organisation cannot describe one access approval model, one offboarding rule, and one exception path, do not treat directory unification as a control improvement.

Decision rule: Use federation when separation is still operationally necessary, but only if the trust layer, recovery process, and assurance requirements are explicit. Move toward unification when shared governance is required and both estates can enforce the same lifecycle and privilege rules without manual exceptions.

What to verify: Confirm whether privileged users, recovery admins, and non-human accounts are subject to the same review and revocation standards in both estates. The hardest post-merger gaps are usually in recovery, delegated admin, and service credentials.

Common mistake: Treating “connected” as “controlled.” A merged sign-in experience can hide a fragmented entitlement model for months, especially where application owners still approve access locally.

Practitioner takeaway: In M&A, the real question is not whether to federate or unify, but whether one enforceable lifecycle policy can govern the combined trust boundary without creating shadow privilege.

Related resources from NHI Mgmt Group

• How should organisations design digital identity systems that minimise unnecessary data sharing during authentication?
• What breaks when organisations take identity systems offline too late during a cyberattack?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?