Why identity dark matter hides in plain sight

Every identity a company can name is only half the picture. The other half — local application accounts, embedded service credentials, legacy authentication flows, and integrations that never reached a central identity provider — is what one article calls identity dark matter. Stolen and misused credentials remain among the most frequently reported initial access vectors in breach research, including Verizon's annual Data Breach Investigations Report, and that hidden surface is where much of the exposure sits.

The Hacker News published an explainer on Sep 19, 2026 under its Identity Security and Zero Trust labels, describing what identity visibility means in IAM, why cloud and multicloud environments complicate it, and which capabilities matter in tools built for the job. The page also discloses that it is published by Orchid Security, which appears in the vendor list it contains.

Intent versus execution

The article defines identity visibility as the ability to see every identity in an environment, what it can access, and how that access is actually used at runtime. It combines inventory, entitlement mapping, and behavioral telemetry into one continuous picture instead of a periodic snapshot.

The distinction the piece leans on is between intent and execution. Identity and access management platforms express policy intent: who should have access, under what conditions, and for how long. Applications and infrastructure reveal execution: which credentials authenticated, which permissions were exercised, and which paths were taken.

The space between those two layers is where unregistered accounts live. The article characterizes that hidden surface as what makes visibility a security problem rather than an administrative one. It lists local application accounts, embedded service credentials, legacy authentication flows, and integrations that were never onboarded into a central identity provider as its components.

A byproduct of rapid adoption

Identity dark matter is rarely an isolated edge case, according to the piece. It is described as a common byproduct of a decade of SaaS adoption, cloud migration, and automation. When organizations add systems faster than their identity programs can absorb them, the gap between documented access and real access widens.

Attackers have adapted to that gap. Rather than deploying malware that endpoint tools are tuned to catch, many intrusions now begin with compromised legitimate credentials used within the permissions those credentials already hold, and the resulting activity can closely resemble normal operational behavior.

The article lists four drivers of growth in the identity attack surface:

• Credential-based intrusion: phishing, token theft, and session hijacking produce authentication events that resemble normal user behavior in IdP logs.
• Machine and non-human identities: service accounts, API keys, and workload credentials frequently outnumber employee accounts in cloud-heavy environments and often have no expiration.
• Application-local accounts: systems that authenticate outside single sign-on may never appear in centralized access reviews.
• Agentic AI workloads: autonomous agents act with delegated permissions across multiple systems, often at a pace and volume that manual review cannot match.

What conventional reports miss

Most IAM reporting describes configuration — group memberships, role assignments, and entitlement catalogs, per the article. That data answers what access was granted, but it does not say whether the application enforced it, whether the account still has a human owner, or whether the permission has been used in the last year.

Governance platforms also tend to report on the applications connected to them rather than verify coverage independently, the piece notes. If an application was never integrated, it does not appear in the report, and absence can be mistaken for compliance.

Verification rather than assumption is the organizing principle the article puts behind identity visibility in IAM. Three concepts make that verification possible: accurate inventory, mapped access relationships, and continuous contextual analysis.

An identity inventory lists the actors, an entitlement map explains what each actor can do, and access relationships connect the two across systems, revealing effective permissions rather than nominal ones. Effective access is often broader than intended, the article says: a user assigned a modest application role may inherit administrative capability through a nested group, a shared service account, or a trust relationship between cloud accounts. Relationship mapping exposes those chained paths, and those are the paths attackers traverse during lateral movement.

Discovery and risk context

Discovery answers a harder question than inventory — what exists that nobody registered. Continuous discovery pulls identity data directly from applications and infrastructure, surfacing local accounts, embedded credentials, and authentication methods that centralized IAM platforms never recorded.

Context then converts findings into priorities. The article offers a comparison: a dormant account with read access to a test system is low-consequence noise, while a non-expiring automation credential with write access to production, no assigned owner, and no multi-factor authentication carries materially higher risk.

Context fragments the moment identity data crosses provider boundaries. Cloud identity visibility is difficult not because cloud platforms lack logging, but because each one models identity differently and none of them describes what happens in the others, per the piece. Multicloud identity visibility is the practice of normalizing those vocabularies so a single identity can be traced across every environment it touches.

The article walks through the models that require normalization:

• AWS: roles, identity- and resource-based policies, and cross-account role assumption define what a principal can reach.
• Azure/Entra ID: directory principals, Azure RBAC role assignments, and consented application permissions across delegated and application scopes.
• Google Cloud: service accounts and IAM bindings that inherit scope through the organization, folder, and project hierarchy.
• SaaS applications: proprietary admin tiers, custom roles, and local accounts that never reach the identity provider.

Without normalization, security teams review each platform separately and can miss the connective tissue — federated trust, cross-account assumption, and shared credentials that let an identity in one cloud act inside another. Cloud lateral movement commonly follows these IAM trust relationships rather than network paths, according to the article.

Machine identities outnumber people

