LDAP in 2026: A Strategic Assessment for Hybrid Enterprises

Independent Research Note | June 2026

---

Bottom Line

LDAP is not dying, but it has stopped evolving, and its perimeter is shrinking. The protocol remains actively maintained across all three major implementations, and no vendor has formally deprecated infrastructure-level LDAP support. Yet the IETF working group that produced the modern specification concluded years ago, and its standards are now frozen¹. The gaps enterprises have complained about for a decade, among them no native MFA and no standard change-notification mechanism, will never be fixed at the protocol level. LDAP’s role is narrowing from general-purpose identity protocol to infrastructure-layer plumbing for systems that cannot speak anything else. Enterprises that treat LDAP as a strategic platform, rather than a managed dependency, accumulate technical debt at an accelerating rate.

---

Key Findings

1. All three major implementations are maintained, but the work is custodial, not transformative. OpenLDAP shipped 2.6.13 as an LTS release in March 2026², yet its core team is four people and leans heavily on Symas for funding and engineering³. Red Hat dropped openldap-servers from RHEL 8⁴, and SUSE retired its OpenLDAP server to the Legacy module⁵. 389 Directory Server is the healthiest of the three: it completed its BerkeleyDB-to-LMDB migration in version 3.1.3⁶ and remains Red Hat’s strategic platform behind FreeIPA and Identity Management⁷.

2. Microsoft is hardening Active Directory’s LDAP, not retiring it. Windows Server 2025 requires LDAP signing by default on new deployments, sets channel binding to “when supported,” adds TLS 1.3 for LDAP over TLS, and deprecates RC4⁸⁹. Entra ID does not speak LDAP natively; cloud-only organizations that need it run Entra Domain Services, which Microsoft itself frames as a “transitional capability” for “AD minimization”¹⁰.

3. The market is bifurcating. SaaS vendors are walking away from LDAP: Docebo deprecated its LDAP integration in August 2025¹¹, and Barracuda stopped accepting new insecure LDAP connections in January 2025¹². Infrastructure vendors are not: Cisco, Palo Alto Networks, Fortinet, and VMware all keep LDAP as a first-class identity source¹³¹⁴.

4. Roughly 40% to 70% of a large enterprise’s application portfolio still carries an LDAP dependency. No analyst publishes this number; it is our estimate from vendor documentation and practitioner accounts. The hardest dependencies cluster in network access control, VPN authorization, the Linux identity stack, multifunction printers, and SAP and Oracle systems, where SAP alone has committed to maintenance through 2040¹⁵.

5. Authentication is largely a solved replacement problem; authorization and directory queries are not. OIDC, passkeys, and service-mesh mTLS now cover new application and workload authentication¹⁶¹⁷. They do not replace LDAP as a queryable user and group store, and no pull-based cloud equivalent to an LDAP search exists. Cross-environment authorization remains unstandardized; the OpenID AuthZEN effort is early¹⁸.

6. Every directory alternative trades away something. Entra ID needs a managed LDAP bridge¹⁰, JumpCloud offers genuine cloud LDAP but prices linearly per user¹⁹, Okta’s LDAP Interface supports only BIND, UNBIND, and SEARCH²⁰, and FreeIPA has no SaaS edition and no native OIDC or SAML⁷.

7. Migrations run far longer and cost far more than budgets assume. The CloudBees 2025 DevOps Migration Index reports an average cost overrun of about $315,000 per migration, with the typical project running roughly 18% over budget²¹. Coverage of Gartner’s 2025 IAM Summit describes application onboarding backlogs of 600-plus apps and timelines beyond eight years²².

---

Forward-Looking Assumptions

1. Through 2030, no major infrastructure or ERP vendor removes LDAP from its products. The pattern is additive: modern protocols ship alongside LDAP, not in place of it. SAP’s commitment runs to 2040¹⁵, and Oracle Internet Directory remains core to Oracle’s on-premises stack²³.

2. By 2028, OIDC and passkeys are the unquestioned default for new application authentication, yet the directory-query gap stays unsolved. Organizations will still run a directory behind their OIDC provider. Passkeys replace credential verification, not the store of record²⁴.

3. Infrastructure-level LDAP persists past 2030. Network gear, printers, and legacy Unix are the categories with no standards-based replacement and replacement cycles measured in years, not quarters.

