Modern cloud directories expose the limits of Active Directory

At a glance

What this is: This is an evaluation checklist for modern cloud directories, arguing that legacy Active Directory patterns no longer fit remote, hybrid, and mixed-OS environments.

Why it matters: It matters because IAM teams need to judge whether their directory architecture reduces operational sprawl or adds bridges, workarounds, and control gaps across human access and endpoint governance.

Context

Active Directory was built for a workplace where devices, applications, and users sat inside a defined perimeter. That assumption weakens when the environment spans remote workers, multiple operating systems, and cloud applications that expect modern federation rather than legacy directory dependence.

For IAM and security teams, the issue is no longer whether a directory exists, but whether it can govern identity, device, and protocol diversity without forcing compensating controls. When identity infrastructure cannot keep pace with the operating model, teams inherit complexity as risk.

Key questions

Q: How should IAM teams choose between LDAP and Active Directory?

A: Choose based on the environment and governance model, not on familiarity alone. LDAP is a protocol for talking to directory services, while Active Directory is a full directory and identity service built for Windows-centric estates. If you need broad interoperability, LDAP may fit as an integration layer. If you need centralised Windows identity control, AD may fit better. Either way, match the directory to the access problem, not the other way around.

Q: Why do identity bridges and VPN workarounds increase directory risk?

A: Because they insert translation layers between users and resources, and those layers must be configured, monitored, and patched separately. Every bridge expands the number of places where policy can drift, logs can fragment, and access decisions can become inconsistent across environments.

Q: What fails when a directory is built mainly for Windows environments?

A: Mixed-OS governance becomes uneven. macOS and Linux often end up managed through add-ons or manual exceptions, which creates partial coverage and makes shadow IT more likely. The failure is not only operational convenience, but incomplete enforcement across the actual device fleet.

Q: How do SSO, MFA, and device management change directory governance?

A: They collapse separate controls into one access model. When identity, access, and device state are linked, the directory can verify trust before granting access instead of treating authentication as a single isolated event. That reduces administrative friction and makes policy enforcement more consistent.

Technical breakdown

Cloud-native directory architecture versus lift-and-shift hosting

A cloud directory is not simply legacy directory software hosted in someone else’s infrastructure. A true SaaS directory removes domain controller management, pushes availability and redundancy into the service layer, and absorbs security updates centrally. By contrast, lift-and-shift directory hosting preserves the operational model that created the maintenance burden in the first place, while adding cloud cost and lifecycle complexity. The technical issue is architectural, not cosmetic: if the control plane still depends on old deployment assumptions, the organisation has modernised the hosting model but not the identity model.

Practical implication: treat cloud-native delivery as an architectural requirement, not a deployment label.

Mixed-OS identity and device management in one control plane

Active Directory was designed around Windows primacy, so macOS and Linux support often arrives through add-ons, agents, or manual workarounds. That creates a fragmented enforcement layer where some endpoints fall outside the directory’s real governance boundary. A platform that treats Windows, macOS, and Linux as first-class managed devices can enforce commands, policy, and patch visibility across the fleet from one console. The core problem is consistency: when device control is split across tools, identity policy becomes uneven and shadow IT becomes easier to hide.

Practical implication: verify that endpoint governance works uniformly across all operating systems before replacing legacy directory control.

Protocol independence for legacy and modern applications

Modern identity stacks must speak more than one protocol because the application estate is mixed. LDAP and Kerberos still matter for legacy resources, while SAML 2.0 and OIDC are central to cloud application federation. A directory that natively supports multiple protocols can connect users to different resource types without forcing an identity bridge as an intermediary translation layer. That matters because bridge layers add failure points, duplicate policy logic, and separate operational ownership. Protocol independence is therefore not just compatibility, it is a way to reduce translation risk in the access path.

Practical implication: map every protocol dependency before migration and eliminate unnecessary bridge layers where possible.

NHI Mgmt Group analysis

Directory replacement is now an identity architecture decision, not a feature comparison. Once work, devices, and applications spread across locations and operating models, the directory becomes part of the trust architecture, not just a user store. The practical consequence is that IAM teams have to evaluate whether the control plane can govern access consistently across environments instead of inheriting legacy friction in a modern wrapper.

