Three days to map the blast radius of a compromised contractor account is the outcome of an identity visibility gap, not an incident response gap. The access existed in disconnected systems you couldn't see. The contractor's engagement had ended but the accounts remained. Service accounts from previous contractors were still active. Eight SaaS applications your security team didn't know about had their own authentication, entirely outside Entra's visibility.

This is identity dark matter — the access that exists and is enforceable, but that your IAM stack has never seen and therefore can't govern.

The findings from your post-incident assessment map exactly to the categories that traditional IGA platforms, CASB tools, and manual spreadsheets each fail to cover:

• Local admin accounts nobody documented → outside CASB scope, not in Entra
• Service accounts from contractors who left years ago → no HR trigger, no lifecycle
• Shadow IT apps with their own auth → outside SSO, outside CASB if internal
• Shared credentials in 1Password → no identity owner, no usage visibility

The problem isn't your SSO setup. The problem is that your SSO perimeter covers roughly 40-60% of the identity surface in most hybrid environments, and the governance tools you've evaluated assume 100% SSO coverage as a prerequisite.

Why the Standard Tools Don't Cover This

Traditional IGA platforms are built on the assumption that every application has a mature API or SCIM endpoint. They work well for the enterprise SaaS stack — Salesforce, GitHub, Slack — and require significant professional services investment for anything outside that catalog. The discovery problem (finding what you don't know about) is not in their design. They govern what you tell them to govern.

CASB tools see SaaS traffic that traverses your network or proxy. They miss internal custom applications, on-prem systems, and any SaaS tool accessed outside your corporate network or VPN. They're useful for SaaS visibility but have no reach into the local admin account layer or legacy databases.

Manual spreadsheets capture what someone manually documented at a point in time. They go stale immediately and have no mechanism to surface what was never documented in the first place.

The visibility gap requires a different approach: discovery that works from the bottom up rather than requiring integrations as a prerequisite.

How Multi-Source Discovery Actually Works

The key architectural insight is that identity dark matter is visible from multiple signals that individually are incomplete but collectively are sufficient. A user accessing a SaaS tool outside SSO generates a browser event. A department paying for a tool outside IT procurement generates a financial transaction. A service account with no owner generates an anomalous pattern when cross-referenced against the HR directory.

Browser and desktop agents deployed at the endpoint level track the actual URLs and applications employees are accessing — including tools that never went through IT procurement and don't traverse a proxy. This is how shadow IT apps with their own authentication show up on your radar. The user's device sees the traffic regardless of whether your SSO does.

Financial and expense system integration — analyzing corporate card transactions and expense reports — identifies the SaaS tools departments are buying outside IT's purview. The tool you didn't know existed shows up as a recurring charge in Concur or Expensify. This is often where the 8 undocumented apps you found post-incident would have appeared months earlier.

HRMS cross-referencing converts your HR termination data into an active access anomaly detection system. When a contractor's contract ends and they're marked inactive in HR, every application account associated with that person that remains active becomes an immediate finding — regardless of whether that application is connected to Entra. The blast radius mapping that took you 3 days becomes a real-time query.

Active Directory agent for on-prem environments: a lightweight Docker-based agent deployed inside your network connects via LDAP/LDAPS to discover local users, OUs, and admin groups and sync them to your central dashboard. Local admin accounts that nobody documented show up in the inventory because the AD agent finds them, not because someone entered them manually.

Legacy database agents for systems with no API: agents that execute custom scripts locally against legacy databases to fetch local admin lists and return them to a central access review interface. For your 2010-era database infrastructure, this is the path to visibility that doesn't require rebuilding the applications.

Zluri's IVIP (Identity Visibility and Intelligence Platform) layer combines these sources into what it calls a Unified Data Fabric — a continuously updated access graph that covers the full identity surface rather than just the SSO-connected portion.

Specific Findings From Your Assessment and How Each Gets Addressed

Local admin accounts nobody documented. The AD agent discovers these from your existing AD structure without requiring anyone to have documented them. The output is an inventory of local admin accounts, their last activity, and their group memberships — visible in a central dashboard and includable in access review campaigns.

Service accounts from contractors who left years ago. HRMS cross-referencing flags any application account associated with an HR record showing a past termination date. Non-human identity classification specifically identifies service accounts and tracks their ownership status. Service accounts with no current owner are flagged for accountability assignment or disablement.

Shadow IT apps with their own auth. Browser agent data and financial transaction analysis surface these without requiring anyone to have reported them. Once discovered, they're classified, risk-scored, and added to the governance scope for access reviews and offboarding workflows.

Shared credentials in 1Password vaults. Shared credential detection identifies accounts that appear to be used by multiple people or lack a single designated owner. These surface as findings for ownership assignment, with the option to convert to individual accounts or establish explicit ownership with a documented lifecycle.

What Comes After Discovery

Discovery answers "what exists." Governance answers "what should exist and what happens when it doesn't." The two phases need to connect.

Once the dark matter is visible — local admins, orphaned service accounts, shadow IT apps, shared credentials — the next step is bringing it into the governance lifecycle: assigning owners, running access reviews against the discovered inventory, and connecting the deprovisioning process to HRMS events rather than manual request submission.

The blast radius problem that took 3 days is a one-time incident response cost. The recurring cost is the next incident, and the one after that. The structural fix is continuous visibility that updates when people join, move, and leave — so the answer to "what did this compromised account have access to" is a real-time query rather than a multi-day investigation.

Frequently Asked Questions

What is identity dark matter in cybersecurity?

Identity dark matter refers to the access, accounts, and credentials that exist in an environment but are invisible to the primary IAM or identity provider. It includes shadow IT applications that bypass SSO, local admin accounts not documented in the central directory, service accounts with no lifecycle management, orphaned accounts from departed users in disconnected systems, and shared credentials with no individual owner. These are often the access paths exploited in security incidents because they fall outside standard monitoring and governance.

Why can't Azure Entra ID or CASB tools see all identity activity in a hybrid environment?

Entra ID governs applications federated to it via SSO. Applications with their own authentication, local admin accounts in on-prem systems, and legacy databases aren't connected to Entra and generate no Entra log data. CASB tools see SaaS traffic through corporate network proxies but miss applications accessed off-network, internal custom applications, and on-prem systems. Neither tool was designed to discover access that was never onboarded to the identity stack in the first place.

How do you find orphaned accounts from departed contractors in disconnected systems?

The reliable approach is cross-referencing application account inventory against HR termination data — establishing the HRMS as the source of truth and flagging any active application account associated with an inactive HR record. This works regardless of whether the application is connected to your IdP. The key is having application account inventory from disconnected systems, which requires either agent-based discovery (for on-prem) or browser/financial data integration (for SaaS shadow IT).

What are non-human identities and why are they hard to govern?

Non-human identities (NHIs) are accounts, credentials, and keys that authenticate between systems rather than on behalf of human users: service accounts, API keys, OAuth service principals, bot accounts, and managed identities. They're difficult to govern because they don't generate usage patterns that look like human behavior, they don't have managers or HR records, and they tend to accumulate permissions without a lifecycle process. Discovery platforms that specifically classify NHIs and track their ownership status are the prerequisite for governing them.