4. Freeze-and-bridge becomes the dominant enterprise pattern, and the identity orchestration layer becomes a standard architectural component. Strata, Microsoft, and Okta already sell the connective tissue, and Gartner named identity orchestration in its June 2025 IAM technical-debt research²⁵.

5. The policy-engine market stays fragmented into 2027. OPA, Cedar, and OpenFGA each win different niches²⁶²⁷, and Apple’s hire of Styra’s OPA maintainers in August 2025 leaves OPA’s commercial trajectory unclear²⁸.

---

Analysis

1. The protocol is maintained, not advancing

All three major LDAP implementations are under active development, but the nature of the work shows the trajectory.

OpenLDAP continues steady LTS releases: 2.6.13 shipped on March 9, 2026, with a 2.7 feature release on the roadmap²²⁹. The project is genuinely maintained, not abandoned. But its core team is four people, and it depends heavily on Symas for funding and engineering³. Red Hat dropped the openldap-servers package starting in RHEL 8⁴, and SUSE placed its OpenLDAP server in the Legacy module and then removed it from SLES 15 SP4⁵. The 2.7 roadmap is evolutionary: a native RADIUS server and password policies scoped by LDAP URI²⁹.

389 Directory Server is the healthiest of the three. Red Hat maintains several release streams in parallel, completed the BerkeleyDB-to-LMDB backend migration in version 3.1.3, and keeps investing in the Cockpit web console, JSON audit logging, and connection handling at scale⁶³⁰. It is Red Hat’s strategic LDAP platform, the foundation under FreeIPA and Identity Management⁷.

Active Directory’s LDAP layer received its most significant security update in years with Windows Server 2025: LDAP signing required by default on new deployments, channel binding set to “when supported,” TLS 1.3 for LDAP over TLS, RC4 deprecation, and new performance counters for LDAP operations⁸⁹. Microsoft is hardening LDAP, not deprecating it, and has announced no plan to retire AD’s LDAP interface. Entra ID does not support LDAP natively. Cloud-only tenants that need it deploy Entra Domain Services as a managed bridge, which Microsoft positions explicitly as a “transitional capability” supporting “AD minimization”¹⁰. On-premises AD and its LDAP interface therefore remain load-bearing inside Microsoft’s own hybrid architecture.

The CVE record keeps the operational risk concrete. Two related Windows LDAP flaws patched in December 2024 make the point. CVE-2024-49112 (CVSS 9.8) is a critical unauthenticated remote code execution vulnerability in the Windows LDAP client. CVE-2024-49113 (CVSS 7.5), the denial-of-service companion that SafeBreach named “LDAPNightmare,” crashes the LSASS process and reboots the server. On January 1, 2025, SafeBreach published the first public proof-of-concept, which reliably crashes unpatched servers; the researchers noted that full remote code execution through CVE-2024-49112 was plausible but not demonstrated³¹. Windows Server 2019 through 2025 were vulnerable if unpatched³². 389 DS has its own history: multiple denial-of-service issues, and an access-control bypass (CVE-2022-1949) that could let an unauthenticated user craft a filter returning data they should not see, including password hashes³³.

At the standards level, LDAP is frozen. The IETF ldapbis working group concluded years ago¹, and the RFC 4510 series from June 2006 remains the definitive specification with no revision effort underway³⁴. A few peripheral SASL drafts exist, such as SCRAM extensions for two-factor authentication and a SASL mechanism for passkeys, but both are expired Internet-Drafts, and no coordinated effort to revise the core protocol exists³⁵. Innovation happens at the implementation level, in OpenLDAP overlays and AD extensions, not in the protocol.

2. Where LDAP cannot yet be replaced

The useful question is not whether LDAP is replaceable in theory, but what share of a real portfolio carries hardwired dependencies that modern protocols cannot serve today. No analyst publishes that figure. From vendor documentation, practitioner accounts, and infrastructure analysis, our estimate is that 40% to 70% of a typical large enterprise application portfolio retains some form of LDAP dependency: direct authentication, user lookup, or group-membership queries.

The hardest categories cluster predictably.

