Top 10 Non-Human Identity Risks

Non-human identities (NHIs) now outnumber human identities in enterprise environments by approximately 144 to 1, and most were provisioned quickly and never formally governed. An attacker no longer needs to phish an employee: they find an API key your software left in a repository, a service account with no owner and admin-level permissions, or a credential that was supposed to be rotated eighteen months ago. The recommended action: audit and revoke orphaned NHIs immediately, move secrets out of source code into a vault, implement short-lived credential rotation for high-risk accounts, scope all NHI permissions to least privilege, and put certificates under automated lifecycle management.

Quick Answer: What Are the Top Non-Human Identity Risks?

OWASP’s 2025 Non-Human Identities Top 10 identifies ten categories in order of impact. Most trace back to three root problems: secrets that live too long, identities with too much access, and identities nobody cleans up. The top five by immediate impact are: Improper Offboarding (91% of former-employee tokens remain active), Secret Leakage (44% of tokens are found exposed in repos and chat tools), Overprivileged NHI (97% of NHIs carry excessive privileges), Long-Lived Secrets (no expiry means unlimited attacker window), and Insecure Cloud Deployment Configurations (static pipeline credentials that can reach production). For an overview of the broader NHI landscape and why machine identities are multiplying, see our companion post on The Non-Human Identity Explosion.

Why NHIs Accumulate Faster Than Governance Can Track

The numbers above did not accumulate by accident. Cloud-native architectures break applications into microservices that each need their own identity. Automation creates credentials programmatically at pipeline speed. AI agents are the newest category: each agent requires its own credential, and they are being deployed by the millions. The result is that machines now create identities at software speed while organizations still manage them at human speed. Each of the ten risks below is a consequence of that gap. Understanding the root cause prevents the instinct of treating the ten items as ten independent problems requiring ten separate tools. They do not. They require a few habits applied consistently across the entire NHI lifecycle.

Risk Prioritization: Where to Start

OWASP NHI Risk	Root cause	Typical prevalence	First action
1. Improper Offboarding	Credentials not retired	91% of former-employee tokens still active	Assign owners to all NHIs; tie decommissioning to application lifecycle
2. Secret Leakage	Secrets in wrong location	44% of tokens found in repos, tickets, chat	Secret scanning in CI/CD; move secrets to vault; rotate exposed credentials
3. Vulnerable Third-Party NHI	External access not governed	Every third-party integration has an NHI	Inventory all third-party integrations; scope to minimum; revoke unused
4. Insecure Authentication	Weak or legacy auth mechanisms	Legacy shared secrets still common in brownfield environments	Replace with OAuth, mTLS, or short-lived certificate-based authentication
5. Overprivileged NHI	Excess permissions never reviewed	97% of NHIs have excessive privileges	Scope every NHI to minimum required; periodic access review for machine accounts
6. Insecure Cloud Deployment Configs	Static credentials in pipelines	Static credentials common in CI/CD pipelines	Replace with OIDC workload identity federation; validate token claims
7. Long-Lived Secrets	No rotation policy enforced	Default for most static API keys and tokens	Implement automated rotation; switch to short-lived credentials where possible
8. Environment Isolation	Credential reuse across environments	Test-to-production credential sharing common	Separate credentials per environment; never share prod credentials with test
9. NHI Reuse	One credential for multiple services	Common in monolithic or early-stage environments	One dedicated credential per workload; independent rotation and revocation
10. Human Use of NHI	Service accounts used for manual tasks	Common in operations and maintenance workflows	Separate human accounts for manual work; monitor and alert on human NHI use

A Closer Look at Each Risk

1. Improper Offboarding

An orphaned NHI is a credential still active but no longer needed: the project wrapped up, the service was retired, or the person who created it left. Research found that 91% of former-employee tokens remained active. Attackers target orphaned NHIs because no one monitors them, no baseline behavior exists to trigger anomaly alerts, and they often retain the broad permissions granted at creation. The fix is to make decommissioning automatic. Retiring a service should revoke its credentials as part of the same workflow, not as a separate manual step. Every NHI needs a named owner; periodic cleanup scans should flag NHIs with no recent usage or no current owner for immediate revocation.

