A common mistake is treating cloud identity as a complete replacement when it often functions as an extension for selected applications and users. That can leave gaps in network authentication, device management, legacy system support, and broader authorization control. Teams should map every resource class first, then confirm which identity functions are actually covered end to end.
Where cloud identity services stop being a directory replacement
The core mistake is assuming cloud identity is the same thing as a full directory service. In practice, cloud identity often covers sign-in and app-centric access well, but it does not automatically replace the broader directory functions that many environments still depend on for device, network, and legacy access control. The failure usually appears when teams equate “users can log in” with “all identity-dependent systems are covered.”
That distinction matters because a directory is often part identity source, part policy anchor, and part integration layer. If you only migrate the authentication surface that is visible to SaaS apps, you can leave behind the controls that govern internal applications, non-web authentication, workstation trust, and older systems that still expect directory protocols or domain-style membership.
Cloud identity also tends to shift the control model toward federation, conditional access, and application-specific policies. That is useful, but it changes how authorization is expressed and where trust is enforced. Teams that do not map those changes end up with partial coverage: modern apps may authenticate correctly while device posture, network access, and inherited authorization rules remain fragmented.
What gets missed in hybrid identity design
Teams most often undercount three things: protocol compatibility, authorization scope, and lifecycle ownership. A cloud identity service may authenticate users to cloud apps, but it may not natively satisfy every on-prem application, LDAP dependency, device join workflow, or service-to-service trust path. If those edges are not documented, the old directory becomes an unplanned dependency instead of a deliberate design choice.
The other common blind spot is that directories are not only about login. They frequently anchor group logic, role resolution, legacy entitlements, and device registration workflows. When teams replace the directory narrative with a cloud-first narrative, they sometimes miss that authorization data still needs a stable source of truth and that certain systems expect directory semantics rather than simple cloud claims.
Cloud identity can also be the right front door while still being an incomplete back-end replacement. For many organisations, the practical model is coexistence: cloud identity handles modern access paths, while the directory continues to support legacy, network, or administrative functions until those dependencies are retired or re-platformed. The question is less “which one wins” and more “which identity function is authoritative for each resource class?”
How to evaluate whether the directory is still required
The useful test is to inventory by resource class, not by product preference. Start with applications, devices, administrative tools, VPN or network access, human users, third parties, and non-web workloads, then ask which identity functions each class actually needs. That usually exposes where cloud identity is sufficient, where directory integration is still necessary, and where both systems need to coexist.
What to verify: confirm whether each critical workload depends on directory-bound authentication, group membership, device trust, or legacy protocol support. Then verify whether the cloud service covers that function directly or only through an integration that still relies on the traditional directory behind the scenes.
Decision rule: if a resource class cannot be managed end to end without the directory, treat the directory as a live control plane, not a temporary leftover. If the cloud identity service only covers a subset of users or applications, document the boundary explicitly so provisioning, revocation, and access reviews do not split across two incomplete views.
What good looks like: every identity-dependent system has a named authoritative source, every exception is intentional, and no team is surprised when a legacy system still requires directory-backed trust. That is the difference between modernising identity and accidentally breaking it.
Risk and Threat Considerations
Partial replacement creates silent exposure. The most common failure mode is not a hard outage, but a control gap where some users, devices, or applications remain outside the intended policy model. That leaves room for inconsistent access enforcement, stale accounts, or legacy trust paths that are easier to overlook during reviews and incident response.
Failure mechanism: teams migrate the visible sign-in experience but leave directory-dependent authentication, authorization, or device trust in place without clear ownership. The result is fragmented identity governance, duplicated entitlement logic, and weaker visibility into who can still reach what through the old path.
Impact: attackers and insiders benefit from the confusion. If revocation, group membership, or legacy authentication is not aligned across both systems, access can persist longer than intended, and security teams may miss the real enforcement point during a compromise or account change.
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-2 — Identification and Authentication (Organizational Users) | Cloud identity replacement decisions hinge on who authenticates and where. |
| IA-9 — Identification and Authentication (Service and Application Accounts) | Directories often remain needed for workloads, services, and legacy non-human access. | |
| AC-2 — Account Management | Partial migration creates lifecycle gaps across directory and cloud account stores. | |
| Recommendation — Map each user population to an authoritative authenticator and prevent split sign-in paths. Preserve distinct authentication controls for service and application accounts. Track account lifecycle ownership across both identity systems and eliminate unmanaged duplicates. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | The question is about how identity and access control are implemented across environments. |
| ID.AM-01 — Physical Devices and Systems Inventory | Evaluating directory replacement requires inventorying which assets still depend on it. | |
| GV.RM-01 — Risk Management Strategy | Hybrid identity boundaries create operational and security risk if not governed explicitly. | |
| Recommendation — Define one authoritative identity and access model for each resource class. Inventory the systems that still rely on directory-backed trust or legacy authentication. Document which identity functions remain directory-dependent and accept residual risk deliberately. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | This topic is fundamentally about choosing the right access control source and boundary. |
| A.5.16 — Identity management | The question concerns whether identity functions can be fully moved from one service to another. | |
| A.8.2 — Privileged access rights | Directory replacement gaps often show up first in admin and legacy privileged access paths. | |
| Recommendation — Assign access-control authority to the system that can enforce it end to end. Maintain a clear identity source of truth for each population and application class. Verify privileged access remains controlled where directory services still enforce it. | ||
Practitioner Guidance
Where to start: build a simple matrix of resource class, identity source, authentication method, authorization source, and lifecycle owner. That matrix is more useful than a product comparison because it shows where the directory remains essential and where the cloud identity service truly replaces a function.
Common mistake: treating SaaS sign-in success as proof that the whole estate is covered. If a system still depends on LDAP, device membership, group nesting, or legacy policy evaluation, the directory is still part of the control path even if end users never notice it.
Practitioner takeaway: modern identity programmes usually succeed by narrowing the directory’s role deliberately, not by assuming cloud identity eliminates it. The right goal is complete coverage by function, with each access path assigned to one authoritative control model.
Related resources from NHI Mgmt Group
- What do teams get wrong when they lift and shift identity systems to the cloud?
- What do teams get wrong when they assume eKYC alone can cover the full identity assurance problem?
- What do security teams get wrong when they assume identity visibility can wait until after a lengthy rollout?
- What do teams get wrong about emergency access and cloud group membership when they try to simplify identity operations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