Network access control is the most entrenched. 802.1X environments rely on RADIUS servers (Cisco ISE, FreeRADIUS, Microsoft NPS) that query LDAP or AD for credential validation and group-based authorization. Certificate-based authentication (EAP-TLS) can remove LDAP from the authentication step, but authorization (VLAN assignment, access policy, group checks) still hits LDAP or AD. Cisco ISE, Aruba ClearPass, and Juniper all support LDAP as a primary identity source, with no standards-based replacement for the authorization function¹⁴.

VPN gateways have moved further. Cisco Secure Client (formerly AnyConnect), Palo Alto GlobalProtect, and Fortinet FortiGate all support SAML authentication³⁶. But LDAP stays wired in for authorization: SAML establishes who you are, while group-to-policy mapping, user-to-IP mapping, and similar functions still query AD or LDAP. Removing LDAP from VPN infrastructure means rearchitecting authorization, not just swapping the authentication protocol.

Linux infrastructure has the deepest coupling. SSSD abstracts LDAP from applications but itself connects over LDAP, or to AD via the LDAP protocol. PAM and NSS resolve users and groups against LDAP-backed directories. FreeIPA, Red Hat’s recommended path, runs 389 DS and the LDAP protocol internally⁷. You can abstract LDAP behind SSSD, but you cannot remove it from the Linux identity stack without moving to local-only authentication or a newer alternative such as Kanidm, which now ships a read-only LDAP gateway and has matured past its early releases, though its scope and adoption remain narrower than the incumbents³⁷.

Enterprise printers are the most overlooked dependency. HP, Xerox, and Ricoh multifunction devices use LDAP for user authentication, address-book lookups, and scan-to-email. They store bind credentials in firmware, often with excessive privileges, and generally support neither SAML nor OIDC. Penetration testers routinely run LDAP pass-back attacks against these devices to capture the stored credentials³⁸. The hardware cannot be upgraded to modern protocols and runs on five-to-ten-year replacement cycles.

SAP and Oracle embed LDAP at the connector, middleware, and authentication layers. SAP HANA supports LDAP authentication natively, SAP CUA synchronizes users between AD or LDAP and SAP, and SAP BusinessObjects uses LDAP as a primary authentication method; S/4HANA adds SAML 2.0 without removing LDAP³⁹. SAP’s maintenance commitment runs to 2040¹⁵. Oracle Internet Directory remains a core component of Oracle’s on-premises identity stack²³.

No major vendor (SAP, Oracle, Cisco, Palo Alto Networks, Fortinet, or Microsoft) has announced plans to remove LDAP. The pattern is additive: modern protocols are offered alongside LDAP, not as replacements for it¹³.

3. What actually displaces LDAP binds today

The replacement landscape splits cleanly by application category.

OIDC and OAuth 2.0 are the default for new application development. Every major identity provider (Entra ID, Okta, Google, Keycloak) treats OIDC as its preferred authentication protocol¹⁶, covering web apps, single-page apps, mobile, and API authorization. The limitation is fundamental: OIDC issues identity tokens and delegated authorization, but provides no general-purpose directory query. Organizations still need a directory behind the OIDC provider. OIDC replaces the LDAP bind for application login; it does not replace LDAP as a user and group store.

SAML 2.0 is steady but no longer growing for new deployments. Most organizations run SAML and OIDC side by side through one provider. SAML still leads in hub-and-spoke federations (academic, government, large business-to-business) and in regulated settings that value rich attribute assertions. The reality is coexistence, not replacement.

FIDO2 and passkeys show the fastest adoption. Per FIDO Alliance research, 87% of surveyed US and UK enterprises with 500 or more employees had deployed passkeys or were rolling them out for employee sign-in, in a survey conducted in late 2024²⁴. Microsoft made new Microsoft accounts passwordless by default in May 2025⁴⁰, and NIST SP 800-63B Revision 4, finalized in mid-2025, requires verifiers to offer at least one phishing-resistant option at AAL2⁴¹. But passkeys sit alongside LDAP rather than replacing it: they replace credential verification, while the directory storing user records and group memberships, typically AD or LDAP, remains.

Kerberos is still the on-premises Windows backbone, tightly bound to AD’s LDAP layer. Microsoft Entra Kerberos bridges cloud and ground by issuing Kerberos tickets from the cloud for FIDO2 and passwordless users reaching on-premises resources, so passkeys can be adopted without abandoning Kerberos⁴².