2. Secret Leakage

A secret leaks when a token, key, or certificate ends up somewhere it should not: in source code, configuration files, log output, chat messages, or support tickets. One study found 44% of tokens were exposed in locations like code commits, tickets, and chat tools. No sophisticated exploit is required. Whoever finds the secret can use it immediately. Controls include secret scanning in CI/CD pipelines on every commit, storing all secrets in a dedicated vault or secrets manager rather than configuration files, and rotating any secret that may have been exposed. The permanent fix is to eliminate long-lived secrets entirely, replacing them with dynamically provisioned short-lived credentials.

3. Vulnerable Third-Party NHI

Every SaaS integration, IDE extension, or third-party tool that connects to your environment gets its own NHI with access to your systems. A vulnerability in the third party’s software or a breach of the third party’s infrastructure becomes your breach if their NHI has persistent, broad access to your environment. This is how many supply chain attacks begin: attackers compromise a vendor’s credential that grants access to hundreds of customer environments. You cannot fix third-party code, but you can control the access it has: maintain an inventory of all third-party integrations, regularly verify the scope of each, remove integrations no longer in use, and apply least privilege to every third-party NHI grant.

4. Insecure Authentication

Every NHI must authenticate to the service it connects to. Many applications still rely on weak or outdated mechanisms: legacy shared secrets, static passwords, or deprecated protocols that are easy to intercept or replay. When the authentication mechanism is weak, an attacker can impersonate the identity or escalate its privileges without detection. The remediation is to replace legacy methods with standards-based modern authentication: OAuth 2.0 with short-lived tokens, mutual TLS (mTLS) with certificate-based machine authentication, or short-lived certificate-based identities using SPIFFE/SPIRE. None of these transmit a persistent shared secret over the network in a way an attacker can capture and replay.

5. Overprivileged NHI

Overprivilege is the most pervasive NHI risk: studies show 97% of NHIs carry excessive privileges. It occurs because granting broad access is the fastest way to make something work, and nobody returns to tighten permissions later. The consequence is that privilege determines blast radius: a tightly scoped NHI that is compromised causes minimal damage; an overprivileged one gives the attacker the same reach as a privileged administrator. Apply the principle of least privilege by scoping each NHI to only the specific resources and operations its function requires. Conduct periodic access reviews for machine accounts with the same rigor applied to privileged human accounts.

6. Insecure Cloud Deployment Configurations

CI/CD pipelines need access to cloud environments to build, test, and deploy. The risk appears when this access uses static credentials stored in environment variables or configuration files, which can leak through repositories, build logs, or misconfigured artifact stores. A compromised pipeline credential grants persistent, privileged access to production. The better pattern is to eliminate static credentials entirely using OpenID Connect (OIDC) workload identity federation: the pipeline authenticates using its verified identity to obtain a short-lived, scoped token for each run. No standing secret exists to steal. Validate OIDC token claims carefully so only the specific workload you intend can obtain elevated access.

7. Long-Lived Secrets

A long-lived secret is a credential that rarely or never expires. Teams create them because rotating credentials manually is burdensome, so they set a key once and defer rotation indefinitely. The risk: once stolen, a non-expiring credential gives the attacker unlimited time to exploit it. A key that leaked in a repository two years ago may still be valid today. The fix is to make secrets short-lived by design. Instead of static keys, use credentials generated on demand that expire in minutes or hours: cloud workload identity, SPIFFE/SPIRE, or certificate lifecycle automation for machine-to-machine connections. The shorter the lifetime, the smaller the attack window.

8. Environment Isolation

Development, testing, and production environments should use completely separate credentials. Environment isolation failures occur when the same identity is reused across environments, particularly between test (the least protected) and production (the highest value). A compromise in the test environment that shares an identity with production extends directly into production without any additional attacker effort. The control is strict separation: provision separate credentials for each environment, store them independently, and technically enforce that test credentials cannot authenticate to production systems.

9. NHI Reuse

