Identity Dark Matter: Is your IAM missing the elephant in the room?
Saw the piece on IVIPs and 'Identity Dark Matter' on Hacker News today, and it really resonated with the current state of our enterprise IAM. As we scale, the fragmentation between decentralized teams, machine identities, and autonomous systems is creating massive blind spots. It feels like we're playing whack-a-mole with SaaS sprawl and service accounts that live completely outside the purview of our IdP.
The article defines Identity Dark Matter as identity activity sitting outside centralized visibility. In my experience, this usually manifests as legacy apps performing direct LDAP binds or third-party SaaS tools provisioned via CSV files rather than SCIM.
I've been trying to hunt down these gaps by correlating network flows with authentication logs to spot anomalies. For those using Microsoft Sentinel, here is a basic KQL query I’m testing to flag users authenticating to resources that are not registered service principals in Entra ID:
SigninLogs
| where ResultType == 0
| extend AppId = tostring(AppId)
| join kind=leftanti (
ServicePrincipalInfo
| project AppId
) on AppId
| summarize count() by UserPrincipalName, AppDisplayName
| where count_ > 5
It’s a crude start, but it helps identify the 'dark matter' of unmanaged apps.
How is everyone else handling this visibility gap? Are you investing in dedicated IVIP platforms, or just expanding your SIEM correlation logic to catch shadow IT?
The concept of Identity Dark Matter is spot on. We performed an audit last month and found 40+ SaaS apps being used by Dev that had no SSO integration. They were just creating local accounts. We're moving toward a 'deny by default' policy for corporate network access to unlisted SaaS, but the political pushback is real.
From a pentester's perspective, this is exactly how we maintain persistence. We look for those legacy service accounts running on old servers that haven't been rotated in years. They aren't in the IdP, so they don't show up in your standard 'disable terminated user' scripts. Your KQL query is a good start, but don't forget to look for non-standard authentication protocols like NTLM or basic auth in your firewall logs.
We tried building custom SIEM rules like yours, but the noise was overwhelming. We eventually implemented an IVIP (specifically Strata/Conductor) to automate the discovery. It actually integrates with our HRIS to detect orphaned accounts on non-standard platforms. The visibility into machine identities was the game changer for us.
Don't forget container workloads. Service accounts in Kubernetes often get bound to IAM roles, creating a direct path to cloud resources that bypasses your IdP entirely. It's crucial to audit your RoleBindings and ClusterRoleBindings to ensure no pods have overly permissive access.
kubectl get rolebindings,clusterrolebindings --all-namespaces -o path='{range .items[?(@.subjects[?(@.kind=="ServiceAccount")])]}{.metadata.name}{"\t"}{.subjects[0].name}{"\n"}{end}'
Mapping these back to human owners is often the hardest part of the cleanup.
Hannah is right about containers. From the EDR side, we often detect dark matter by looking for 'orphaned' logons—instances where a user is active on an endpoint but the ID doesn't resolve back to the IdP.
We hunt for this using a simple KQL query to flag interactive logons from non-AAD accounts:
DeviceLogonEvents
| where LogonType == "Interactive"
| where isnotempty(AccountName) and isempty(AADUserId)
It's been surprisingly effective at catching local admin sprawl that our IAM team missed.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access