Service-mesh mTLS (Istio, Linkerd, Consul) replaces the old pattern of services sharing an LDAP service-account credential for backend authentication. Each service gets a short-lived X.509 certificate tied to its Kubernetes ServiceAccount, which removes shared secrets¹⁷. This is standard in containerized environments, but it does not extend to user authentication or directory queries.

The gaps are stark. Network device authentication, enterprise printers, legacy Unix PAM, and ad-hoc directory queries have no standardized LDAP replacement. OIDC and SAML do not speak to switches, printers, or NAS appliances, and no pull-based cloud directory-query protocol equivalent to an LDAP search exists.

4. The authorization gap is harder than the authentication gap

Replacing LDAP for authentication is largely solved. Replacing the “query LDAP for group membership, then make an access decision” pattern is not.

SCIM 2.0 has reached broad adoption for user and group provisioning across the major identity providers, but it is push-based with eventual consistency: sync cycles typically run 20 to 60 minutes⁴³. (A widely repeated claim that Gartner found 80% of large enterprises use SCIM does not trace to any Gartner publication, so we do not rely on it.) Microsoft has added inbound SCIM 2.0 provisioning APIs for Entra ID⁴⁴. SCIM still cannot answer an arbitrary (memberOf=cn=X) filter, handles nested groups inconsistently across vendors, and offers no equivalent to an ad-hoc directory search.

Open Policy Agent reached CNCF Graduated status in 2021⁴⁵ and runs in production at Netflix, Goldman Sachs, and Pinterest⁴⁶. It can replace LDAP group-based authorization by evaluating group claims carried in OIDC or SAML tokens. But in August 2025 Apple hired OPA’s core maintainers from Styra, and Styra’s commercial products are being wound down, which raises real questions about the project’s commercial roadmap²⁸. AWS Cedar, the language behind Amazon Verified Permissions, benchmarks 42 to 60 times faster than OPA’s Rego and adds formal verification, but has a smaller community and an AWS-centric design²⁶. OpenFGA, which originated at Auth0 and Okta and reached CNCF Incubating status in late 2025, is gaining ground for relationship-based access control²⁷. The policy-engine space is genuinely fragmented.

The industry is moving toward hybrid models that pair role-based assignments with attribute-based policy for context (device posture, location, risk). Role explosion, where an organization accumulates more roles than users, is the usual reason teams push past simple LDAP group-based RBAC.

The hardest unsolved problem is coherent authorization across hybrid environments. Cloud apps receive group claims in OIDC tokens; on-premises apps query LDAP or AD directly; sync lag between cloud providers and on-premises AD creates brief inconsistencies; group-nesting behavior differs between environments. The OpenID AuthZEN working group is standardizing an externalized authorization API, but adoption is early¹⁸. No universal standard for real-time cross-environment authorization queries exists today.

5. Directory alternatives all carry tradeoffs

No single product replaces LDAP and AD without giving something up.

For Microsoft-centric enterprises, Entra ID is the strategic direction, with more than 610 million monthly active users by Microsoft’s most recent public figure, reported in 2023⁴⁷, and customers including Toyota, NHS England, and the US Department of Veterans Affairs⁴⁸. But Entra ID does not serve LDAP natively. Organizations that need LDAP compatibility deploy Entra Domain Services, whose Standard tier runs about $109.50 per month, with one-way sync from Entra ID, no Domain Admin rights, and no way to pause it once enabled⁴⁹⁵⁰. At $6 per user per month for P1 and $9 for P2⁵¹, a 10,000-seat deployment runs $60,000 to $90,000 per year in Entra ID licensing before Domain Services.

For cross-platform environments, JumpCloud offers the strongest cloud LDAP story: a genuine hosted LDAP service rather than a proxy, with native device management across macOS, Windows, and Linux¹⁹. Its published per-product pricing runs from about $9 to $15 per user per month, with bundled platform packages quoted on request⁵²; linear per-user pricing is the main constraint at large scale. Okta dominates enterprise SSO, trusted by about two-thirds of the Fortune 100⁵³, but its LDAP Interface supports only BIND, UNBIND, and SEARCH²⁰, which makes it a compatibility shim, not a real LDAP server.

