The gaps show up in device control, legacy application access, and protocol support. Azure AD does not natively manage endpoints, provide open directory interoperability, or fully replace the GPO and local resource capabilities many environments still depend on. Teams then need extra services for LDAP, RADIUS, and hybrid sync, which increases fragility and makes identity administration harder to govern.
Why Azure AD Cannot Fully Replace On-Prem Active Directory
Azure AD, now Microsoft Entra ID, is an identity control plane for cloud and SaaS access, not a drop-in clone of on-prem active directory. The break point is usually not sign-in alone, but the services that still depend on directory-integrated authentication, device policy, LDAP, Kerberos, or classic Windows resource management. Once those dependencies are exposed, organisations need coexistence patterns rather than a clean replacement.
That distinction matters because the weakest migrations are often built on the assumption that “users can authenticate” means “the directory is functionally replaced.” In practice, endpoint policy, legacy apps, and network services often keep the old directory in the path, even after most user login flows have moved to the cloud.
Where The Functional Gaps Actually Appear
The most visible break is device and endpoint control. On-prem Active Directory and its adjacent tooling still anchor Group Policy, computer object administration, and many local resource rules. Azure AD can join and register devices, but it does not natively deliver the same operating model for Windows device management, so endpoint policy normally shifts to a companion platform rather than disappearing.
Legacy application access is the second fault line. Many older workloads expect LDAP, Kerberos, NTLM, or direct directory lookups, and some line-of-business systems still assume on-prem directory services for authorization and application binding. That is why hybrid identity patterns remain common: the app is not “migrated” until its protocol and directory dependencies are remediated, or an intermediary service is introduced.
Protocol support is the third constraint. Azure AD is designed around modern cloud authentication and federation patterns, while classic directory protocols and some network access services remain outside its native scope. When organisations still need LDAP, RADIUS, or similar integration points, they typically add supporting services, which creates extra interfaces to secure and operate.
Why Hybrid Identity Becomes The Operational End State
In a real migration, Azure AD often becomes the primary cloud identity provider while on-prem Active Directory continues to serve specific workloads, devices, or authentication paths. That coexistence can work well, but only when teams are explicit about which directory owns which function. If ownership is vague, identity administration becomes harder to govern because provisioning, policy enforcement, and troubleshooting are split across multiple systems.
The main architectural trade-off is simplicity versus compatibility. Replacing every on-prem function at once would reduce complexity, but most enterprises cannot do that without breaking legacy access, device policy, or local resource workflows. A staged model preserves business continuity, but it also means duplicate controls, synchronisation dependencies, and more places for drift to accumulate.
For a broader view of directory and non-human identity dependencies, Ultimate Guide to NHIs is useful background on lifecycle, visibility, and access governance, and the NHI Lifecycle Management Guide maps the lifecycle controls that become harder, not easier, when identity responsibility is split across platforms.
Risk and Threat Considerations
The risk is not just feature loss, it is control fragmentation. When organisations bolt on extra services for directory interoperability, remote access, or hybrid sync, they add more identities, more credentials, and more configuration surfaces that can fail or be abused. Misplaced trust in synchronisation and compatibility layers can also hide stale accounts, excessive permissions, or broken access paths until an outage or compromise exposes them.
Failure mechanism: A partial replacement leaves critical workloads dependent on legacy directory functions while cloud identity handles others, so failures in sync, protocol bridges, or policy translation create inconsistent authentication and access decisions.
Impact: Organisations can lose governance clarity, increase administrative overhead, and expand the blast radius of a directory or credential failure, especially where legacy access methods remain embedded in production operations.
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-9 — Identification and Authentication (Service and Non-Organizational Users) | Covers service and external auth paths that often remain in hybrid directory setups |
| AC-2 — Account Management | Directory replacement affects provisioning, revocation, and account ownership across systems | |
| IA-5 — Authenticator Management | Hybrid directory designs still rely on credentials and tokens that must be rotated and controlled | |
| Recommendation — Apply IA-9 to govern non-organizational authentication across legacy and cloud identity paths. Use AC-2 to keep account lifecycle authority clear during hybrid identity coexistence. Apply IA-5 to manage credential storage, rotation, and recovery across both directories. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about access control gaps created by replacing one directory with another |
| Recommendation — Map each access path to PR.AA-05 and verify it still works under hybrid dependency. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure Authentication | Legacy and cloud directory coexistence depends on authenticated access across multiple protocols |
| Recommendation — Use A.8.5 to secure each authentication path that remains after migration. | ||
Practitioner Guidance
What to prioritise: Inventory every dependency on Group Policy, LDAP, Kerberos, RADIUS, local resource authorization, and device management before declaring Azure AD the “replacement.” The practical question is not whether users can sign in, but which workloads still require on-prem directory semantics to function correctly.
What to verify: Confirm which system is the source of truth for device policy, account lifecycle, and application binding. If two directories can both affect the same access path, document which one wins during conflict and test that behaviour under failure conditions.
Practitioner takeaway: Azure AD can modernise identity, but it does not erase the operational need for directory interoperability, so the safest migration strategy is to retire old dependencies deliberately rather than assume they disappear.
Related resources from NHI Mgmt Group
- What breaks when organisations try to use local logon restrictions and group policies as the main way to protect Active Directory tier boundaries?
- What breaks when organisations try to consolidate Active Directory without first cleaning up security issues?
- What breaks when organisations try to secure Microsoft 365 access without a clear bridge between on-premises Active Directory and cloud identity services?
- Why do Active Directory service accounts complicate zero trust programs?