NHI reuse happens when the same identity or secret is shared across different applications, services, or components, typically because creating a separate identity per workload takes effort. The risk is blast radius: if the shared identity is compromised anywhere, the attacker can access every system trusting it. A single token shared between a development tool, a production API, and a batch processing service means stealing it from any one grants access to all three. Give each workload its own dedicated identity and secret, rotate them independently, and track which identity belongs to which application. Independent identities also simplify revocation: removing one service’s access does not disrupt the others.

10. Human Use of NHI

Human Use of NHI occurs when a person uses a non-human credential (service account, API token) to perform manual tasks that should run under their own account. It is common because service accounts are pre-configured with broad access that is convenient for maintenance work. The problem is attribution: most platforms cannot distinguish whether the NHI was used by an automated process or a human, so the audit log shows the service account, not the person. This prevents accountability when something goes wrong, enables privilege escalation, and complicates compliance reviews requiring individual attribution (PCI DSS Requirement 8, HIPAA). The fix is separate accounts for humans and machines, with context-aware access controls that flag or block interactive human sessions using NHI credentials.

The Pattern: Three Root Causes, Not Ten Separate Problems

Reviewing all ten risks reveals that they are not ten independent problems. They are the same three habits appearing in different forms:

• Secrets that live too long: Long-Lived Secrets (7), Secret Leakage (2), and Insecure Authentication (4) all involve credentials that persist longer than they should or are stored where they should not be.
• Identities with too much access: Overprivileged NHI (5), NHI Reuse (9), Environment Isolation (8), and Insecure Cloud Deployment Configurations (6) all result in a single compromised credential providing wider access than the attacker should ever have.
• Identities nobody cleans up: Improper Offboarding (1), Vulnerable Third-Party NHI (3), and Human Use of NHI (10) all produce unmanaged or mismanaged identities that accumulate in the environment and are exploited precisely because no one is watching them.

You do not need ten separate tools or ten separate workstreams. You need three habits applied consistently across the entire NHI lifecycle: short-lived credentials, minimum privilege, and clean decommissioning.

Deployment Example: Addressing the OWASP NHI Top 10 in an Enterprise Environment

A 2,000-employee organization running cloud-native workloads on AWS and Azure with 80+ SaaS integrations implements the following NHI risk reduction program over 90 days:

1. Discovery (Week 1-2): a continuous NHI discovery scan across AWS IAM, Azure Active Directory, GitHub, and all registered SaaS integrations produces an inventory of 47,000 NHIs. 12,000 have no current owner in Active Directory, flagging them as orphaned candidates. All 12,000 are reviewed and the confirmed orphans are revoked immediately (addresses Risk 1: Improper Offboarding).
2. Secret scanning deployment (Week 2-3): secret scanning is added to all CI/CD pipelines, blocking commits containing API keys, tokens, or private keys. Scanning of the git repository history identifies 340 historically exposed credentials; all 340 are rotated immediately (addresses Risk 2: Secret Leakage).
3. Third-party integration audit (Week 3-4): all 80+ SaaS integration NHIs are reviewed. 23 integrations are found to have scopes exceeding what they actively use; scopes are reduced. 11 integrations from tools no longer in use are revoked entirely (addresses Risk 3: Vulnerable Third-Party NHI).
4. Pipeline credential migration (Month 2): all CI/CD pipelines are migrated from static AWS access keys to OIDC workload identity federation. Pipelines now obtain short-lived session tokens per build run; no standing credentials exist in the pipeline (addresses Risks 6 and 7).
5. Certificate automation deployment (Month 2-3): automated certificate lifecycle management is deployed across all 3,200 TLS certificates in the environment. All certificates are renewed automatically before expiry; the inventory is updated continuously as new certificates are issued (addresses Risk 7 as it applies to certificates, and positions the organization for the 47-day certificate lifetime requirement in 2029).
6. Least-privilege remediation (Month 3): a machine identity access review reduces permissions on the 35,000 remaining NHIs. Service accounts previously holding AdministratorAccess or equivalent are scoped to specific resource-level permissions. Separate credentials are provisioned for development, testing, and production environments where cross-environment reuse was found (addresses Risks 5, 8, and 9).

