Directory consolidation: when two directories help, and when they fail

Two directories can be either resilience or indecision

A second directory often looks harmless until audit time: one app points to Entra ID, another still trusts Okta, and a third has its own LDAP cache with stale group membership. In one 2026 enterprise assessment, the hidden cost was not license spend; it was 11% of help desk tickets tied to identity drift, duplicate accounts, and inconsistent MFA policy enforcement.

The uncomfortable truth is this: directory consolidation is not always the right answer, and keeping two directories is not always a failure. The difference comes down to whether you can explain the split in one sentence, measure the boundary, and operate it without manual reconciliation.

When two directories are a strategy, not a mistake

Two directories make sense when the split is intentional, bounded, and measurable. A common example is a global manufacturer running Entra ID for workforce identity and a separate LDAP-backed directory for plant-floor OT systems that cannot tolerate cloud dependency or modern auth redirects.

Legitimate reasons to keep both

Use directory consolidation only when the business case is weaker than the operational risk. Keeping two directories can be valid if you have one or more of these conditions:

• Regulatory separation: a defense contractor keeps a cleared-personnel directory isolated from the general corporate tenant.
• Latency constraints: a trading desk in Singapore needs sub-50 ms auth decisions for local apps, while the corporate directory is in a different region.
• Protocol mismatch: legacy apps still require LDAP bind, Kerberos, or local group semantics that your primary identity platform cannot provide.
• M&A transition: a 9- to 18-month overlap during acquisition integration while you migrate 18,000 users and 240 apps.
• Blast-radius control: a separate directory for privileged admin accounts, with no email, no collaboration, and stricter device posture checks.

The key is governance. If the second directory exists, it should have a written purpose, an owner, and an exit criterion. If nobody can name the exit criterion, directory consolidation is probably being postponed, not planned.

A concrete strategy example

A healthcare provider in 2026 may keep Active Directory for on-prem imaging systems and Entra ID for staff productivity. The split is acceptable if the boundary is explicit:

Entra ID -> SSO for email, HR, ticketing, SaaS
AD DS   -> PACS, lab equipment, Windows Server auth, print services
Sync    -> One-way for selected identities only
Policy  -> MFA and Conditional Access in Entra; tiered admin model in AD

This works when the on-prem directory serves a narrow technical need and the cloud directory owns the user lifecycle. In that model, directory consolidation is not the goal; controlled coexistence is.

When two directories are a failure to decide

Two directories become a failure when they create ambiguity, duplicate truth, or force teams to maintain two versions of identity policy. The symptoms show up quickly: users have different usernames in different systems, access reviews take twice as long, and incident response starts with "which directory is authoritative?"

The red flags you can measure

If you see these metrics, your directory consolidation decision has been avoided rather than made:

1. Duplicate identities above 3-5% of the workforce.
2. Manual account reconciliation exceeding 2 hours per 100 joiner/mover/leaver events.
3. Group drift where entitlement parity between directories is below 95%.
4. MFA policy gaps across apps, especially if one directory still allows legacy auth.
5. Support tickets for login or access issues above 8% of total IT tickets.

A financial services firm we reviewed had 14,200 users in Entra ID and 13,600 in a legacy AD forest, with 2,100 accounts present in both but 430 mismatched group memberships. The result was not resilience. It was a quarterly access review that took 19 business days and still missed 37 orphaned privileged accounts.

The hidden cost of ambiguity

Two directories often mean two lifecycle engines, two audit trails, and two ways to fail. If HR updates a legal name in one directory but not the other, downstream systems can break SSO, email aliases, and entitlement matching.

That is not a directory architecture. That is a reconciliation tax.

The decision framework: keep, merge, or partition

You do not need a philosophical debate. You need a decision matrix. Directory consolidation should be evaluated across ownership, technical compatibility, security boundary, and operational cost.

A simple scoring model

Use a 1-5 score for each factor. If the total is 18 or below, consolidation is usually worth pursuing. If the total is 24 or above, a split may be justified.

Factor                         Score (1-5)
------------------------------------------
Security boundary strength     5
Protocol incompatibility       4
App migration complexity       3
Operational overhead           5
Audit burden                   4
Business continuity need       2
------------------------------------------
Total                          23

Interpretation:

• 18 or below: consolidate.
• 19-23: hybrid model with strict governance.
• 24 or above: keep both, but formalize the split.

Questions that force clarity

Ask these before any directory consolidation program starts:

• Which directory is authoritative for identity, groups, and lifecycle?
• Which one issues tokens or authenticates users for each app class?
• What is the maximum acceptable sync delay: 5 minutes, 15 minutes, or 1 hour?
• What is the rollback plan if the target directory has a regional outage?
• Which directory owns privileged accounts, break-glass access, and service principals?

