Identity dark matter shows why IAM controls miss real exposure

At a glance

What this is: Orchid Security argues that unmanaged application-level identity, or identity dark matter, is the dominant source of exposure in European enterprises, with cleartext credentials and IdP bypasses showing how much risk sits outside central IAM.

Why it matters: IAM, PAM, IGA, and security teams need application-level visibility because compliance coverage and central directory controls do not reliably reflect the real authentication and authorization paths attackers use.

By the numbers:

• 51% of identity implemented throughout European enterprises sits in an unmanaged layer the article calls identity dark matter.

Context

Identity dark matter is the unmanaged layer of application identity that sits outside central IAM controls. In practical terms, it is where local authentication, orphaned accounts, overpermissioned access, and weak or missing controls survive even when the enterprise believes its IAM programme is in place.

The article's core governance point is that identity exposure is measured where the application actually enforces access, not where policy says it should. That makes the problem directly relevant to NHI governance, human IAM, and any programme that assumes central visibility equals real control.

The article also places the issue in a European regulatory context, where access control, auditability, and account accountability are under increasing scrutiny. The starting position described is not an edge case; it is the normal state in large, diverse enterprise application estates.

Key questions

Q: What breaks when identity data remains siloed across IAM controls?

A: Siloed identity data produces blind spots, duplicate work, and slower response because each control sees only a partial version of the truth. Automation also weakens, since workflows cannot pass enough context to enforce policy consistently across systems.

Q: Why do local authentication paths and cleartext credentials create such high risk?

A: They let attackers bypass federation and reuse static secrets without defeating the central identity provider. Once an application stores credentials locally or accepts alternate login flows, compromise can occur entirely outside the main IAM monitoring model. That is why hidden authentication paths are often the shortest route to breach impact.

Q: How do teams know whether identity dark matter is actually shrinking?

A: They should look for fewer application-local accounts without owners, fewer credentials found in code, and fewer access paths that bypass centralized identity providers. A real reduction shows up as cleaner inventory, faster offboarding, and less reliance on unmanaged authentication. If those indicators do not improve, the hidden identity layer is still growing.

Q: Who is accountable when an application keeps its own identity model?

A: The application owner, IAM team, and security governance function all share accountability, but the system owner is responsible for exposing how identity is implemented at runtime. Regulators and auditors care about effective control, not internal ownership charts. If the application can authenticate or authorize independently, that fact must be owned and evidenced.

Technical breakdown

Why application-local identity control creates hidden exposure

Identity is often implemented inside the application itself, either natively or through partial integration with an IAM stack. That means authentication methods, authorization rules, emergency access, service accounts, and local credentials can exist outside the control plane the security team thinks it owns. In large enterprises with thousands of applications, those hidden paths accumulate into a parallel identity layer that central directories never fully see. The result is not just poor hygiene but a structural visibility problem: the authoritative source of access becomes the application, while governance tooling only sees the intended design. Practical implication: treat the application layer as the control boundary, not the IAM policy statement.

Practical implication: Inventory identity at the application layer, not just in the directory, because that is where exposure actually exists.

How cleartext credentials and IdP bypasses expand attack surface

Cleartext credentials, weak hashing, and authentication flows that bypass the corporate IdP create separate compromise paths that sit outside normal federation and monitoring. When applications support local login, alternate protocols, or static secrets, an attacker does not need to defeat the central identity provider at all. That breaks the assumption that a single sign-on layer meaningfully contains account risk. It also weakens audit confidence, because the presence of an IdP says little about how many real authentication paths remain in use. Practical implication: map every credentialed and federated path per application, then compare it to what the IAM stack can actually observe.

Practical implication: Map every authentication path per application, including local and alternate flows, before assuming SSO has reduced risk.

Why dormant, orphaned, and overprivileged accounts persist

The article describes identity dark matter as including dormant accounts, orphaned accounts, and access that becomes overpermissioned over time. These conditions arise when joiner-mover-leaver processes stop at the central directory but do not fully track application-level entitlements, third-party access, or emergency accounts. In effect, governance becomes time-lagged: access is granted for one purpose and retained after that purpose changes. That is why the issue is not only technical debt but accountability debt. Practical implication: tie access reviews to the actual application account lifecycle, not to directory recertification alone.

Practical implication: Align joiner-mover-leaver controls to application accounts, or privilege creep will survive every directory review.

Threat narrative

Attacker objective: The attacker aims to reach and abuse the application's real access paths without having to compromise the central identity stack first.