For Linux-heavy environments, FreeIPA and Red Hat IdM remain the best open-source option, with full 389 DS-backed LDAP, Kerberos, and centralized management at no cost beyond a RHEL subscription, and documented tuning to roughly 100,000 users⁵⁴. But FreeIPA has no SaaS edition and does not natively provide OIDC or SAML to applications (it fronts those with Keycloak), and it treats Windows and macOS as second-class⁷.

PingDirectory is the least-discussed but arguably most capable enterprise LDAP server, built for hundreds of millions of identities with full LDAPv3, bidirectional AD sync, and SCIM 2.0⁵⁵. Ping does not publish a list price; it sells through enterprise quotes, so the entry figures that circulate are third-party estimates rather than published rates.

AWS Managed Microsoft AD provides actual Microsoft AD in the cloud at roughly $88 per month for the Standard edition and $292 per month for Enterprise, per region⁵⁶, suitable for lift-and-shift. Google Secure LDAP exposes Cloud Identity and Workspace over LDAP, subject to daily query quotas that can constrain high-volume use⁵⁷. Neither is an identity platform; both are LDAP endpoints for legacy compatibility.

6. Cloud deployment forces hard architectural choices

All three major clouds support LDAP-dependent workloads, and their guidance converges on one message: LDAP in the cloud is a bridge, not a destination.

AWS recommends Managed Microsoft AD for most scenarios, with two or more domain controllers across availability zones. Its best-practice documentation warns that broad LDAP queries across tens of thousands of objects cause CPU hot-spotting on individual domain controllers⁵⁸, and that reaching an on-premises directory over Direct Connect adds latency and a network dependency, so a connectivity failure can cut authentication entirely⁵⁹.

Microsoft positions Entra Domain Services as enabling “AD minimization,” a bridge for legacy workloads during modernization rather than a long-term architecture¹⁰. Google’s guidance is similar: to let applications authenticate over LDAP, “you can expose or replicate an on-premises LDAP directory to Google Cloud or you can extend your Active Directory to Google Cloud”⁶⁰.

Blast radius is the defining operational concern. When a cloud-hosted directory goes down, every dependent system loses authentication at once. GitLab states it plainly: “If your configured LDAP provider and/or endpoint is offline or otherwise unreachable by GitLab, no LDAP user is able to authenticate and sign-in”⁶¹. Mitigation means multi-AZ deployment at minimum, multi-region replicas for critical workloads, and credential caching where the architecture allows.

The most resilient hybrid pattern places read-only replicas in each cloud region for authentication queries, with writes directed to a primary on-premises master. That cuts latency, removes the network dependency for reads, and contains blast radius to a region. Identity orchestration layers (Strata’s Maverics, named in Gartner’s June 2025 IAM technical-debt research²⁵, along with Microsoft Entra Connect and Okta’s AD agents) bridge the synchronization gap between cloud and on-premises stores.

7. Migration projects run longer and cost more than anyone budgets

The gap between vendor migration narratives and practitioner experience is wide. A focused IAM migration for a single system can finish in weeks. But coverage of Gartner’s 2025 IAM Summit describes application onboarding backlogs of 600-plus applications with projected timelines beyond eight years, and only about 10% of organizations provisioning new access within two days²².

The failure modes are predictable and consistently underestimated. Application discovery gaps top the list: shadow IT and line-of-business applications, which by one industry measure account for about 84% of applications sitting outside IT’s direct control⁶², are routinely missed in dependency audits. No purpose-built tool maps enterprise-wide LDAP dependencies; teams combine network monitoring (ports 389, 636, 3268), AD audit logging (Windows Event IDs 2887 and 2889 for insecure binds⁶³), and manual inventory. Windows Server 2025’s default LDAP-signing enforcement became an unplanned discovery mechanism by breaking applications that relied on insecure binds⁸.

Hardcoded bind credentials pervade legacy environments. Printer firmware, middleware, custom applications, and monitoring systems store service-account passwords that violate rotation policy, often with excessive privileges. Printer service accounts found with Domain Admin rights are a recurring penetration-testing finding³⁸. Migration means locating and rotating every embedded credential, which can take months.