Bridge complexity is its own security problem. VPNs, identity bridges, and protocol adapters often look like temporary compatibility measures, but they become enduring control dependencies. Each one adds policy translation, troubleshooting overhead, and a wider space for configuration drift. The implication is that organisations should measure how much of their directory strategy depends on compensating layers that no one actually governs end to end.

Mixed-OS support is no longer optional because device diversity changes the access model. A directory that still treats non-Windows endpoints as secondary forces security teams to accept partial coverage and inconsistent enforcement. That is a governance issue as much as a technical one, because control effectiveness now depends on whether the platform can see and manage the real fleet. Practitioners should treat endpoint parity as a prerequisite for modern directory selection.

Protocol independence is the new interoperability baseline. Legacy protocols still exist, but they now coexist with cloud-native federation expectations in the same enterprise. The directory that cannot bridge those worlds natively pushes complexity into external tooling and weakens accountability for access paths. For practitioners, the meaningful question is whether the directory can support the estate you have now while avoiding another layer of identity translation debt.

Modern directory governance needs to collapse identity, access, and device administration into one operating model. Separating those disciplines once made sense in office-bound environments, but it leaves gaps when access decisions depend on both who the user is and what device they are using. The field is moving toward unified policy enforcement because the old split between identity and endpoint management no longer reflects how access is actually granted.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Directory replacement decisions are really control-plane decisions. The main question is whether the new directory can absorb identity, device, and protocol diversity without multiplying compensating controls. Teams that only compare user experience or migration effort usually miss the larger governance trade-off: every bridge left in place becomes a lasting dependency.

Endpoint parity should be treated as a security requirement. If macOS, Linux, and Windows do not receive equal policy enforcement, the directory is already fragmenting the trust model. That creates different access outcomes for different device classes, which is exactly the kind of inconsistency Zero Trust programmes are meant to avoid.

Protocol independence is a practical measure of directory maturity. When LDAP, RADIUS, SAML 2.0, and OIDC all need to coexist, the directory has to normalise access across old and new application estates. The more translation work it pushes into external bridges, the more likely identity governance becomes distributed and harder to audit.

For practitioners

• Define replacement criteria around architecture, not branding Require true SaaS delivery, no domain controller dependency, and automatic availability and update handling before comparing vendors.
• Audit endpoint coverage across all operating systems Confirm that Windows, macOS, and Linux are managed through the same policy and command model, with no add-on path for core enforcement.
• Inventory protocol dependencies before migration List every LDAP, Kerberos, RADIUS, SAML 2.0, and OIDC dependency so you can retire identity bridges only where native support exists.
• Unify identity and device governance Evaluate whether the directory can enforce SSO, MFA, and device-linked access decisions from one control plane instead of separate systems.

Key takeaways

• Modern directory selection is fundamentally about whether identity control can scale beyond the assumptions that shaped Active Directory.
• Mixed operating systems and cloud applications expose the limits of legacy directory models and make bridge complexity a governance issue.
• Practitioners should prioritise cloud-native delivery, protocol breadth, and endpoint parity when evaluating replacement options.

Key terms

• Cloud-native directory: A cloud-native directory is built and operated as a SaaS control plane rather than as legacy directory software hosted in new infrastructure. The distinction matters because the service owns availability, updates, and scale, while the customer focuses on policy and governance rather than server maintenance.
• Identity Bridge: An identity bridge is an integration layer that connects a legacy directory to modern applications, devices, or cloud services. It can preserve access during transition, but it also adds translation complexity, can obscure control paths, and often becomes a long-lived governance dependency.
• Mixed-OS Management: Mixed-OS management is the ability to apply consistent policy, commands, and visibility across Windows, macOS, and Linux endpoints. It matters because modern identity governance cannot assume a single operating system, and uneven support creates unmanaged devices and inconsistent security outcomes.
• Protocol Independence: Protocol independence is the capacity to support multiple identity and access protocols natively, such as LDAP, SAML, OIDC, and RADIUS. It reduces reliance on brittle translation layers and helps organisations align legacy access needs with cloud-era application requirements.

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 building or maturing an IAM programme, it is worth exploring.