Non-Human Identity Security: The Credential Risk Hiding in Plain Sight Across Your SDLC

Key Takeaways

• NHIs outnumber humans 144:1: Most machine credentials have no designated owner, no expiration policy, and no regular access review.
• Identity abuse is a top attack vector: 30% of all intrusions in 2024 started with valid credential abuse, and machine identities are the fastest-growing share of that surface.
• Credential risk spans the entire SDLC: Hardcoded secrets in repos, overprivileged pipeline tokens, cached credentials in container layers, and unmonitored cloud workload identities all create exposure.
• Secrets management is necessary but not sufficient: Vaulting protects the credential value. NHI security governs the identity itself: its permissions, behavior, and lifecycle.
• A scalable program starts with discovery: You cannot enforce least privilege or rotation policies on identities you haven’t inventoried and classified.

---

The average enterprise runs 144 machine credentials for every human identity it governs, and almost none of them have an owner, an expiration date, or a security review.

Non-human identities, the service accounts, API keys, tokens, and certificates that power every automated workflow in modern development, now outnumber human identities 144 to 1 in the average enterprise. Most have no designated owner, many never expire, and identity abuse already accounts for 30% of all intrusions, according to IBM’s X-Force 2025 Threat Intelligence Index. 

The problem compounds at every stage of the SDLC where hardcoded secrets persist in repo histories, CI/CD pipelines run with overprivileged tokens that leak into build logs, container images cache credentials in hidden layers, and cloud workloads inherit standing permissions that no one reviews. When one of these credentials is compromised, the average cost now stands at $4.88 million.

The strongest AppSec programs treat non-human identity security as an architectural problem that spans the full software development lifecycle, requiring visibility from code through runtime.

NHI credential risk builds across the SDLC, from code and pipelines to runtime systems. Security teams need controls that account for how machine identities are created, used, rotated, and governed at scale. 

What Are Non-Human Identities in the SDLC?

A non-human identity is any credential assigned to a software component, service, or automated process that authenticates and accesses resources without direct human involvement. In practice, non-human identities show up everywhere modern software gets built and shipped.

Every microservice-to-microservice call, every CI/CD pipeline run, every cloud workload spinning up at runtime depends on some form of machine credential. The more distributed the architecture, the more identities get created. 

And with agentic AI entering the picture, the growth is accelerating. Gartner forecasts that by 2028, over 33% of enterprise applications will incorporate agentic AI, up from less than 1% in 2024. Each of those agents will need its own credentials to operate.

The table below breaks down the most common NHI types and where machine identity security risk concentrates for each:

Identity Type	Primary Function	Key Risk Factor
Service accounts	Background processes, application tasks	Excessive permissions, no designated owner
API keys and secrets	Third-party and SaaS integration	Hardcoded in code, no expiration by default
OAuth tokens	Delegated application access	Persistent refresh tokens, broad scopes
Workload identities	Resource-to-resource authentication (cloud)	Often overprivileged, context-bound but unreviewed
Certificates	Encrypted communication (mTLS, X.509)	Missed rotation, expiration outages
CI/CD pipeline tokens	Build, test, and deploy automation	High privilege, exposed in logs and environment variables

Why Non-Human Identity Risk Is Harder to Manage Than Human Identity Risk

Human identities follow a lifecycle that security teams understand well. An employee joins, gets provisioned, changes roles, and eventually leaves. Next, HR triggers deprovisioning, and access gets revoked. The process has gaps, but the model is mature.

Non-human identities don’t follow this lifecycle. A developer creates a service account to solve an immediate problem, such as a script that needs database access, a pipeline that needs to push to a container registry, or a third-party integration that needs an API key. That credential gets scoped broadly because least privilege takes longer to configure. It works, so it stays.

But this leads to several notable problems:

• No one documents it in an enterprise inventory. 
• No one assigns an owner responsible for rotation or review. 
• No offboarding process fires when the project winds down, or the developer who created it leaves the company.

This leads to identity sprawl at a scale that manual governance cannot touch. Nearly half of all active NHIs are over a year old, and 7.5% have been active for five to ten years, long outliving the humans who created them. These stale credentials sit with standing privileges, active around the clock, and invisible to the access reviews designed for people.

Where Non-Human Credential Risks Hide Across the SDLC

Credential exposure follows the code. Every stage of the software development lifecycle introduces its own flavor of NHI risk, and attackers have learned to target each one.

[Visual placement: Risk Map showing the four SDLC stages (Code, Build/CI, Deploy/Container, Runtime) with dominant credential types and risk at each stage.]

Source Code Repositories

Hardcoded secrets remain the single largest source of credential exposure, accounting for 57% of all detections. 

Developers embed API keys, connection strings, or private keys in code during testing and forget to remove them. Once committed to Git, those credentials persist in the immutable commit history even after deletion in a later commit. 

In 2025, over 28.65 million new hardcoded secrets were added to public GitHub repositories alone. Private repos are worse, as they are eight times more likely to contain secrets than public ones, because developers assume restricted access eliminates the risk. Effective secrets detection at the repo level is the first line of defense.

CI/CD Pipelines

Pipelines require high-privilege credentials to build, test, and deploy across environments. Those tokens are often stored as plaintext environment variables or accidentally printed in build logs. 

The March 2025 supply chain attack on the tj-actions/changed-files GitHub Action demonstrated how dangerous this is. Attackers compromised a maintainer’s personal access token and pushed a malicious commit that scraped runner memory for active secrets, exposing credentials from over 23,000 repositories. Any organization relying on mutable automation dependencies faces a similar software supply chain security risk.

