Identity

Think of identity dark matter as a containment challenge

COMMENTARY: An attacker needs one stolen credential that still works. The enterprise has to find every place it can work.

The recent FortiBleed case illustrates that asymmetry. Fortinet described attackers reusing credentials from earlier incidents and urged customers to check for unauthorized accounts and lateral movement. Containment has to follow the access those credentials enable.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

What we call identity dark matter represents the access embedded in applications that sits outside central identity visibility and control. It includes local accounts, service identities, API credentials, and authentication paths that bypass the enterprise’s identity provider.

We arrived here by building identity and access management (IAM) one use case at a time. Workforce access, customer identity, governance, and privileged access became separate point solutions, each with its own connectivity and policy model.

Each asset and application then needs onboarding into the relevant tools through vendor-specific connectors, APIs, and configuration. One application may support workforce, consumer, and partner logins alongside machine-to-machine traffic, service accounts, and AI agents. Each authentication path and its permissions must be understood and integrated. A completed workforce SSO integration can leave service accounts or partner access outside central governance.

The scale becomes substantial. Our Identity Gap 2026 Snapshot, based on enterprise application telemetry from North America and Europe, found that 57% of analyzed applications bypassed centralized identity providers. Some 67% of nonhuman accounts were created directly inside applications, outside central IAM oversight, and 70% of applications had excessive privileged accounts.

These gaps affect the authority behind a credential. In its July 2026 intrusion write-up, Hugging Face described a shared connector credential that gave an intruding agent administrator access across multiple clusters. Teams need to understand where access works and how far it extends.

That uncertainty becomes a barrier to safe AI adoption. Agents use the identities, credentials, and permissions of the applications in which they connect. An agent assigned to summarize invoices may use an encapsulated plain-text service account that can also change payment details. The task does not automatically limit the account’s authority. Security and business owners cannot responsibly approve that workflow until they can define its target destination boundaries, trace its actions, and stop its access.

Teams should begin with applications that hold sensitive data or permit high-impact actions. Discover their identities, credentials, and actual authentication paths. Map effective permissions, identify bypass routes, and assign accountable owners.

Auditability cannot wait until every application gets fully governed. Systems still outside central IAM need application-level evidence of actual use: successful and failed authentication, delegation and token activity, permission changes and sensitive operations. Correlate that telemetry with existing IAM logs to establish who or what acted, through which account and with what authority. Preserve human, service and agent attribution wherever available.

Connect this identity map and audit stream to data-classification feeds. Link permissions and observed activity to the sensitive resources applications expose, including customer records, financial information, and intellectual property. That context helps teams prioritize dangerous access and define what data an AI workflow may use. An account’s significance depends on what it can reach and what it actually does.

Use those findings to coordinate controls through the existing IAM stack. Bring uncovered paths under authentication, governance, and privileged-access controls, with application-specific enforcement where needed. Scope credentials to required resources and limit permissions to the task.

During an incident, rotate exposed and reused credentials across affected systems, terminate compromised sessions, remove unauthorized accounts, and reduce excessive permissions. Revoke tokens where supported and account for those still valid until expiry. Verify that compromised access no longer works through any identified route.

Keep discovery, auditing and classification context current as applications and permissions change. Measure coverage of critical access paths and time to verified containment. Those same capabilities offer the evidence needed to approve and safely expand AI adoption.

The news cycle moves on. The attacker’s access remains valuable until we find it and take it away.

Roy Katmor, co-founder and CEO, Orchid Security

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

You can skip this ad in 5 seconds