They import separate trust decisions faster than identity teams can standardise them. Each acquired environment or cloud estate often arrives with its own directories, federation patterns, and application dependencies, so rationalisation becomes a coexistence problem before it becomes a migration problem.
Why M&A and multi-cloud programmes accelerate identity provider sprawl
M&A and multi-cloud programmes make identity provider sprawl worse because they multiply trust boundaries faster than governance can collapse them. Every newly acquired business unit or cloud estate may arrive with its own SSO, federation, privileged access patterns, and application dependencies, so the organisation inherits parallel identity decisions before it can design a single target state.
That creates a compound problem: identity teams are asked to keep the business operating while they sort out naming standards, tenant boundaries, federation trust, and application cutover sequencing. The result is not just more directories, but more exceptions, more bridge accounts, and more interim integrations that become hard to remove later.
What changes when each estate brings its own trust model?
The core change is that identity stops being a platform and becomes a negotiation layer. Acquired companies often depend on local directories, local admin delegation, and local recovery processes that cannot be switched off on day one without disrupting users and applications. Multi-cloud adds a second source of sprawl because each cloud may have different native identity constructs, token models, and entitlement patterns.
Identity provider sprawl usually grows through coexistence. During transition, teams keep the source IdP, stand up a central IdP, and then add federation between them to avoid downtime. That temporary arrangement often survives because application owners, operations teams, and security teams all rely on it for different reasons, and no one wants to be the first to break a working login path.
At scale, this means the organisation is not just managing more login systems. It is managing more policy sources, more recovery paths, more admin roles, and more places where authentication and authorisation logic can drift apart. For a useful overview of the control problem behind that drift, see the Identity Provider and SSO Security Guide.
Why rationalisation is harder than migration
Rationalisation requires agreement on control ownership, not just technical compatibility. In an M&A programme, the acquired business may still need to operate independently for legal, contractual, or operational reasons, so the target state cannot be a simple lift-and-shift into one directory. In multi-cloud, the same issue appears when applications must retain cloud-specific authentication dependencies or when teams resist centralisation because it seems to reduce autonomy.
This is why identity provider sprawl often persists after the initial integration project ends. The migration may finish, but the control plane remains fragmented because the remaining work is organisational: retiring duplicate admins, remediating app-specific trusts, re-issuing service credentials, and reworking recovery and break-glass paths. The longer these coexistence patterns remain, the more they become embedded as normal operating practice.
Good programmes treat IdP consolidation as a dependency mapping exercise first and a technology project second. They inventory where identities are authenticated, where sessions are issued, and which applications still trust legacy directories or federation endpoints. That lifecycle view is central to the NHI Lifecycle Management Guide, because sprawl is often sustained by unmanaged transition states.
Where the hidden risk comes from
The main risk is not simply that there are many IdPs. It is that each one becomes a separate trust decision with its own failure modes, review cycles, and attack surface. A fragmented identity estate makes it easier for stale federation trust, weak recovery paths, overprivileged admins, and unused accounts to survive long after the original integration rationale has disappeared.
That is also why post-merger identity issues are so often linked to session theft, token abuse, and lateral movement. If one environment is compromised, a loose federation chain or an unretired access path can turn a local incident into a cross-tenant or cross-cloud problem. Strong examples of how identity shortcuts become compromise paths are documented in the Okta support system breach 2023 and the Cloudflare Thanksgiving breach 2023.
Practitioners should also watch for application dependencies that silently force the sprawl to continue. If critical workloads still require a legacy IdP, a local LDAP path, or cloud-native identities that cannot yet be federated cleanly, the programme is no longer just doing identity consolidation. It is operating a distributed trust architecture that must be governed as such.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity provider sprawl often persists through unmanaged credentials and recovery paths. |
| AC-2 — Account Management | M&A and multi-cloud programmes expand account lifecycle and ownership complexity across estates. | |
| IA-9 — Service Identification and Authentication | Cross-cloud and application-to-application trust dependencies drive sprawl in non-human authentication paths. | |
| Recommendation — Inventory and retire duplicate authenticators, secrets, and recovery paths during IdP consolidation. Centralise account ownership and deprovision duplicate accounts after each integration milestone. Standardise service-to-service trust and eliminate ad hoc federation links. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions are Managed | Sprawl grows when multiple estates keep separate entitlement and trust decisions alive. |
| Recommendation — Review and normalise access permissions across all inherited identity domains. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | M&A identity consolidation requires consistent governance of identities across merged environments. |
| Recommendation — Define one identity governance model for inherited and target-state environments. | ||
Practitioner Guidance
What to prioritise: Build the application and trust dependency map before debating which IdP should “win”. The real sequencing question is which federation links, admin roles, recovery paths, and service credentials must remain in place during coexistence.
What to verify: Confirm which systems still authenticate directly to legacy directories, which ones rely on bridge accounts or cross-tenant trust, and which recovery processes can bypass the target IdP altogether. Those are usually the places where sprawl becomes sticky.
What changes at scale: With every additional cloud, subsidiary, or business unit, temporary exceptions become harder to retire because more applications depend on them. If the programme cannot name an owner for each trust relationship, it is already behind.
Practitioner takeaway: Identity provider sprawl is usually a governance and sequencing problem disguised as a technology integration problem, so success depends on controlling coexistence windows, not just selecting a better platform.
Related resources from NHI Mgmt Group
- How should security teams reduce identity sprawl across hybrid and multi-cloud environments?
- Why do multi-cloud identity programmes need orchestration instead of one central IDP?
- Why do identity silos create risk in multi-cloud IAM programmes?
- Why do service meshes make identity and access decisions more reliable in multi-cloud environments?