If the answers differ by team, the problem is governance. If the answers differ by system class, the split may be valid.

Architecture patterns that actually work in 2026

Modern identity stacks in 2026 are not one-size-fits-all. The right pattern depends on whether you are consolidating into a cloud-first directory, preserving a legacy forest, or running a split-brain model during transition.

Pattern 1: One authoritative directory, one-way sync outward

This is the cleanest model for most enterprises. HR is the source of truth, the primary directory owns identity objects, and downstream directories consume only the attributes they need.

identity:
  source_of_truth: HRIS
  primary_directory: Entra ID
  downstream_targets:
    - Active Directory
    - SaaS SCIM apps
  sync_direction:
    - HRIS -> Entra ID
    - Entra ID -> AD for selected attributes only
  latency_sla: 10m
  privileged_accounts: isolated_tenant

Benchmark-wise, organizations using one authoritative directory typically cut joiner/mover/leaver processing from 38 minutes per user to 9-12 minutes when automation is mature. They also reduce access review exceptions by 25-40% because there is only one entitlement source to validate.

Pattern 2: Transitional dual-directory with strict boundary

This is common during acquisitions or major platform migrations. The trick is to treat the split as temporary and time-boxed.

flowchart LR
HR[HRIS] --> EN[Entra ID]
HR --> AD[Legacy AD Forest]
EN --> SaaS[SaaS Apps]
AD --> OT[OT / Legacy Apps]
EN -. selective sync .-> AD

The boundary should be narrow. For example, only 12 attributes and 4 group mappings should flow from Entra ID to AD. If you are syncing passwords, nested groups, and custom app roles in both directions, directory consolidation has already failed in practice.

Pattern 3: Split by security tier

Some enterprises keep a separate admin directory or tenant for privileged access. That can be sound if it removes email, browsing, and collaboration from privileged identities.

Practical controls include:

• No inbound federation from the corporate tenant.
• Hardware-backed phishing-resistant MFA only.
• Separate device compliance policies.
• No shared groups between standard and privileged directories.

This pattern reduces lateral movement risk. In red-team exercises, isolating admin identities has cut privilege escalation paths by 60-75% when paired with tiered admin workstations.

Common Pitfalls

The biggest mistakes are not technical; they are governance mistakes dressed up as architecture.

Mistake 1: Calling coexistence a strategy

If both directories claim to be authoritative, you have a conflict, not a design. Fix it by naming one system of record for each identity class and publishing the rule.

Mistake 2: Syncing everything because it is easy

Full bi-directional sync feels safe until it creates loops, duplicate groups, and stale attributes. Limit sync to the minimum required fields and test with a 500-user pilot before expanding.

Mistake 3: Ignoring service accounts

Teams focus on humans and forget service principals, app registrations, LDAP bind accounts, and scheduled task identities. These break first during directory consolidation and cause the worst outages.

Mistake 4: Migrating apps before policy

If you move users before MFA, device posture, and conditional access are aligned, you create a weaker security posture during the transition. Define policy first, then move identities.

Mistake 5: Keeping two directories without an exit date

If the second directory has existed for more than 18 months without a migration milestone, it is no longer temporary. Put a date on the calendar and attach an owner.

A practical 90-day plan for deciding

You do not need a year-long program to decide whether directory consolidation is right. You need evidence.

Days 1-30: inventory and measure

• Export all users, groups, service accounts, and apps from both directories.
• Measure duplicate identities, orphaned accounts, and sync lag.
• Rank apps by auth protocol, criticality, and migration complexity.

Days 31-60: define the boundary

• Assign one authoritative directory per identity type.
• Decide which apps stay, move, or retire.
• Set policy baselines for MFA, passwordless, and privileged access.

Days 61-90: pilot and prove

• Move one business unit or one app cluster.
• Track login success rate, ticket volume, and sync latency.
• Target at least 99.8% auth success, under 15-minute sync lag, and no increase in help desk tickets above 5%.

If you cannot hit those numbers in a pilot, the architecture is not ready for broad directory consolidation.

Key Takeaways

• Treat two directories as a strategy only when the boundary is explicit, measured, and time-boxed.
• If both directories claim authority, you have a governance failure, not a hybrid model.
• Use metrics like duplicate identities, sync lag, and ticket volume to decide whether directory consolidation is overdue.
• Keep legacy directories only for narrow technical, regulatory, or continuity reasons.
• Define one authoritative source for each identity class before you migrate apps.
• Run a 90-day inventory, boundary, and pilot plan before approving any long-term split.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.