Machine identities are a subset of non-human identities, and in cloud environments they often represent the majority of principals, the piece states. Infrastructure automation creates them — pipelines, Terraform runs, orchestration tools — rather than HR-driven joiner-mover-leaver events, so they tend to bypass the lifecycle governance built for employees.

Control-plane identities deserve particular attention. Because they configure infrastructure itself, a compromised automation credential can create new access, alter logging configuration, or disable the controls meant to detect it, the article warns. It argues that every non-human identity benefits from the same governance attributes as a human account: a named owner, a stated purpose, an expiration or rotation schedule, and active monitoring.

What the tool category covers

Monitoring machine and human identities at scale is the job of identity visibility and intelligence platforms, a category the article says emerged because governance, cloud posture, and detection tools each addressed part of the problem. It presents a vendor list that it describes as illustrative rather than exhaustive and not ordered by performance, with overlapping and frequently changing capability sets that organizations should evaluate against their own environments. The page discloses that it is published by Orchid Security, which appears in that list.

The listed vendors and their stated starting points are: Orchid Security, which discovers identities, entitlements, and authentication flows directly from applications and infrastructure rather than relying only on IAM configuration data, and turns that telemetry into audit-ready compliance evidence, oriented toward application-layer blind spots; Veza, an observability-centric access graph mapping effective permissions across data systems, cloud platforms, and SaaS with an emphasis on entitlement-relationship analysis; SailPoint, a governance-centric platform focused on lifecycle management, certification campaigns, and policy enforcement at enterprise scale; Saviynt, combining identity governance and administration workflows with cloud infrastructure entitlement management analysis; Silverfort, runtime authentication visibility and enforcement including legacy and unmanaged systems that cannot readily be onboarded to modern SSO; Semperis, posture-centric protection for Active Directory and Entra ID emphasizing configuration hygiene, attack-path analysis, and recovery; and CrowdStrike Falcon Identity Protection, detection-centric identity threat detection and response tied closely to endpoint and workload telemetry.

Whatever the starting architecture, the baseline capability is the same, per the article: one authoritative inventory that reconciles identities across IdPs, cloud platforms, applications, and infrastructure, then maps effective access between them. A useful test of that inventory, it suggests, is whether it includes identities nobody registered — a platform that reads only IAM configuration will reproduce the blind spots already present in IAM, and application-layer discovery is what separates a report from an inventory.

Analytics and remediation

Inventory without analysis creates a longer list, not a safer environment, the piece cautions. Detection quality depends on the behavioral baseline: knowing what normal usage looks like for a given identity before judging a deviation.

The article identifies four analytics capabilities worth evaluating. Behavioral baselining distinguishes routine automation activity from anomalous privilege use by the same credential. Attack-path analysis assesses whether a misconfiguration is exploitable given permissions, reachability, and runtime context. Technique mapping aligns findings to MITRE ATT&CK identity-related techniques, such as Valid Accounts (T1078), so analysts can reason about adversary behavior rather than isolated alerts. Remediation routing sends findings to the owning team with the evidence needed to act, rather than to a shared queue.

Fitting the identity fabric

Identity visibility and intelligence is not a replacement layer, according to the article. It is the observability layer that makes existing identity investments verifiable. IAM platforms generally operate in two dimensions — design time, covering lifecycle, policy, and provisioning, and runtime, covering authentication and authorization enforcement — and visibility platforms observe both and report the difference between them.

That reporting feeds each neighboring system differently, per the piece. IGA receives evidence that certifications reflect real access. Privileged access management receives discovery of privileged accounts operating outside vaulting. Security operations receive identity context that can shorten timeline reconstruction during an investigation, instead of requiring analysts to stitch events together across several consoles.

Zero trust, as described in NIST SP 800-207, assumes continuous verification, and continuous verification requires continuous observation, the article notes. Access decisions are only as good as the signal behind them: session context, credential type, historical behavior, and the sensitivity of the target system. Identity intelligence supplies that signal.

Why it matters

The practical consequence for security teams is that the inventory they trust may be answering the wrong question. If an application never reached the identity provider, its accounts and credentials sit outside every access review, certification campaign, and dashboard an organization runs — and the article's own description of discovery suggests those are precisely the identities an attacker would prefer to use, because their activity has no established baseline to deviate from.

For cloud-heavy organizations, the normalization problem compounds this. Each provider's permission vocabulary is internally coherent, which makes per-platform review feel complete; the risk the article describes lives in the trust relationships between platforms, where an identity in one cloud can act inside another. That suggests teams evaluating visibility tools may want to test whether a given product can trace a single identity across every environment it touches, rather than count how many platforms it integrates with.

One caveat belongs here: the page carries a disclosure that it is published by Orchid Security, a vendor it also lists among identity visibility platforms. Readers weighing its vendor comparison should treat the list as one participant's framing. Nothing in the article identifies a specific breached organization, a measured victim count, or an independently verified incident, so the arguments it makes are best read as the vendor's account of a category it sells into, not as reporting on a confirmed event.