Container Images

Docker builds create a hidden persistence problem. When developers pass credentials using ENV or ARG instructions, those values get embedded permanently in the image’s metadata and layers. 

Deleting the secret in a later Dockerfile step only removes it from the final layer. The earlier cached layer still contains the credential, and anyone with pull access can extract it using standard tooling. 

Multi-stage builds, where secrets are confined to an intermediate stage and never copied to the production image, are the reliable fix.

Cloud Runtime Environments

At runtime, NHI risk concentrates around overprivileged workload identities and cloud metadata services. 

The Instance Metadata Service (IMDS) provides temporary credentials to applications running on cloud instances. If an application has a server-side request forgery (SSRF) vulnerability, an attacker can query IMDSv1’s unauthenticated endpoint and steal the IAM role credentials attached to that workload. 

IMDSv2 mitigates this by requiring session-based token authentication, but many organizations still run IMDSv1 for backward compatibility.

How to Build a Non-Human Identity Security Program

Treating NHI risk as a series of one-off fixes, rotating a key here, revoking a token there, does not scale. 

A structured program connects discovery, classification, enforcement, and monitoring into a continuous loop across the SDLC. This includes:

• Discover and inventory at scale: You cannot enforce policies on identities you haven’t found. Integrate scanning across repos, CI/CD pipelines, secrets vaults, container registries, and cloud providers to build a unified view of every machine credential in your environment. Application security posture management platforms serve as the orchestration layer here, correlating findings from code analysis with runtime data to trace each credential back to its origin, its current usage, and its blast radius.
• Classify and assign ownership: Every NHI needs a human owner, a specific person accountable for its lifecycle, not a shared team alias. Document the business justification for each identity and classify by blast radius: credentials with access to PII, payment data, or the cloud control plane get priority.
• Eliminate standing privileges: Long-lived, always-on credentials are the highest-value target for attackers. Move toward just-in-time provisioning, where machine identities receive short-lived tokens that expire after a task completes. Workload identity federation using OIDC or SPIFFE/SPIRE replaces static API keys with cryptographically verified, runtime-bound identities that never need to be stored.
• Separate secrets management from identity governance: Vaulting tools like HashiCorp Vault and AWS Secrets Manager protect the credential value. That is necessary. But a secret can be stored perfectly and still be assigned to an overprivileged identity with no owner and no access review. Non-human identity security governs the identity itself: its permissions, its behavior over time, and its decommissioning when the business justification ends.
• Monitor behavior and decommission aggressively: Establish behavioral baselines for each machine identity and alert on deviations: unusual access patterns, privilege escalation attempts, or usage of credentials flagged as stale. Automate decommissioning triggers for any NHI inactive for 90 days. If the owner cannot justify its continued existence within 30 days, disable it.

Govern the Identity Behind the Secret

NHI credential risk is an identity governance problem that spans every stage of the SDLC.

The credentials are the artifacts. The real exposure comes from ungoverned identities with no owner, expiration, access review, or permissions that no one has re-evaluated since the day they were created.

Teams that focus only on vaulting will keep chasing leaked secrets one at a time. Teams that govern the identity lifecycle, connected to the full application architecture from code to runtime, will close the gap at its source.

Apiiro’s Software Graph and code-to-runtime visibility give AppSec teams the architectural context to discover, classify, and prioritize non-human identity risk across the entire SDLC. Instead of treating every leaked credential as equally urgent, teams can focus on the identities that access sensitive data, run in internet-exposed workloads, and carry standing privileges with real business impact.

Map your non-human identity risk with full architectural context. Schedule a demo to see how Apiiro connects credential findings to the software architecture that gives them meaning.

FAQs

What is a non-human identity in the context of software security?

A non-human identity is any credential assigned to a software component, service, or automated process that authenticates and accesses resources without direct human involvement. Common examples include service accounts, API keys, OAuth tokens, certificates, and CI/CD pipeline tokens. They enable machine-to-machine communication across every stage of the SDLC.

What are the most common non-human identity risks in the SDLC?

The most common risks are hardcoded secrets in source code repositories, overprivileged tokens in CI/CD pipelines, credentials cached in container image layers, and unmonitored workload identities in cloud runtime environments. These credentials often have no owner, no expiration, and excessive permissions that accumulate over time without review.

How do attackers typically exploit non-human credentials?

Attackers mine Git commit histories for hardcoded secrets, scrape CI/CD runner memory for active tokens, extract credentials from Docker image layers, and exploit SSRF vulnerabilities to query cloud metadata services for IAM role credentials. Compromised OAuth tokens also enable lateral movement across connected SaaS applications.

What is the difference between secrets management and non-human identity security?

Secrets management protects the credential value through vaulting, encryption, and rotation. Non-human identity security governs the identity itself: who owns it, what permissions it holds, whether its behavior is normal, and when it should be decommissioned. Both are necessary. A perfectly vaulted secret assigned to an overprivileged, ownerless identity is still a risk.

How can AppSec teams discover and inventory non-human identities at scale?

Teams need automated scanning across code repositories, CI/CD configurations, secrets vaults, container registries, and cloud provider IAM systems. ASPM platforms consolidate these findings into a unified inventory, correlate each credential with its runtime context and code origin, and prioritize based on blast radius and actual exposure.