They sit outside normal joiner-mover-leaver and review workflows, so they can keep authenticating and executing after the organisation has lost sight of them. That makes service accounts, local accounts, and application-specific users a durable source of ungoverned access in otherwise mature IAM environments.
How identity dark matter identities evade normal governance
identity dark matter identities are not risky because they exist, but because they often persist outside the control points that keep identity programmes accurate. They may be created for a project, embedded in an application, or inherited from a legacy system, then forgotten. Once that happens, governance becomes reactive instead of continuous, and the organisation loses the ability to prove who owns them or why they still need access.
That creates a structural gap between what the identity system thinks is governed and what is actually still active. Mature programmes often focus on joiner-mover-leaver flows for people, while these accounts continue to exist as quietly functioning exceptions. The result is an identity estate with stale entitlements, unclear ownership, and authentication paths that survive long after business need has ended.
For teams building broader identity visibility, the problem is often not the absence of controls, but the absence of discovery. Resources like Identity Visibility and Intelligence Platforms (IVIP) Guide are useful because they explain how hidden identities, identity graphs, and effective access views help surface what standard inventories miss. That is the real governance challenge: you cannot govern what you cannot consistently see.
Why they become durable sources of ungoverned access
These identities become durable because they are usually tied to something operationally sticky, such as an application, batch job, integration, or local operating-system account. In practice, that means they are less likely to move through approvals, periodic reviews, and ownership attestations that are routine for workforce access. If the surrounding system still works, teams are often reluctant to disturb the account even when no one can explain its origin.
Service accounts, local accounts, and application-specific users are especially prone to this pattern because they are created to make systems work, not to fit a lifecycle process. The IAM and IGA Basics guide is helpful here because the control problem is really about provisioning, entitlement review, and governance over both people and machines. When those processes are absent or incomplete, identity drift accumulates quietly.
At scale, these identities can also hide behind environment boundaries, shared credentials, or application teams that assume “someone else owns it.” That is why lifecycle discipline matters. NHI Lifecycle Management Guide captures the operational pattern well: discovery, ownership, rotation, and offboarding are not optional extras, they are what prevent identities from becoming permanent but unmanaged access paths.
What governance teams should do differently
Governance should treat identity dark matter as an inventory and ownership problem first, then an access problem. Start by separating accounts that are operationally required from accounts that are merely tolerated because they have not yet broken anything. The right question is not whether the account has been used recently, but whether the business can still justify its existence, owner, and access scope.
One practical anchor is to review hidden or legacy identities through the lens used in Identity Security Posture Management (ISPM) Guide, which emphasises posture findings such as dormant accounts, standing access, and configuration drift. That approach helps shift the conversation from annual cleanup to continuous governance, where exceptions are measured and tracked rather than rediscovered after an incident.
The best control outcome is not zero dark matter, because some machine and application identities are necessary. The goal is to make each one attributable, bounded, and reviewable. Teams should be able to answer three questions for every non-human or application-specific identity: who owns it, what system depends on it, and what would happen if it were revoked tomorrow.
Risk and Threat Considerations
These identities are attractive to attackers because they can provide stable access with less scrutiny than interactive user accounts. When ownership is unclear and review processes do not reach them, compromise can persist for a long time, and privilege can quietly expand through reuse, shared secrets, or overly broad permissions.
Failure mechanism: The account exists outside normal governance, so rotation, review, and revocation do not happen reliably; that lets access survive after the legitimate business need has ended, or after an attacker has obtained the credential.
Impact: An ungoverned identity can become a durable foothold for unauthorised access, lateral movement, privilege abuse, or silent operational dependence on credentials no one is actively controlling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dark matter identities persist through uncontrolled secrets and credentials. |
| AC-2 — Account Management | The issue is unmanaged account lifecycle and missing ownership. | |
| IA-9 — Service Identification and Authentication | Service and application identities are central to the risk described. | |
| Recommendation — Inventory and rotate authenticators for forgotten accounts before they become durable access paths. Enforce account ownership, review, and timely removal for inactive or orphaned identities. Authenticate service and workload identities with explicit lifecycle and revocation controls. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity dark matter is fundamentally an identity governance failure. |
| A.5.18 — Access rights | Ungoverned access is the direct consequence of these hidden identities. | |
| Recommendation — Maintain authoritative identity records and ownership for non-human and application accounts. Review and revoke access rights that lack current business justification. | ||
Practitioner Guidance
What to prioritise: Focus first on accounts that can authenticate to production systems, especially those with shared credentials, no clear owner, or no expiry. If the account can reach sensitive data or administration functions, treat it as a governance exception, not a housekeeping item.
What to verify: Confirm that every dark matter identity has a named owner, a documented business purpose, and a review path that is actually exercised. If you cannot produce those three things quickly, the account is already outside effective control.
Common mistake: Teams often assume that “non-interactive” means “low risk.” In reality, machine and application identities can be more dangerous than human accounts because they are harder to notice, less likely to be challenged, and often embedded in automated workflows that are not monitored closely.
Practitioner takeaway: Governance fails when identities are allowed to become operational facts instead of managed assets; the control objective is continuous attribution, review, and removal of access that no longer has a defensible owner or purpose.
Related resources from NHI Mgmt Group
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?
- Why do non-human identities create compliance risk even when policies exist?
- Why do duplicate identities and unclassified shadow users create operational risk in identity governance?