Teams often assume each application can manage identity cleanly on its own, but that approach creates silos, duplicate records, and weak visibility into who has access. It also makes reporting, lifecycle changes, and security reviews slower. The better pattern is to use a central directory and federated controls so access stays consistent across applications.
Why This Matters for Security Teams
Separate directories tend to look convenient until the organisation has to answer simple governance questions, such as who has access, who approved it, and whether that access still matches job function. Once each application keeps its own identity store, teams inherit duplicate records, inconsistent group naming, and conflicting privilege models. The result is not just administrative overhead, it is weak access accountability across the estate, especially when joiner, mover, and leaver changes must be reflected in many places at once.The core mistake is treating directory sprawl as an application design choice rather than an access governance problem. Good governance depends on one authoritative identity source, consistent entitlements, and reviewable rules for how access is granted and revoked. When those controls are fragmented, audit evidence becomes hard to assemble and security reviews become reactive instead of continuous. Current access decisions may still work, but the organisation cannot trust them at scale.
In practice, many teams discover the weakness only after a recertification, incident review, or merger exposes how many application-local accounts had drifted away from central policy.
How It Works in Practice
A central directory gives access governance a single place to anchor identity, attributes, and lifecycle state. Applications can still have local authorization logic, but they should rely on federated authentication and centralized provisioning rather than maintain their own long-lived identity records. That pattern reduces duplication and makes it possible to apply consistent controls across systems, even when the business has many applications with different owners or technologies.In practical terms, the governance model usually needs three layers:
- A source of truth for identity attributes, such as legal name, department, manager, status, and employment state.
- A federation or SSO layer that lets applications trust the central directory for authentication.
- A provisioning and deprovisioning process that creates, updates, and removes access in downstream systems based on authoritative lifecycle events.
That structure matters because access governance is not only about login. It is about entitlement quality, removal speed, reviewability, and evidence. When each app holds its own records, reports become inconsistent: one system may show an active account while another shows an orphaned one, and reviewers lose confidence in the result. By contrast, centralized governance makes it easier to answer whether access is role-based, whether privileged access is separately approved, and whether stale accounts are still in circulation. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance, identity management, and lifecycle control as core security functions rather than back-office administration. For teams that need a deeper control baseline, NIST Cybersecurity Framework 2.0 is a good reference point for aligning identity governance with broader security operations.
These controls tend to break down when legacy applications cannot federate or when teams allow local exceptions to become permanent accounts, because governance then splits between what the directory says and what the application actually enforces.
Common Variations and Edge Cases
Tighter centralization often increases integration effort, so organisations have to balance governance consistency against legacy compatibility and application autonomy. That tradeoff is real, especially in environments with older applications, third-party platforms, or systems that only support local accounts. In those cases, the right answer is usually not to abandon central governance, but to constrain the exceptions and make them visible.There are also cases where a separate directory exists for a legitimate reason, such as tenant isolation, regulatory segregation, or a partner-operated environment. Even then, the control objective does not change: teams still need authoritative ownership, lifecycle triggers, and reviewable entitlement boundaries. The difference is that the directory boundary becomes part of the access model and must be treated as a governed trust boundary, not a convenience layer.
For application teams, the most common failure is assuming that synchronization alone equals governance. Synchronization can move accounts around, but it does not guarantee that access is appropriate, promptly removed, or consistently reviewed. If the application still allows local creation of accounts, local admins can quietly rebuild the very sprawl the central directory was meant to eliminate. The practical question is not whether a separate directory can function technically, but whether it can still produce reliable access decisions, clean offboarding, and evidence that survives audit scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organisational Context | Access governance depends on a clear identity authority model and ownership. |
| PR.AA — Identity Management, Authentication and Access Control | Separate directories weaken consistent authentication and access enforcement. | |
| Recommendation — Define the identity source of truth and ownership boundaries for all application access. Centralise authentication and enforce consistent access rules across applications. | ||
| CIS Controls v8 | 5 — Account Management | Duplicate local directories create orphaned and inconsistent accounts. |
| 6 — Access Control Management | Federated controls reduce fragmented privilege decisions across apps. | |
| Recommendation — Inventory accounts centrally and remove stale local identities on a defined lifecycle. Standardise entitlement approvals and review access across all connected applications. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Lifecycle and Revocation | Application-local identities create lifecycle drift and delayed revocation. |
| NHI-03 — Visibility and Inventory | Separate directories obscure who has access and where it resides. | |
| Recommendation — Automate provisioning and revocation so access changes propagate from one authority. Maintain a complete inventory of identities and downstream accounts across applications. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Local directories and duplicate accounts can hide unauthorized access changes. |
| Recommendation — Monitor for unauthorized account creation, privilege changes, and stale access paths. | ||
Practitioner Guidance
What to prioritise: Treat lifecycle control and entitlement consistency as the first governance requirements. If an application-local directory cannot reliably remove access when identity state changes, it should be considered a governance gap even if logins still work.
What to verify: Verify that there is one authoritative identity source, that downstream accounts are provisioned from it, and that local exceptions are documented, time-bound, and reviewable. Also confirm that orphaned and duplicate accounts are detectable, not just theoretically preventable.
Decision rule: If the application can federate, prefer central authentication with local authorization only where the app truly needs it. If it cannot federate, require compensating controls for lifecycle, review, and deprovisioning before accepting the exception.
Practitioner takeaway: Separate directories become a governance problem when nobody can prove that identity changes propagate cleanly everywhere access exists. The control objective is not fewer directories for its own sake, but fewer places where access can drift beyond review and revocation.
Related resources from NHI Mgmt Group
- What do security teams get wrong when they rely on static PAM rules for healthcare access?
- What do teams get wrong about Terraform governance when they rely on shared access and weak branch controls?
- What do teams get wrong about cloud governance when they rely on manual audits alone?
- What do teams get wrong when they try to use Zanzibar-style authorization for every access control decision?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
