Join our Newsletter — 33% off our NHI Course
Home FAQ Governance, Ownership & Risk What breaks when identity governance stops at the…
Governance, Ownership & Risk

What breaks when identity governance stops at the primary directory?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 14, 2026 Domain: Governance, Ownership & Risk

Governance becomes partial because authentication is visible while effective permissions remain hidden inside non-native applications. That leaves teams unable to certify, recertify, or remove toxic access with confidence. The practical result is an identity programme that can prove who signed in, but not what authority they actually exercised.

Where the Directory View Stops Being Enough

Primary directories tell you who authenticated, but identity governance has to answer a wider question, which systems the identity can reach, with what effective privilege, and under what business justification. When governance stops at the directory, entitlement sprawl in SaaS, ERP, and custom applications becomes invisible, so certification findings look clean while real access remains untouched. That gap is especially dangerous for shared roles, inherited group membership, and delegated admin paths that never surface in the directory record. In practice, many teams only discover the gap during an audit, a joiner-mover-leaver exception, or a post-incident access review.

The problem is not that the directory is wrong, it is that it is only one control plane. If the rest of the application estate holds its own roles, grants, and tokens, then governance based on the directory alone can document identity, but not authority. That is why lifecycle controls, access reviews, and revocation need coverage across the systems where privilege is actually consumed, not just where login is verified.

Operationally, this means your governance model must trace entitlements end to end, from the human or workload identity source through downstream application permissions and any standing delegated access. Without that chain, recertification becomes a paper exercise, because reviewers are certifying an incomplete picture of access.

How the Failure Shows Up in Practice

The failure usually appears in three places: orphaned entitlements in non-native systems, inaccurate attestations, and delayed deprovisioning. A directory-centric program can confirm that an account exists or that MFA was used, yet still miss that the same person has direct app-level admin rights, API access, or a dormant role in a business system. For practitioners, the key issue is that effective access often lives in the target application, not in the source directory.

  • Application roles may be provisioned once and then drift away from the directory record.
  • Group membership can imply access in one system and be meaningless in another, creating false confidence.
  • Exception handling often bypasses standard governance, leaving no reliable review trail.
  • Deprovisioning may remove directory access but leave local entitlements, service links, or delegated grants intact.

This is where review evidence matters. Teams need a provable mapping from identity to the actual access path, and they need it refreshed often enough to catch role changes, temporary access, and stale privileges. Resources such as the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs are useful when the access model includes non-native or automated entitlements that do not appear cleanly in the directory.

Where this guidance breaks down is in highly federated environments with many legacy applications, because entitlement data is often fragmented, incomplete, or not exposed in a format that supports reliable review.

Common Variations and Edge Cases

Tighter governance usually increases integration overhead, because every additional application or entitlement source adds mapping, review, and reconciliation work. That tradeoff is worth it when access decisions have material business impact, but it creates real friction in environments with legacy apps, shadow IT, and externally managed SaaS.

One common edge case is federated login combined with local authorization. The directory may govern authentication, while the application independently governs roles. Another is temporary access, where a ticket, approval, or workflow grants privilege outside the directory and then outlives the reason it was approved. In both cases, the directory looks authoritative while the practical authority sits elsewhere.

Another variation is machine or delegated access used by scripts, integrations, or automations. If governance only sees the primary directory account, it can miss access chains that continue through tokens, service grants, or app-specific secrets. For this reason, teams should treat the directory as a source of truth for identity, not a finished control for entitlement governance. The broader pattern is consistent with the control objectives in the NIST Cybersecurity Framework 2.0, especially where access management depends on continuous visibility and lifecycle control.

Practitioner takeaway: the directory is the starting point for governance, not the boundary of it, and any programme that cannot prove effective access across downstream systems will eventually certify the wrong thing.

Risk and Threat Considerations

The material risk is access persistence, because privilege can survive even after the directory record has been cleaned up. That creates exposure for over-privilege, toxic combinations, and delayed revocation, especially where administrators, integrations, or business users can hold rights directly in the target system.

Failure mechanism: attackers and insiders benefit from the same blind spot. If governance only reviews the primary directory, a compromised account, stale app role, or unmanaged delegated grant can remain active long enough to support data access, privilege escalation, or lateral movement without obvious directory evidence.

Impact: organisations can lose confidence in access reviews, fail audits, and leave sensitive systems governed by partial truth rather than actual entitlement state. The practical consequence is that revocation and recertification appear successful on paper while real authority remains in place.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC — Identity Management, Authentication and Access ControlAccess governance and lifecycle control are central to directory-beyond-directory entitlement coverage.
Recommendation — Map every effective entitlement source and enforce access review across downstream systems.
CIS Controls v85 — Account ManagementAccount lifecycle control must extend beyond the primary directory to prevent hidden access.
6 — Access Control ManagementThe issue is incomplete control over effective permissions, not just sign-in records.
Recommendation — Inventory and reconcile all account and entitlement stores, then remove stale access paths. Review and revoke application-level privileges, not only directory memberships.
NIST SP 800-63IAL — Identity ProofingIdentity assurance is weakened when downstream authority is unmanaged after authentication.
Recommendation — Separate identity proofing from entitlement governance and validate downstream authority explicitly.
NIST Zero Trust (SP 800-207)SC.AC — Access Control Policy and EnforcementZero Trust requires policy enforcement at the resource, not just the primary directory.
Recommendation — Enforce access decisions at each application boundary rather than trusting directory state alone.

Practitioner Guidance

What to prioritise: certify the applications and entitlement stores that hold the highest-value access first, not the easiest-to-report directory fields. If an application can grant effective authority independently, it needs to be in scope for governance even when directory records are clean.

What to verify: confirm that every review can answer two separate questions, who authenticated and what privilege was actually exercised. If those answers come from different systems, the governance process must reconcile them before a recertification is considered complete.

Practitioner takeaway: good identity governance measures effective access, not just identity presence, and the programme is only trustworthy when revocation, review, and evidence all extend beyond the directory.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 14, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org