TL;DR: Hybrid and multi-cloud environments expose a persistent gap between authenticating identities and authorising what they can do, especially when legacy apps cannot support modern methods and multiple identity providers multiply risk, according to Strata Identity. The practical issue is not confusion over terms, but programme design that treats identity proof and access enforcement as interchangeable controls.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Strata Identity's blog post: Authentication and authorization are distinct controls, and hybrid, multi-cloud IAM breaks down when legacy apps and multiple identity providers blur the boundary between proving identity and granting access.
Why it matters: IAM teams need to preserve the separation between identity proofing and access enforcement because multi-cloud sprawl and legacy application constraints can turn that distinction into an exposure point across human and non-human access paths.
Context
Authentication answers who or what is attempting to enter a system, while authorization decides what that entity can do once admitted. In hybrid and multi-cloud environments, those two functions often end up implemented in different layers, with different identity providers, policies, and application constraints.
The governance gap appears when organisations try to stretch legacy applications across modern identity patterns without rethinking where policy is enforced. That creates inconsistent access boundaries, especially where access decisions depend on multiple clouds, multiple authentication paths, or orchestration layers that are supposed to bridge the gap.
Key questions
Q: How should security teams separate authentication from authorization in hybrid cloud IAM?
A: Security teams should treat authentication as identity proof and authorization as a separate policy decision. The practical move is to map where each control is enforced, then test whether a verified identity can still reach sensitive data through inherited permissions, exceptions, or stale policies. That separation is essential in multi-cloud environments where control boundaries are easy to blur.
Q: Why do legacy applications create a governance gap for IAM teams?
A: Legacy applications often keep authorization logic, local accounts, and audit trails inside the application itself, which means central IAM cannot consistently enforce policy or prove access removal. The gap appears when the identity programme can change roles in the IdP but cannot reach the real access path. That is why governance looks complete on paper but fails in practice.
Q: What breaks when multiple identity providers handle the same cloud estate?
A: Policy coherence breaks first. Users may authenticate successfully in one place, but access decisions can differ across clouds, applications, or orchestration layers. The result is fragmented authorization, harder audits, and a greater chance that access granted in one domain does not align with the intended enterprise policy in another.
Q: When should teams use identity orchestration instead of direct federation?
A: Use orchestration when you need to bridge legacy and modern systems without recoding, but only if the architecture still makes proof of identity and permission enforcement visible. If orchestration hides the actual trust boundary or creates inconsistent access semantics, it should be redesigned rather than expanded.
Technical breakdown
Authentication proves identity, authorization grants rights
Authentication establishes that an entity is genuine. Authorization determines whether that entity can perform a specific action on a specific resource. The distinction matters because a strong login flow does not create entitlement, and a good entitlement model cannot compensate for weak proof of identity. In modern IAM, these controls are often separated intentionally: one layer handles proof, another layer applies policy. In hybrid environments, confusion between the two usually surfaces when teams assume a valid session should also mean broad application access.
Practical implication: keep authentication and authorization separate in architecture, policy, and reporting so one control does not silently substitute for the other.
Why legacy applications break modern identity assumptions
Legacy applications frequently cannot support modern authentication methods cleanly, which is why organisations end up preserving old login patterns longer than they should. That does not just create technical debt. It creates a control mismatch, because modern identity governance expects stronger assurance, better federation, and more consistent policy enforcement than those applications were designed to accept. When an old app cannot speak modern protocols, teams often compensate with orchestration or translation layers, but those layers can hide where the real trust decision is being made.
Practical implication: identify applications that still depend on outdated login patterns and map where their trust decisions are actually enforced.
Multiple identity providers increase policy fragmentation
In multi-cloud environments, each cloud often brings its own identity provider, its own policy logic, and its own session behaviour. The result is not just more login screens. It is more places where authentication can succeed without producing a consistent authorization outcome. That fragmentation makes policy drift more likely, especially when access is granted across integrated services or translated through orchestration platforms. The issue is less about whether users can sign in and more about whether access rules remain coherent after sign-in across every cloud boundary.
Practical implication: standardise how access policy is evaluated across clouds so successful authentication does not create inconsistent downstream permissions.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication and authorization drift becomes a governance problem, not a terminology problem. The article is right to separate the concepts, but the operational failure is deeper than vocabulary confusion. In hybrid and multi-cloud IAM, teams often inherit architectures where proof of identity and permission checks are split across different systems, then assume those systems will remain aligned. The practical consequence is that access design becomes inconsistent at the exact point where policy coherence matters most.
Legacy application compatibility is where modern identity assumptions begin to fail. Older applications that cannot natively support modern authentication methods force organisations into translation layers, brokered sessions, or compensating controls. That is not inherently wrong, but it means the access model no longer reflects the app’s original trust boundaries. For IAM, the issue is whether governance can still explain who is trusted, by which mechanism, and under which policy.
Multi-cloud identity silos widen authorization ambiguity across the enterprise. When each cloud brings its own identity provider and policy engine, identity proof becomes easier to achieve than consistent access enforcement. That creates a fragmentary control plane in which one provider may authenticate successfully while another layer decides authorization differently. Practitioners should treat cross-cloud policy coherence as a core IAM design requirement, not an integration detail.
Identity orchestration only helps when it preserves control intent, not when it obscures it. Orchestration can bridge heterogeneous systems, but it also risks becoming a black box that hides where trust is validated and where permissions are granted. The named concept here is authentication-authorisation boundary drift: the point at which proof of identity and access enforcement stop lining up across apps, clouds, and policy layers. Teams need a governance model that keeps that boundary visible, auditable, and consistent.
What this signals
Authentication-authorisation boundary drift: hybrid estates make it harder to see where identity proof ends and entitlement begins. That is a governance visibility issue as much as a technical one, because every hidden boundary becomes a place where policy can diverge from intent.
Multi-cloud teams should watch for cases where a successful sign-in does not map cleanly to a single authorization source of truth. The programme signal is simple: if you cannot explain which layer makes the final access decision, your IAM model is already fragmenting.
For practitioners
- Map the authentication-authorisation boundary Document where identity is proved, where access is granted, and which system owns each decision across every major application and cloud.
- Inventory legacy apps that cannot handle modern methods Identify applications that still depend on older login flows, then record the compensating controls used to bridge them into the current IAM model.
- Rationalise multi-cloud identity providers Reduce unnecessary divergence in policy logic, session handling, and entitlement enforcement across cloud platforms so authorization is evaluated consistently.
- Separate access proof from access entitlement reviews Review authentication strength and authorization scope as distinct governance checks, especially where orchestration layers or federated sessions connect systems.
Key takeaways
- Hybrid and multi-cloud IAM fails fastest when authentication and authorization are treated as interchangeable controls rather than separate governance decisions.
- Legacy applications and multiple identity providers both increase the chance that access policy will drift away from the intended trust model.
- The practical fix is not just stronger login methods. It is clearer ownership of where identity is proved, where permissions are granted, and how those layers stay aligned.
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 Zero Trust (SP 800-207), NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The article centres on identity proof across apps, clouds, and orchestration layers. |
| Recommendation — Apply IA-9 to ensure non-human and federated identities are authenticated consistently across service boundaries. | ||
| NIST Zero Trust (SP 800-207) | Access Control — Access Control | The topic maps to continuously verifying identity and enforcing least-access decisions across environments. |
| Recommendation — Design access control so authentication success never automatically implies authorization. | ||
| NIST SP 800-63 | SP 800-63C — Federation | The article discusses federated identity flows and how multiple providers affect access decisions. |
| Recommendation — Use federation controls to keep identity proofing and relying-party authorization aligned across systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authorization drift is the core governance issue across hybrid and multi-cloud estates. |
| Recommendation — Review entitlements separately from authentication strength so permission scope stays governed. | ||
Key terms
- Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
- Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
- Identity Orchestration: Identity orchestration is the control layer that routes identity decisions across applications and environments instead of letting each system manage access independently. For agents, it is the mechanism that can centralise policy, auditing, and downscoping at runtime.
- Hybrid Cloud IAM: Hybrid Cloud IAM is the management of identities and access across a mix of on-premises systems, private cloud, and public cloud services. It coordinates authentication, authorization, lifecycle control, and policy enforcement across environments with different control planes, ensuring users, workloads, and service accounts receive consistent access decisions and auditability.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org