Most of the non-human identities in your enterprise never appear in an access review. These are service accounts, API keys, tokens, bots, workload identities, and pipeline credentials. Developers and platform teams provision them, they accumulate quietly, and published research puts them at many times the number of your employees. CyberArk's 2025 research, for example, estimates 82 machine identities for every human one.  Attackers have noticed. Verizon's 2024 Data Breach Investigations Report found that stolen credentials appeared in almost one-third of breaches over the past 10 years. The encouraging part is that the ways’ non-human identity (NHI) risk shows up are familiar. Three failure modes come up again: hard-coded secrets, over-privileged service accounts, and orphaned identities.  Each has a technical symptom, and each has a governance root cause. This post covers both, because fixing the symptom without the cause means fixing it again next quarter. 

Failure Mode 1: Hard-Coded Secrets 

The symptoms. A credential is embedded directly in source code, a configuration file, a container image, or a notebook, and sometimes ends up in a public repository. A single API key can expose a database, cloud infrastructure, or downstream services to anyone who finds it.  Why attackers like it. Hard-coded secrets are durable and unmonitored. A credential baked into an image or config file is rarely rotated, so a key that leaks today may still work months later. Automated scanners crawl to public repositories continuously, and a leaked key can be found and tried quickly. These maps are of MITRE ATT&CK Unsecured Credentials (T1552).  The governance root cause. Nobody owns the secret. Without an owner, nobody knows where it lives, what depends on it, or who should rotate it. When it leaks, the response is a scramble to find out what breaks.  What good looks like: 
  • No credential lives in code or configuration. Secrets sit in a managed vault and are injected at runtime. 
  • Pre-commit and pipeline scanning catches secrets before they reach a repository. 
  • Every secret has a named owner and a rotation schedule. 
  • When a secret is exposed, you can revoke and rotate it in minutes, because you know what depends on it. 

Failure Mode 2: Over-Privileged Service Accounts 

The symptoms. A service account is created so an application, script, or workload can do one task. Too often it is granted standing rights far beyond that task, such as domain-admin-equivalent permissions, wildcard cloud roles, or write access to systems it never touches. Nobody scopes it later, so the excess becomes permanent.  Why attackers like it. This is what attackers exploit under MITRE ATT&CK Valid Accounts (T1078). A compromised service account with broad rights gives adversary legitimate-looking access for lateral movement and privilege escalation, and it blends into automated traffic. These accounts run unattended and can't answer an MFA prompt, so anomalous use is hard to spot. A single foothold turns into wide reach.  The governance root cause. No documented business justification. If nobody wrote down what the account is for, nobody can tell whether its permissions are right, and every review defaults to "leave it, it might break something." What good looks like: 
  • Every service account has a documented purpose, and its permissions are scoped to that purpose. 
  • Standing privilege is replaced with just-in-time access wherever the workload allows. 
  • Entitlements are reviewed regularly against what the account uses, and unused rights are removed. 
  • Credentials are vaulted and rotated automatically. 

Failure Mode 3: The Orphaned NHI 

The symptoms. A credential outlives its purpose. The application was decommissioned, the project ended, or the engineer who created it left. The credential lives on, valid and functional, accountable to no one.  Why attackers like it. There is no owner to notice misuse, no process to trigger deprovisioning, and no access review to flag it for removal. Orphaned identities offer access without scrutiny, and misuse can go undetected for a long time. Each one is unmanaged attack surface that grows quietly.  The governance root cause. No lifecycle. Humans have a joiner, mover, and leaver process, and machines have nothing equivalent. Identities get created, but nothing is responsible for retiring them.  What good looks like: 
  • Every NHI has a named owner and a defined lifecycle from creation to retirement. 
  • Discovery is continuous, so identities are inventoried as they appear rather than found after an incident. 
  • Access certification covers NHIs as well as human users. 
  • Identities with no owner or no recent use are flagged and decommissioned. 

One Root Cause, Three Symptoms 

Failure mode  What breaks  Missing governance control 
Hard-coded secrets  Credentials scattered across code and artifacts  Ownership of every secret 
Over-privileged accounts  Permissions far beyond need  Documented justification and review 
Orphaned identities  Access outlives its purpose  Lifecycle from creation to retirement 
sss These are three views of the same gap: identities created without ownership, justification, or an end date. That is why more scanning, and more tooling alone rarely makes the problem go away.  Where AI agents fit. An agent inherits all three failure modes through the credentials it uses and adds a risk of its own: what it does with that access isn't fixed in advance. We'll cover agent governance in a dedicated post.

Governing NHIs Is a Discipline You Already Know 

Securing non-human identities doesn't require inventing a new security model. It requires applying disciplines you already use for privileged human access to a much larger and faster-moving population. The core practices are familiar:
  • Discover every identity so you can govern what you can see. 
  • Assign owners and document why each identity exists. 
  • Constrain access to what the function requires, and vault and rotate credentials. 
  • Certify continuously so entitlements are reviewed and orphans are retired. 
The challenge with NHIs is scale and automation, not a new theory of access. 

How ARCON Can Help 

Each failure mode in this post comes down to a missing control: ownership, justification, or lifecycle. ARCON is building NHI governance to supply all three. Ownership and lifecycle are tracked from the moment an identity is created, a secrets vault replaces hard-coded credentials, and workload IAM keeps access scoped to what each application needs. 

The Takeaway 

These failure modes aren't exotic, and you can find and fix them with discipline rather than new doctrine. If your access reviews stop at human users, the larger share of your identity estate is going ungoverned. The starting point is visibility: knowing how many non-human identities you have, who owns them, and what they can reach.