What breaks when identity reviews are based only on human-readable directories?

Reviews break when they ignore effective permissions created by cloud roles, policy inheritance, and machine-to-machine trust paths. The result is a certification exercise that approves stale records while real access remains excessive or orphaned. In practice, the organisation believes access has been reviewed when the risky entitlement still exists.

Why This Matters for Security Teams

Human-readable directories were built to help administrators see people, groups, and titles. They were never meant to be the system of record for every effective permission that now exists across cloud IAM, SaaS sharing, service accounts, and delegated trust. When identity reviews stop at the directory, the certification evidence can look clean while the real access path remains active. That gap is exactly why NHI Management Group highlights that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.

This matters because risk is usually expressed through the effective entitlement, not the label in the directory. A user may appear to have one role, while inherited policy grants, nested group membership, or machine-to-machine trust gives them much more. The same issue applies to NHIs, where API keys, workload identities, and tokens often sit outside the directory review process entirely. Current guidance from the NIST Cybersecurity Framework 2.0 emphasises governance and access control outcomes, not directory hygiene alone. In practice, many security teams encounter the discrepancy only after an incident review, rather than through a deliberate access certification design.

How It Works in Practice

Effective identity review has to start with the question, “What can this identity actually do right now?” not “What does the directory say this identity is?” That means pulling data from cloud IAM policies, resource-level grants, service account bindings, application entitlements, secrets managers, and workload trust relationships. For NHIs, this is especially important because the identity often exists as a token, certificate, or workload credential, not as a person-facing account.

A practical review flow usually includes:

• Reconciling directory records with cloud and SaaS entitlement graphs.
• Tracing inherited access from groups, roles, and policy attachments.
• Identifying non-interactive identities such as service accounts, pipelines, and bots.
• Checking whether credentials are still valid after the directory object has changed or been disabled.
• Verifying who can assume, mint, or delegate the identity through trust paths.

This is where NHI-specific governance becomes essential. The 52 NHI Breaches Analysis shows how often credential exposure and over-permissioned machine identities turn into real compromise paths. That pattern aligns with guidance in NIST CSF 2.0 and with the operational reality that access review must cover runtime entitlements, not just directory metadata. If a team only certifies records in HR or LDAP, it can miss lateral paths created by cloud role assumption, shared secrets, and stale tokens. These controls tend to break down in hybrid estates where the directory is authoritative for naming but not authoritative for authorization because permission inheritance lives elsewhere.

Common Variations and Edge Cases

Tighter review coverage often increases operational overhead, requiring organisations to balance audit completeness against the cost of joining data from many control planes. That tradeoff is real, especially in large cloud estates where service accounts are created automatically, permissions are inherited through templates, and access changes faster than quarterly reviews can keep up.

There is no universal standard for this yet, but current guidance suggests treating the directory as one input rather than the source of truth. Edge cases include cross-account role assumption, federated SaaS access, ephemeral compute identities, and CI/CD systems that inherit secrets at deploy time. In those environments, a directory review can be accurate and still incomplete because the effective privilege is created dynamically after the record is approved. This is why the operational answer is to review the entitlement graph, not the name field.

Teams also need to distinguish between human accountability and machine authority. A human owner may be listed correctly while the underlying NHI still has standing access, long-lived credentials, or broad trust relationships. The most reliable programs pair directory review with periodic workload inventory, secrets rotation, and trust-path analysis, using the Top 10 NHI Issues as a practical checklist for what directory-only processes routinely miss.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• What breaks when user-based reviews rely on incomplete identity data?
• What breaks when defensive AI gets broad access to identity code and deployment workflows?
• What breaks when help desk teams rely on phone numbers to confirm identity?