Notifications
Clear all
Topic starter
07/06/2026 9:18 pm
TL;DR: IAM programmes often expose only the visible layer of apps, accounts, and policies, while orphaned accounts, unmanaged applications, and fast-growing machine identities remain outside governance, according to Orchid Security. The blind spot is structural: if identity cannot be onboarded, reviewed, and continuously monitored, access risk stays hidden until audit failure or breach evidence appears.
NHIMG editorial — based on content published by Orchid Security: Identity dark matter and hidden identity risk in IAM
Questions worth separating out
Q: How do security teams find identities that were never onboarded into IAM?
A: Start with discovery across cloud, SaaS, source control, and automation layers, then compare what exists to what IAM knows about.
Q: Why do orphaned accounts and unmanaged applications create so much risk?
A: They create risk because no one is accountable for their access state.
Q: What do security teams get wrong about machine identity governance?
A: They often try to manage machine identities with human-centric processes.
Practitioner guidance
- Inventory identities outside formal governance Run discovery across cloud, SaaS, and engineering environments to find apps, service accounts, tokens, and certificates that are active but not mapped to an owner or lifecycle record.
- Reconcile ownership before review cycles Require every identity in scope for recertification to have a named owner, a business purpose, and a documented offboarding path before it is allowed into the review process.
- Separate machine identity governance from human IAM Use distinct workflows for service accounts and secrets so machine identity lifecycle, rotation, and access review do not rely on human access processes that were never designed for them.
What's in the full article
Orchid Security's full blog post covers the narrative detail this post intentionally leaves for the source:
- The article’s full metaphorical explanation of identity dark matter and how the analogy is meant to reshape IAM thinking.
- Orchid Security's examples of invisible identity risks across applications, orphaned accounts, and machine identities.
- The vendor’s own framing for why the blind spot persists and how it wants readers to think about future posts in the series.
👉 Read Orchid Security's post on identity dark matter in IAM →
Identity dark matter: what IAM teams are not seeing yet?
Explore further
08/06/2026 9:12 am
Identity dark matter is not a visibility problem alone. It is a governance failure where access exists outside the system that is supposed to define it. If an identity never enters the IAM control plane, the organisation has no reliable ownership, lifecycle state, or review evidence for it. That means audit confidence is being inferred from partial data. Practitioners should treat unseen identity as an operational control gap, not a reporting inconvenience.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the same report.
A question worth separating out:
Q: What frameworks should organisations use to reduce hidden identity risk?
A: Use OWASP Non-Human Identity guidance for machine identity failure modes and NIST CSF for control coverage and assurance. Together they help teams move from broad visibility claims to verifiable ownership, monitoring, and remediation. The important question is not whether the policy exists, but whether the organisation can prove every identity is in scope.
👉 Read our full editorial: Identity dark matter shows why IAM dashboards miss hidden access
