They usually stall at the boundary between legacy application constraints and modern authentication goals. Teams can add OIDC or SAML, but without orchestration, coexistence planning, and inventory quality, they cannot remove older dependencies safely. The programme then advances in pockets instead of across the estate.
Where multi-cloud identity programmes usually get stuck
The stall is rarely at the point of choosing an authentication protocol. It usually happens when teams discover that modern identity standards must coexist with older application assumptions, inconsistent inventory, and platform-specific exceptions. The programme then becomes a series of local fixes rather than a controlled estate-wide transition.
That boundary matters because the hard work is not just “adding OIDC” or “turning on SAML.” It is deciding how legacy apps will be retired, remediated, wrapped, or left on compensating controls while the organisation keeps moving toward a common identity pattern.
Why legacy constraints slow modern authentication plans
Many multi-cloud estates contain applications that were built around static credentials, embedded trust, or one-off federation logic. Those systems can often accept a new login path, but they cannot safely lose the old dependency until someone has mapped every caller, token flow, and service-to-service assumption. That is why cloud workload identity guidance matters here: workload identity is often the cleanest exit from static keys, but only when the application estate can actually absorb the change.
Legacy constraints also create coexistence pressure. Identity teams may need to run old and new mechanisms in parallel for a long time, and that parallel state is where delivery slows. If application owners are not ready to change dependencies, the identity programme cannot simply “enforce modern auth” without causing outages or broken integrations.
The practical implication is that the stall is architectural, not just operational. Teams need to understand whether the blocker is protocol support, dependency discovery, application ownership, or the absence of a safe migration path for secrets, sessions, and federation trust.
Why inventory and coexistence planning decide whether the programme scales
Multi-cloud identity work tends to fragment when inventory quality is poor. If teams do not know which applications still rely on legacy auth, which cloud accounts are tied to which business services, or where cross-cloud trust is duplicated, then the migration plan cannot be sequenced with confidence. The result is selective progress in a few well-understood areas while the rest of the estate stays untouched.
Orchestration is what turns that discovery problem into a programme. It coordinates cutovers, fallback handling, exception approval, and ownership between cloud, app, security, and platform teams. Without it, coexistence becomes a permanent state rather than a controlled bridge to the target model.
Identity programme design is useful here because the issue is not only technical migration, it is governance across a mixed estate. A programme that cannot assign ownership, track roadmap status, and manage exceptions will usually stall even if the preferred authentication technology is well chosen.
What separates a stalled effort from a manageable transition
The difference is whether the team treats legacy coexistence as a transition discipline or as a permanent accommodation. A manageable transition has a clear inventory, a defined sequence for retiring dependencies, and a plan for applications that cannot yet move. A stalled effort has a target architecture on paper but no reliable mechanism for reducing old dependencies in practice.
That is why the most useful next step is to group applications by migration path rather than by cloud provider. Some will move cleanly to modern federation, some will need wrappers or gateway patterns, and some will remain temporary exceptions until they are rewritten or retired. The identity programme advances only when those categories are explicit.
Lifecycle management also becomes relevant once old dependencies remain in place, because long-lived exceptions, stale access paths, and incomplete offboarding are the usual reasons “temporary” coexistence turns into enduring risk.
Risk and Threat Considerations
When modern authentication is layered onto legacy applications without removing the old path, the exposed surface often grows instead of shrinking. Stale credentials, duplicated trust relationships, and incomplete inventory make it easier for an attacker or an internal misuse case to find a weaker path into the same environment.
Failure mechanism: legacy systems keep accepting long-lived secrets, older federation patterns, or bypass routes while new identity controls are added beside them, so the estate never reaches a single enforceable access model.
Impact: teams inherit inconsistent control strength across clouds, migration stalls become permanent exceptions, and compromise in one weak dependency can undermine the wider identity programme.
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, NIST CSF 2.0 and CIS Controls v8 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 | Covers lifecycle control of credentials during auth migration. |
| IA-9 — Service Identification and Authentication | Applies to service-to-service and workload auth common in multi-cloud estates. | |
| Recommendation — Govern secrets and authenticators so legacy paths can be retired safely. Use service authentication controls to replace static trust dependencies. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Inventory quality is central to knowing which apps still block identity migration. |
| Recommendation — Maintain a complete application and dependency inventory before cutover. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Asset inventory supports identifying legacy applications and hidden dependencies. |
| Recommendation — Keep application and dependency inventories current to support migration decisions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Coexistence often stalls where account and access lifecycle is unclear across clouds. |
| Recommendation — Standardise account lifecycle handling across legacy and modern identity paths. | ||
Practitioner Guidance
What to prioritise: build an application-by-application migration map before expanding the rollout. The first question is not which cloud or protocol to standardise on, but which dependencies must be retired, wrapped, or isolated before the new pattern can be safely enforced.
What to verify: every app in scope should have an owner, a known authentication path, and a documented coexistence plan. If any of those are missing, treat the app as a programme blocker rather than a low-priority edge case.
Common mistake: treating pilot success as estate-wide readiness. A handful of modern apps can authenticate cleanly while the overall programme still fails because inventory quality, orchestration, and exception handling were never solved.
Practitioner takeaway: multi-cloud identity programmes stall when migration mechanics are confused with architecture readiness, so progress depends on retiring legacy dependencies in a controlled sequence rather than layering modern auth on top of them.
Related resources from NHI Mgmt Group
- Why do multi-cloud identity programmes need orchestration instead of one central IDP?
- Why does multi-tenant SaaS often reduce governance friction in identity programmes?
- Why do identity silos create risk in multi-cloud IAM programmes?
- Why do identity and access programmes often stall when teams treat them as isolated tooling projects?