1. Entry begins where an application retains a local credential, alternate login path, or bypassed federation route that is outside the central identity provider.
2. Credential access follows when cleartext secrets, weak hashing, or static application credentials are available to abuse rather than revoke.
3. Escalation occurs through overpermissioned, dormant, or orphaned accounts that preserve more access than the current business need justifies.
4. Impact is reached when the attacker uses those hidden identity paths to move through applications and data stores without triggering the organisation's primary IAM controls.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity dark matter is not an edge condition; it is the operating reality of large application estates. Central IAM programs describe intent, but the application layer determines whether that intent is enforced. When local authentication, orphaned accounts, and alternate access paths exist, policy coverage and actual exposure diverge. Practitioners should treat hidden identity paths as a primary governance domain, not a cleanup task.

Application-level identity visibility is now the decisive control boundary. The article shows why directory-centric assurance fails when apps can authenticate, authorize, and retain access independently. That means recertification, PAM, and audit evidence all become incomplete if they do not reach the application source of truth. The practical conclusion is that governance must follow the runtime identity implementation, not just the corporate control model.

Identity dark matter creates an exposure gap that traditional audits systematically miss. If 44% of applications bypass the IdP and 48% store credentials in cleartext, the problem is not policy absence but enforcement absence. That is why compliance success can coexist with real-world compromise paths. The implication for IAM and IGA leaders is that control coverage must be measured at the application edge, where hidden identity behaviours live.

Managed identity cannot be assumed from tooling presence alone. An enterprise can have an IdP, PAM, and IGA and still leave substantial identity surface unmanaged if applications keep their own access logic. That is a programme-design failure, not just an operations gap. The named concept here is identity dark matter: access paths that exist, matter, and remain outside the control plane that claims ownership. Security teams should define and govern that layer explicitly.

Compliance evidence must be derived from observed application behaviour, not documentation drift. Regulatory scrutiny increasingly expects proof of access control, not a statement that controls exist somewhere upstream. When applications diverge from central identity standards, the weakest implementation becomes the real control. For identity leaders, the field lesson is simple: if you cannot observe it at the application, you cannot govern it at scale.

What this signals

Identity dark matter turns application inventory into an identity-control problem. Teams that only track sanctioned directories will continue to miss local authentication, emergency accounts, and shadow access paths. The practical shift is from directory governance to application governance, because the runtime implementation is where exposure accumulates.

Control evidence has to move closer to the application source. Audit success does not prove that hidden login paths are absent, only that the documented control set passed review. The next maturity step is to correlate access, authentication, and authorization at the app layer before recertification or remediation decisions are made.

For practitioners

• Inventory application-level identity paths Discover every authentication flow, local account, alternate login method, and shadow identity path across the application estate, including legacy and self-hosted systems.
• Reconcile central controls to application reality Compare directory, PAM, and IGA coverage against what each application actually enforces, then mark gaps where local access still bypasses corporate identity controls.
• Target cleartext and weakly protected credentials Prioritise applications that store cleartext credentials, use weak hashing, or fail to enforce token expiry, because those weaknesses create the most direct compromise paths.
• Reset access review scope Include orphaned, dormant, service, emergency, and third-party accounts in reviews so recertification reflects the true account estate, not just the central directory.
• Continuously monitor identity drift Track changes in permissions, login controls, and authentication methods after patches, upgrades, and business changes so hidden identity pathways do not reappear unnoticed.

Key takeaways

• Identity dark matter describes the gap between central IAM design and the access behaviour actually embedded in applications.
• The article shows that hidden local authentication, cleartext secrets, and bypassed IdP flows can coexist with apparently mature IAM programmes.
• The strongest response is to govern identity at the application layer, where real enforcement, drift, and accountability can be observed.

Key terms

• Identity Dark Matter: Identity dark matter is the hidden mass of old grants, unused credentials, and inherited access that exists in an environment but is not actively understood. In NHI programmes it becomes dangerous because autonomous systems can discover and reuse it at machine speed.
• Application-Level Identity: Application-level identity is the authentication and authorization logic implemented inside a specific application rather than enforced only by a central directory. It matters because the application, not the policy document, ultimately decides how access is granted, retained, and revoked.
• Shadow Identity: A shadow identity is a machine identity created outside central governance, often by developers or automation tooling. These identities are dangerous because they bypass normal provisioning and offboarding controls, making them hard to inventory, review, and revoke before attackers find them.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.