When organisations keep relying on a legacy directory while the rest of the stack moves to cloud services, identity control becomes harder to maintain. Administrators end up stitching together more point solutions, which increases complexity and weakens consistency across users, devices, and applications. Over time, that approach can slow onboarding, complicate policy enforcement, and limit security visibility.
Why a Cloud-First Stack Exposes the Limits of Open Directory
Open Directory was built for a world where directory services sat close to on-premises systems and administrators controlled most access paths directly. As more business services move into SaaS, cloud infrastructure, and federated access, the directory becomes only one part of a wider identity picture. The result is not instant failure, but a growing gap between where identities are governed and where access decisions actually happen.
That gap matters because cloud services tend to introduce their own authentication, authorization, and provisioning layers. When the directory remains the centre of gravity, teams often keep forcing new services back into an old operating model rather than redesigning identity around the current stack. The directory still has value, but it stops being sufficient as the system that makes access coherent across the environment.
In practice, that means the organisation starts relying on connectors, synchronisation jobs, and manual exceptions to keep users aligned across platforms. The more those integrations multiply, the more identity data can drift out of sync. This is why modern identity architecture usually pairs a directory with federation, lifecycle automation, and tighter policy enforcement at the cloud boundary, as reflected in NIST Cybersecurity Framework 2.0 and OpenID Connect Core 1.0.
Where Identity Complexity Starts to Accumulate
The first pressure point is consistency. A legacy directory can still authenticate many users, but it may not be the authoritative place for every cloud app, external partner, device, or privileged workflow. Once the stack spans multiple environments, access policy becomes fragmented: one control path for the directory, another for the cloud provider, and another for SaaS applications. That fragmentation is a governance problem as much as a technical one.
The second pressure point is lifecycle speed. Cloud-based services usually expect faster onboarding, faster offboarding, and more granular role changes than a traditional directory-centric model was designed to support. If lifecycle changes depend on batch syncs or manual updates, organisations can leave stale access in place longer than intended. For a modern control view, compare this with identity and access expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and cloud identity controls in CSA MAESTRO agentic AI threat modeling framework.
The third pressure point is visibility. A directory alone rarely tells you enough about cloud-native access paths, token use, delegated permissions, or service-to-service trust. As the stack expands, teams often lose a single, reliable view of who can access what and through which mechanism. That does not just slow administration, it makes access review, incident investigation, and policy enforcement harder to trust.
What the Operating Model Usually Looks Like as It Degrades
When organisations keep the legacy directory at the core of a cloud-heavy environment, they usually compensate with more tooling, not less. They add identity connectors, sync engines, conditional access policies, and ad hoc administration steps to bridge the mismatch. The environment can still function, but it becomes more brittle because each added control depends on the last one behaving correctly.
This is where inconsistency tends to show up across users, devices, and applications. A user may appear correctly provisioned in one system but carry stale or incomplete entitlements in another. A device policy may be enforced in the cloud but not reflected in the directory. An application may accept a federated identity while still maintaining local permissions that no longer match the source of truth. The problem is not just operational overhead, it is that every exception weakens the reliability of the identity model.
For that reason, cloud migration programmes usually need a deliberate identity redesign rather than a directory preservation strategy. The question is no longer whether the directory exists, but whether it remains the right authoritative layer for each access decision. If the answer is no, the organisation needs to reassign authority more explicitly, rather than hoping integrations will cover the gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Cloud migration changes where identity is governed across the business. |
| PR.AA-05 — Identity Management, Authentication and Access Enforcement | The question is about access control becoming harder to maintain across systems. | |
| Recommendation — Define the identity authority model for cloud and legacy services. Enforce consistent access decisions across directory and cloud services. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Directory drift affects account lifecycle, provisioning, and revocation across the stack. |
| IA-2 — Identification and Authentication (Organizational Users) | Cloud-first identity still depends on reliable user authentication and federation. | |
| Recommendation — Centralise account lifecycle control and remove stale access paths. Use strong authentication flows that remain consistent across platforms. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The subject is fundamentally about identity governance across changing environments. |
| A.5.17 — Authentication information | Cloud integration increases reliance on credentials, tokens, and sync-mediated access. | |
| Recommendation — Assign clear identity ownership across on-premises and cloud systems. Control credential issuance, storage, and rotation across integrated services. | ||
Practitioner Guidance
What to verify: Confirm which system is authoritative for joiner, mover, and leaver events, and check whether cloud apps still depend on local directory replication or manual reconciliation. If access changes can be made in more than one place, treat that as a control weakness until ownership is explicit.
Common mistake: Treating directory synchronisation as equivalent to identity governance. Synchronisation moves attributes; it does not by itself guarantee that cloud authorisation, delegated access, and application-local permissions stay aligned.
What good looks like: The directory continues to support identity where it is appropriate, but cloud services receive identity and policy through clearly defined authoritative paths, with fewer manual exceptions and a shorter delay between HR or administrative change and actual access change.
Practitioner takeaway: The key decision is not whether to keep Open Directory, but whether it still owns the right identity relationships in a cloud-first environment. If it no longer does, the architecture should shift authority, not keep layering compensating controls onto a model that no longer matches the stack.
Related resources from NHI Mgmt Group
- What happens when organisations keep relying on perimeter-based security after moving remote?
- What happens if organisations keep relying on manual identity management for Linux devices instead of integrating them with directory controls?
- What happens when organisations keep relying on manual remediation for Active Directory access cleanup?
- What happens when organisations keep relying on a traditional SEG after moving more email and collaboration into the cloud?
