What breaks is the organisation’s ability to see authorization risk. Directory data tells you who exists, but not what that identity can actually do across applications, data, or delegated paths. When teams rely on directories alone, they understate over-permissioning, miss access chaining, and lose the context needed to govern AI use safely.
When Directory Data Stops Being Enough
Directory systems are good at telling you that an account exists, who created it, and where it lives. They are not designed to answer the harder governance question: what that account can do once it leaves the directory and starts moving through apps, APIs, shared services, delegated permissions, and automation paths.
That gap matters because authorization risk is usually expressed in relationships, not just records. A directory can show a user or service principal, but it rarely shows effective permissions, inherited access, consent grants, cross-system trust, or the way one entitlement becomes a stepping stone to another.
Once identity is treated as directory plumbing, the security conversation narrows to provisioning and deprovisioning hygiene. The broader problem, however, is access meaning, who can act, where that authority is exercised, and how quickly excess privilege accumulates when ownership, delegation, and application-level entitlements are not modelled together.
What Gets Hidden: Authorization, Chaining, and Delegation
One of the first things lost is visibility into authorization governance. If teams only inspect directory objects, they may miss the difference between nominal membership and effective access, especially where roles, app permissions, inherited groups, token scopes, or delegated approval paths expand what an identity can actually do.
This is where access chaining becomes dangerous. A low-friction permission in one system can unlock a second system, which then exposes data, admin functions, or downstream credentials. The directory may remain unchanged while the real blast radius grows across platforms and control planes.
It also obscures governance for automation and AI-assisted workflows. When an agent, script, or service account can invoke tools on behalf of a person or process, the real question is not just who the identity is, but what it is authorised to trigger, inherit, or relay at runtime.
For that reason, effective review has to move beyond directory objects into access paths, entitlement graphs, and the operational context of delegated action. Non-human identities are especially prone to this blind spot because their authority often sits outside the places teams traditionally look first.
Why Governance Must Follow Effective Access, Not Just Existence
Security teams should treat directory data as a starting point, not the control surface. The right question is whether the organisation can explain effective access at the application, data, and delegated-action layer, then prove that access is still appropriate after role changes, app changes, and environment changes.
That is why lifecycle reviews, entitlement recertification, and privilege reduction need to be tied to actual usage and actual reachable systems. If a team cannot answer what the identity can reach, what it can modify, and which trust relationships it can leverage, it is governing labels rather than authority.
Directory-centric models also tend to miss ownership drift. A lingering account can appear harmless in the directory while retaining hidden rights in SaaS applications, cloud consoles, shared integrations, or long-lived automation. The result is stale authority that survives organisational change.
For readers trying to evaluate maturity, this is where identity programme design matters. Lifecycle management becomes the practical discipline that connects creation, rotation, review, and retirement to actual access outcomes rather than to directory status alone.
Risk and Threat Considerations
Directory-only thinking creates a control gap that attackers and internal misuse can both exploit. If effective permissions, delegated trust, and app-level entitlements are not visible, excessive access can persist unnoticed and provide a quiet route to sensitive data or privileged actions.
Failure mechanism: Identity records remain accurate while the underlying authorisation state drifts across applications, tokens, group inheritance, and delegation paths. That allows over-permissioning, privilege reuse, and access chaining to accumulate without a clear review signal.
Impact: Organisations lose the ability to spot who can really do what, which weakens access reviews, slows containment, and increases the chance that a compromised or misused identity can move laterally or reach protected systems.
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 | AC-2 — Account Management | Directory-to-access drift is an account governance problem. |
| AC-6 — Least Privilege | The question centers on over-permissioning beyond directory records. | |
| IA-5 — Authenticator Management | Directory plumbing often hides credential and token lifecycle risk. | |
| Recommendation — Review account states and disable stale identities with unused or excessive access. Limit each identity to the minimum effective permissions it needs. Track and rotate credentials that enable access outside the directory. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The topic is about governing effective access, not just directory presence. |
| GV.RM-01 — Risk Management Strategy | The answer frames visibility into authorization risk as a governance gap. | |
| Recommendation — Manage identities and access using the effective permissions they can exercise. Define how authorization risk is identified, reviewed, and escalated. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directory-only treatment fails to govern actual access decisions. |
| Recommendation — Apply access control rules based on effective business need and privilege. | ||
Practitioner Guidance
What to prioritise: Start by mapping effective access for the identities that can touch sensitive data, administer systems, or invoke automation. The directory entry is useful, but the review should end with a clear answer on reachable apps, delegated paths, and the highest-impact permissions.
What to verify: Confirm that access review evidence includes application entitlements, privileged role assignments, consented grants, and service or workflow delegation. If the review only produces a list of directory accounts, the control is incomplete.
What good looks like: Teams can explain not just who the identity is, but what it can reach, what it can change, and which permissions would remain if a downstream application or delegation path were abused.
Practitioner takeaway: The moment identity is reduced to directory plumbing, governance shifts from controlling authority to cataloguing accounts. Mature programmes measure effective access and delegated reach, because that is where authorization risk actually lives.
Related resources from NHI Mgmt Group
- What breaks when identity management is still organised around a Windows-only directory model?
- What breaks when directory identity is treated as enough for AI agent authorisation?
- When does a machine identity become a compliance problem?
- Why is it important to integrate identity and data governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org