What breaks when governance only covers managed directories?

Where managed-directory governance stops short

Managed directories are often the system of record, but not the whole identity estate. Once access is also issued through SaaS admin consoles, service accounts, integrations, API tokens, and AI-mediated workflows, directory-only governance misses actors that still authenticate, authorize actions, and retain privilege. That gap matters because the control problem is not just who is in the directory, but who can actually act.

Directory-centric oversight is strongest when every meaningful account is joined, owned, and lifecycle-managed from one place. In mixed estates, however, the ownership model fragments: some identities are provisioned in apps, some are created by platforms, and some are inherited from automation or vendor dependencies. The result is that the directory can look clean while effective access remains wide.

For that reason, governance has to follow the operative access path rather than the administrative boundary. A useful way to think about the issue is to separate directory membership from authoritative control of the full identity surface, including non-directory accounts and machine-driven access. External guidance such as OWASP Non-Human Identities Top 10 and the cloud control domain for IAM in ISO/IEC 42001:2023 AI Management System Standard both reinforce that control boundaries must extend beyond human-directory administration.

Why offboarding, recertification, and audit evidence fail first

When governance only covers managed directories, the first failures usually appear in lifecycle tasks. Offboarding can remove the directory account while leaving service credentials, shared secrets, app-local admins, or third-party connections intact. Recertification can confirm the wrong population, because reviewers only see employees and contractors that exist in the directory. Audit evidence then becomes incomplete, since the report proves directory control but not actual access coverage.

This creates a subtle but important mismatch: the control may be operating as designed, yet the design itself no longer matches the environment. In practice, that means an organisation can pass a directory review and still retain active access paths in SaaS, infrastructure, or automated workflows. The governance failure is not always obvious until an exception, incident, or audit forces a full inventory.

That same gap appears in broader identity governance expectations. NIST Cybersecurity Framework 2.0 supports the need to identify assets and manage access across the real environment, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control logic for identification, authentication, access control, and auditability that must cover the full access surface.

What broadens the identity surface beyond the directory

The missing population is usually not exotic. It includes service accounts that authenticate silently, SaaS-native admins that never sync back, application integrations created outside central IAM, and AI-driven workflows that use delegated access or tool permissions. It can also include third-party or platform-owned identities that are operationally powerful but poorly visible to directory reports. Once these actors exist, the directory is only one source of truth, not the source of truth.

The practical question is whether an identity can still create impact after directory governance says it is done. If the answer is yes, then the identity needs lifecycle ownership, review, and evidence somewhere else as well. That is why access governance has to extend to secrets, tokens, role bindings, and application-local privilege, not just named user records.

Risk and Threat Considerations

When only managed directories are governed, orphaned access paths can persist after offboarding or change, and those paths are attractive because they are less visible and less frequently reviewed. Attackers and insiders alike benefit from controls that stop at the directory boundary but do not reach application-local accounts, service credentials, or delegated automation.

Failure mechanism: An identity is removed or recertified in the directory, while a parallel access path remains active in a SaaS app, integration, or service account, allowing continued authentication and privilege use outside central review.

Impact: Organisations can retain hidden privilege, fail to revoke access completely, and produce audit evidence that overstates control coverage, increasing the chance of unauthorized action going undetected.

Practitioner Guidance

What to verify: Reconcile directory membership against the set of accounts, tokens, integrations, and service principals that can still perform actions in production. If a system can authenticate or change state without passing through the directory, it belongs in scope for review.

What good looks like: Every access path has an owner, a lifecycle event for joiner-mover-leaver changes, and a review record that covers the actual control point where privilege is exercised. Directory reports should be evidence, not the evidence.

Practitioner takeaway: Governance is incomplete when it covers only the administration plane; the test is whether you can prove revocation, review, and accountability across every place access can actually exist.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?
• Why is it important to integrate identity and data governance?
• Why is NHI governance critical in the age of AI attacks?