Schema dependencies surface during testing, not planning. Custom schemas, non-standard attributes, and deep nested-group hierarchies accumulated over years resist clean migration, and Red Hat’s own documentation notes that IdM differs from a generic LDAP directory in schema support and tree structure⁷. Protocol mismatches compound it: applications using NTLM, LDAPv2, or anonymous binds collide with modern security requirements.

Cost data specific to LDAP migrations is not published by any major analyst. As a proxy, the CloudBees 2025 DevOps Migration Index reports an average cost overrun of about $315,000 per migration project, with the average project running about 18% over budget and 57% of enterprises spending more than $1 million²¹. By analogy with comparable identity programs, a full enterprise LDAP migration touching hundreds of applications, network infrastructure, and endpoints plausibly lands in the high six to low seven figures for a large organization, but no documented case study confirms a specific range. Large-scale public case studies of complete LDAP elimination effectively do not exist, and that absence is itself a finding.

---

Recommendations for Security and Risk Management Leaders

1. Freeze LDAP at the on-premises boundary, and mandate cloud-native identity for everything new. This is not a compromise; it is the only approach that matches real portfolios. Extending LDAP into the cloud works for lift-and-shift but widens blast radius without reducing debt. Full migration is correct in direction but, at eight-plus-year timelines, is a program, not a project.

2. Deploy an identity orchestration layer to bridge existing LDAP to cloud workloads. Strata Maverics, Microsoft Entra Connect, Okta’s AD agents, or an equivalent should mediate between on-premises LDAP and cloud-native protocols, with SCIM for provisioning and OIDC or SAML for modern application authentication²⁵.

3. Instrument directories before you migrate. Turn on audit logging, watch Event IDs 2887 and 2889 for insecure binds⁶³, and monitor ports 389, 636, and 3268 to map the real dependency surface. You cannot migrate what you have not discovered.

4. Find and rotate every hardcoded bind credential, starting with printers and middleware. Treat any service account with excessive directory privileges, especially one stored on a multifunction printer, as an active exposure³⁸.

5. Build a multi-year application migration backlog, prioritized by security risk and business value. Re-point applications to OIDC or SAML where you can. Accept that network gear, printers, and legacy Unix will not move on that schedule.

6. For cloud-hosted directories, design for blast radius from day one. Use read-only replicas per region for authentication reads, direct writes to a primary master, deploy across availability zones at minimum, and cache credentials where the architecture allows⁶¹⁵⁹.

7. Plan for permanent coexistence, not a finish line. Assume some LDAP infrastructure persists past 2030. Organizations that plan for coexistence make better architectural decisions than those chasing an elimination date that does not yet exist.

---

Market Outlook

Practitioner consensus has settled on a two-phase strategy: freeze LDAP at the on-premises boundary for existing investments, adopt cloud-native identity for all new workloads, and migrate high-value applications selectively over a multi-year horizon. Cloud-native and smaller organizations have gone cloud-only successfully. Large enterprises with network infrastructure, printers, ERP, and custom applications find complete migration multi-generational.

The real disagreement is about timeline and finality. Optimists, mostly cloud identity vendors and consultancies, expect LDAP to be marginalized within three to five years for most workloads. Practitioners managing physical infrastructure counter that LDAP’s moat is not applications, which can be re-pointed to OIDC, but infrastructure-level authentication: Linux SSH, network gear, NAS and SAN storage, and printers, where no standardized replacement exists. JumpCloud frames the practitioner view bluntly: the world is moving to the cloud, but a large part of the local environment gets left behind.

The analyst frameworks back the freeze-and-bridge posture. Gartner’s June 2025 IAM technical-debt research²⁵ and KuppingerCole’s Identity Fabric model⁶⁴ both treat LDAP as one protocol within a composable identity architecture rather than a standalone strategic platform. The recommended shape is consistent: an identity orchestration layer mediating between on-premises LDAP and cloud-native protocols, SCIM for provisioning, and OIDC or SAML for modern applications.

The honest assessment is that LDAP’s decline is real but slow, and its floor is higher than the cloud-only narrative admits. The protocol has stopped evolving, its standards are frozen, and its perimeter is shrinking. None of that makes it disappear from the switch closet, the printer, or the Linux fleet this decade. The organizations that come out ahead will be the ones that stop arguing about whether LDAP is dead and start managing it as the long-lived dependency it has become.

---

Key Sources

Every specific figure, date, version, and quotation above links to its primary source below.