For every employee in your organization, there are many more identities you've probably never inventoried, and attackers know it. Service accounts, API keys, OAuth tokens, workload identities, and RPA bots form a silent majority inside your environment. Most lack a named owner, a rotation schedule, or a retirement process. Credentials remain the attacker's favorite way in. Verizon's 2024 Data Breach Investigations Report found that stolen credentials appeared in almost one-third of breaches over the past 10 years. Most identity programs were designed around people, while machines were assumed to be "trusted by configuration." That assumption is now the blind spot. This post defines what a non-human identity (NHI) is, explains why human-centric controls fail for machines, walk through common breach patterns, and offers a four-step governance starting point you can take to your next board review.

What Counts as Non-Human Identity?

Your security, platform, and DevOps teams need a shared definition before they can govern anything. A working one: any digital identity that authenticates, requests access or executes actions without a human at the keyboard. In a modern enterprise, that includes:
  • Service accounts: Active Directory, database, and application accounts used in background processes
  • API keys and OAuth tokens: static or rotating secrets for system-to-system calls
  • Workload identities: Kubernetes service accounts, AWS IAM roles, Azure managed identities, GCP service accounts
  • CI/CD pipeline credentials: build agent tokens, deploy keys, Git PATs, artifact repository credentials
  • RPA bots and automation scripts: UiPath, Automation Anywhere, custom jobs
Cloud-native architecture, microservices, and DevOps velocity each spawn new credentials, and every new integration adds more. A note on AI agents. Agentic AI isn't just another type of NHI. An agent is a non-deterministic actor that decides at runtime what to do, and it consumes NHIs (tokens, roles, keys) to do it. Governing the credential is necessary, but a credential alone doesn't tell you what the agent will do with it. Agents need everything in this post, plus controls for delegated intent, task-scoped access, and accountability for each action. We'll cover that in a dedicated post.

The Scale Problem: More Identities Than Anyone Is Counting

Published estimates of the NHI-to-human ratio vary, from roughly 50 to 1 to well over 80 to 1 in recent vendor research. CyberArk's 2025 Identity Security Landscape report put it at 82 to 1. Whatever the exact multiplier, the direction is the same. For a 5,000-employee enterprise, even a conservative 20:1 ratio means 100,000 non-human identities. Most have no inventory record, no documented owner, and no defined end of life. This governance debt compounds quietly. It rarely appears in board reports until an incident puts it there, and the average breach now costs $4.88M (IBM Cost of a Data Breach Report 2024).

Why Human-Centric IAM and PAM Break for Machines

Most identity controls assume a person at the other end. Here are five gaps to brief your board on.
  • No lifecycle owner. This is the core governance failure. Service accounts routinely outlive the engineer who created them. No HR leaver process triggers deactivation, no access review catches them, and no manager attests to ongoing need. Without an owner, nothing else gets done.
  • No MFA option. Machines can't satisfy a second factor. They rely on static secrets, certificates, or, when configured well, short-lived tokens.
  • Secrets sprawl. API keys end up in Git repos, container images, CI/CD variables, chat messages, and developer laptops. The credential perimeter is no longer your directory but every artifact every engineer has touched.
  • Over-privileged by default. Machine identities get broad permission "to make it work" during integration, and nobody trims them later. Least privilege takes deliberate effort, while over-privilege is the path of least resistance.
  • No behavioral baseline or clean audit trail. SOC tooling is tuned to human anomalies like impossible travel and off-hours logins. Machine behavior is harder to baseline, and shared service accounts hide the human behind an action, which complicates audit requirements under frameworks such as SOX and PCI DSS.

Four Common Breach Patterns Involving NHIs

Each of these maps to techniques your detection team should already track in MITRE ATTACK.
  1. Exposed API key in a public repository leads to cloud compromise. A developer commits an access key. Automated scrapers find it quickly. The attacker enumerates permissions, escalates, and reaches production data. (T1552.001, Credentials in Files)
  2. Compromised pipeline credential leads to supply chain exposure. A build system's token or service account is abused to alter downstream artifacts or reach other environments. The more privileges the pipeline identity holds, the wider the blast radius. (T1195.002, Compromise Software Supply Chain)
  3. Abused OAuth application leads to inherited access. An OAuth app or token with broad, long-lived access to a core platform is compromised or misused. The attacker inherits that scoped access and bypasses user-facing MFA entirely. Microsoft's January 2024 disclosure of the Midnight Blizzard intrusion, which involved abuse of a legacy OAuth application, is a well-known example.
  4. Orphaned service account leads to a persistent foothold. An account created for a decommissioned application is never deactivated. Its credentials, still valid, are found during reconnaissance and used as a quiet persistence channel that survives password resets aimed at human accounts. This is the pattern ownership prevents.

A Four-Step NHI Governance Starting Point

You don't need a new tool category to start. You need a program. These steps align with NIST CSF and Zero Trust principles (NIST SP 800-207).
  1. Inventory. You cannot govern what you cannot see. Build a continuous inventory across Active Directory, cloud IAM, Kubernetes, SaaS integrations, CI/CD systems, and secrets managers. Treat it as a living asset, not a one-time scan.
  2. Own. Every NHI needs a named human owner and documented business justification. No owner is a candidate for deprovisioning. This single control catches most orphans, and it should be enforced at creation time, so the backlog stops growing.
  3. Constrain. Right-size entitlements continuously and favor short-lived, just-in-time credentials over standing privilege. Vault static secrets, rotate them on a defined schedule, and revoke them when ownership lapses.
  4. Certify and monitor. Owners should attest on a regular cadence that each NHI still needs to exist and still needs its access. Feed NHI activity into your SOC alongside human identity signals, so anomalies and unowned accounts surface early and flow back into steps 2 and 3.

How ARCON Can Help

Governing non-human identities takes three things working together: knowing what exists and who owns it, keeping secrets out of code and under control, and managing how workloads authenticate and what they can reach. ARCON is building toward exactly that. Our approach to NHI gives security teams a single view of non-human identities and their owners. A secrets vault takes credentials out of code, configuration, and pipelines and keeps them rotated and revocable. Workload IAM governs how applications and services authenticate and what access they hold across their lifecycle. The aim is for every identity, human or non-human, to be discovered, owned, scoped, and accountable.