How Encryption Consulting Can Help

The fastest single action that closes multiple OWASP NHI risks simultaneously is bringing your certificates under automated management. Certificates appear in Risks 2 (Secret Leakage, when certificates or private keys are exposed), 7 (Long-Lived Secrets, when certificates are not rotated before the CA/Browser Forum’s 47-day maximum applies), and 1 (Improper Offboarding, when expired or orphaned certificates remain in the environment). Our CertSecure Manager addresses all three: continuous discovery of all certificates across cloud, on-premises, and hybrid infrastructure; centralized inventory with named owner assignment; zero-touch automated renewal that scales to 47-day certificate lifetimes without increasing operational burden; and full audit trails for compliance evidence.

For the full NHI governance picture beyond certificates, including service account lifecycle, API key management, AI agent credential governance, and encryption strategy, our Encryption Advisory Services provide an independent assessment of where you stand across the OWASP NHI Top 10 and a prioritized remediation roadmap.

Conclusion

The OWASP NHI Top 10 gives security teams a clear prioritization framework for where to invest. But the list is not ten discrete problems: it is three root habits showing up in ten different forms. Address secrets that live too long, identities with too much access, and identities nobody cleans up, and you resolve the majority of NHI risk without attempting to manage each item separately.

A practical starting point: audit and revoke orphaned NHIs immediately (closes the easiest gap), move secrets out of source code into a vault, implement short-lived credential rotation for the highest-risk accounts, and bring certificates under automated lifecycle management (the single highest-leverage action for most organizations, since certificates span multiple risk categories and are already present at scale in every enterprise). If you want expert guidance on assessing and closing NHI risk, contact Encryption Consulting.

Frequently Asked Questions

What is the OWASP Non-Human Identities Top 10?

OWASP’s 2025 framework ranking the ten most critical NHI risk categories in order of impact. NHIs include API keys, OAuth tokens, service accounts, TLS certificates, SSH keys, cloud IAM roles, and AI agent identities. The number one risk is Improper Offboarding (orphaned credentials), followed by Secret Leakage, Vulnerable Third-Party NHI, Insecure Authentication, Overprivileged NHI, Insecure Cloud Deployment Configurations, Long-Lived Secrets, Environment Isolation, NHI Reuse, and Human Use of NHI.

What is the biggest NHI risk and how do you address it?

Improper Offboarding (orphaned credentials). 91% of former-employee tokens remain active after departure. Orphaned NHIs have no monitoring, no behavioral baseline for anomaly detection, and often carry broad permissions. Remediation: make decommissioning automatic by linking NHI lifecycle to service or application lifecycle; assign every NHI a named owner; run periodic cleanup scans to revoke NHIs with no usage or owner.

What are long-lived secrets and why are they dangerous?

Credentials (API keys, tokens, certificates) that rarely or never expire. They accumulate because rotation is burdensome. Once stolen, they give the attacker unlimited time to exploit them. Fix: replace with dynamically provisioned short-lived credentials (SPIFFE/SPIRE, OIDC workload identity, automated certificate lifecycle management). The shorter the lifetime, the smaller the attack window.

How does NHI reuse increase breach blast radius?

When the same identity or secret is shared across services, a compromise in one grants access to all. Fix: one dedicated credential per workload; rotate independently; revoke per-service without disrupting others. Track which identity belongs to which application in a central inventory.

What is Human Use of NHI and why is it an audit problem?

When a person uses a service account or machine token for manual work, the audit log shows the NHI, not the person. This prevents attribution, enables privilege escalation, and complicates compliance requirements for individual accountability (PCI DSS Requirement 8, HIPAA). Fix: separate human and machine accounts; monitor and alert on interactive human sessions using NHI credentials.

What should organizations tackle first from the OWASP NHI Top 10?

Revoke orphaned NHIs immediately (easiest gap to close). Then move secrets out of source code into a vault. Then implement short-lived credential rotation for high-risk accounts. Then scope permissions to least privilege. Then bring certificates under automated lifecycle management, the highest-leverage single action since certificates span multiple risk categories and are already present at scale.