Topic starter
06/11/2026 6:36 pm
TL;DR: Unosecur shows that directory exports can reveal far more than names and roles, because group membership, reporting lines and tool associations effectively publish an authorization map even when no passwords or tokens are exposed. That turns directory read access into a high-value identity risk, not just a data leakage problem.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “A Directory Is an Authorization Map: What the DHS Icepick Leak Exposes”.
Key questions
Q: What should teams do first when directory group data is exposed?
A: First, contain the exposure by revoking or narrowing directory read access, rotating any exposed secrets tied to the directory integration, and identifying which group names, membership lists, and role mappings were readable.
Q: How should teams limit read access to identity directories?
A: Limit directory read access with least privilege, scoped roles, and separate administrative accounts, and only grant directory listing rights to identities that genuinely need them.
Q: When should directory group names be treated as sensitive information?
A: Directory group names should be treated as sensitive whenever they disclose business function, privileged access, security tooling, incident response, finance, payroll, or other high-value roles.
Practitioner guidance
- Inventory directory-read identities List every API token, service account and integration that can read users, groups or memberships in your identity provider, then assign a named owner to each one.
- Remove unnecessary directory read scope Strip directory enumeration rights from any integration that does not need full visibility into users and groups for its function.
- Reduce sensitive naming in groups Rename groups that expose operation names, case names or privileged tooling so that directory readers cannot infer sensitive functions from the label alone.
Bottom line: A readable directory can expose the organisation's authorization logic even when no credentials are stolen.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact identity-provider visibility patterns the vendor maps across Okta, Entra ID and Active Directory
- Graph-based access-path visualisations used to prioritise identities with excessive or dormant privileges
- The vendor's run-time visibility workflow for human, non-human and AI agent identities across connected environments
- The incident-response scoping context that follows leaked directory structure and access-path data
👉 Read Unosecur's analysis of the DHS Icepick leak and directory authorization risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Directory exposure is authorization exposure: when a directory reveals group membership, reporting lines and tool-linked roles, it exposes the logic that governs access, not just personal data. That makes the directory itself part of the control plane, because an observer can infer who is privileged, how work is segmented and where access is concentrated. Practitioners should treat readable group structure as a governance object, not a harmless directory attribute.
A question worth separating out:
Q: When should directory group names be treated as sensitive information?
A: Directory group names should be treated as sensitive whenever they disclose business function, privileged access, security tooling, incident response, finance, payroll, or other high-value roles. Names can reveal internal structure and target sets for attackers, so they should be protected like metadata that helps map access paths, not as harmless labels.
👉 Read our full editorial: Directory authorization maps expose the real breach surface