Top seven NHI risks are exposing enterprise access controls

At a glance

What this is: This is a practitioner-focused overview of the seven most common NHI risks and the controls used to reduce them.

Why it matters: It matters because the same governance failures that weaken NHI programmes also create spillover risk for IAM, PAM and lifecycle management across human and machine identities.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone.

👉 Read Keeper Security's blog on the top seven NHI risks and mitigations

Context

Non-Human Identity risk is no longer a narrow secrets-management problem. It is the control plane for machine access, because service accounts, API keys, tokens and certificates now sit inside almost every deployment path, integration flow and automated process.

When NHIs are overprivileged, forgotten after offboarding, or left with long-lived credentials, the issue is not just exposure. The issue is governance drift across the lifecycle, where access persists longer than the business need that justified it.

That pattern is typical in modern enterprise environments, not an edge case, which is why NHI security now touches IAM, PAM, IGA, DevOps and cloud operations at the same time.

Key questions

Q: What breaks when NHI credentials are overprivileged?

A: Overprivileged NHI credentials turn a single compromise into a larger access problem. Once attackers obtain the secret, they can often move laterally, reach higher-value systems and escalate privileges because the identity already carries more access than the task requires. The result is a wider blast radius and slower containment.

Q: Why do long-lived secrets increase enterprise risk?

A: Long-lived secrets increase risk because they remain usable long after exposure. If a key, token or certificate is stolen, the attacker can keep returning until the credential expires or is revoked. That persistence makes detection less useful unless rotation and expiration are enforced automatically.

Q: How can security teams tell whether NHI governance is working?

A: They should look for fewer orphaned accounts, shorter credential lifetimes, lower secret reuse and faster decommissioning when systems or projects end. If credentials still survive after business purpose has ended, the governance model is not controlling the lifecycle effectively.

Q: Who should own offboarding for service accounts and API keys?

A: Ownership should sit with the system or application team that depends on the identity, but decommissioning needs governance from IAM, PAM or IGA so removal is not optional. A good model ties offboarding to retirement events, project closure and periodic review.

Technical breakdown

Overprivileged NHIs and lateral movement

An overprivileged NHI has more permissions than the task requires, which expands the blast radius of any credential compromise. In practice, this turns a single exposed API key or token into a path for lateral movement, privilege escalation and access to higher-value systems. Least privilege is the governing principle here, but it only works when entitlements are scoped to the actual task and periodically revalidated. RBAC can help with structure, while JIT access reduces the time window in which excess privilege can be abused.

Practical implication: map every NHI to a minimal permission set and remove standing privilege where task-scoped access is sufficient.

Secret leakage, hardcoded credentials and secrets sprawl

Secret leakage happens when credentials are embedded in code, configuration files, build systems or collaboration tools instead of being centrally managed. Once secrets spread across repositories and pipelines, the organisation loses visibility into where they live and who can use them. That creates secrets sprawl, where one leaked token often implies multiple compromised paths. A secrets manager reduces this risk only when paired with code scanning, policy enforcement and automated rotation; storage alone does not solve exposure.

Practical implication: scan source, CI/CD and collaboration systems for embedded credentials and enforce automated rotation for anything exposed.

Improper offboarding and orphaned service accounts

Improper offboarding is the failure to deactivate an NHI when a project ends, a system is retired or the owning team changes. Orphaned service accounts and API keys often keep the same access they had on day one, even though the operational need has disappeared. That creates hidden access paths that are hard to detect during audits because they look legitimate on paper. Lifecycle governance has to cover creation, active use, review and decommissioning as one continuous process, not as separate events.

Practical implication: connect NHI offboarding to asset retirement, project closure and identity review workflows so unused accounts are actually removed.

Threat narrative

Attacker objective: The attacker wants durable access to enterprise systems and data using machine credentials that are easier to hide and reuse than interactive accounts.

1. entry: The attacker gains entry through an exposed or leaked NHI credential such as an API key, token or certificate.
2. escalation: The compromised NHI is then used to reach additional systems because it already carries excessive or standing privilege.
3. impact: The attacker moves laterally, accesses sensitive data or persists through long-lived credentials that remain valid after discovery.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Overprivilege is still the most expensive NHI governance mistake. The article correctly treats excess access as a blast-radius problem, not just a policy issue. Once an NHI credential is compromised, standing privilege turns a narrow authentication event into a lateral-movement opportunity across systems, data stores and deployment tooling. The practical conclusion is that entitlement scope, not only secret strength, determines whether the compromise stays local or becomes enterprise-wide.

Improper offboarding is really lifecycle failure, not admin negligence. NHIs do not retire themselves, and service accounts are often forgotten because they are embedded in pipelines and integrations rather than owned like human users. That makes lifecycle governance the control that determines whether access ends when business purpose ends. The implication is that organisations need a single offboarding model that covers creation, active use, review and decommissioning for machine identities.

Long-lived secrets create identity persistence that security teams underestimate. A credential with no expiration date behaves like an always-open door once exposed. This is why ephemeral access and automated expiry matter: they limit how long stolen machine identity can remain useful. Practitioners should treat secret lifetime as a core risk variable, not an implementation detail.

Secret sprawl is a control-plane problem, not a code-quality problem. Hardcoded credentials in scripts, repositories and configuration files mean the organisation has lost track of where machine identity lives. That makes discovery, rotation and revocation much harder than policy documents suggest. The practical conclusion is that NHI governance must extend across DevOps, cloud and collaboration tooling, not stop at the vault.

Policy-based access only works when it is tied to continuous identity review. RBAC and JIT reduce exposure, but they do not help if access is never reviewed or if the underlying NHI is never decommissioned. The field should treat NHI governance as a lifecycle discipline with access, ownership and expiry all bound together.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, which shows how quickly secret exposure continues to scale across development workflows.
• Track machine identity leakage alongside lifecycle controls in the Guide to the Secret Sprawl Challenge so secret discovery and revocation are treated as one control problem.

What this signals

Secret age is becoming a better governance metric than secret count. If a leaked credential can still be used months or years later, the real programme failure is not discovery but revocation latency. Teams should watch how fast exposed identities are invalidated across cloud, CI/CD and collaboration tools, because that is where actual containment happens.

With 28,65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, secret sprawl is no longer a niche DevOps hygiene issue. It is a structural identity problem that forces IAM, PAM and engineering teams to share ownership of machine access.

NHI programmes that still rely on periodic review alone will continue to miss the fastest path to compromise. The next maturity step is continuous lifecycle control, where creation, usage, expiry and offboarding are bound to the same operational workflow.

For practitioners

• Inventory every machine identity Create a complete register of service accounts, API keys, tokens and certificates across cloud, CI/CD and application estates, then assign an owner and expiry condition to each one.
• Eliminate hardcoded credentials Scan repositories, scripts and config stores for embedded secrets and block deployment when a secret is detected outside the approved secrets manager.
• Convert standing privilege to task-scoped access Use RBAC and JIT to limit machine access to the minimum permissions required for the task, then revoke access automatically when the task completes.
• Automate NHI offboarding and expiry Tie deactivation of service accounts and tokens to project closure, application retirement and pipeline teardown so orphaned credentials cannot remain active.
• Measure secret age and reuse risk Track how long credentials remain valid, how often they are rotated and where they are reused so stale secrets can be prioritised for replacement.

Key takeaways

• Overprivileged, long-lived and orphaned NHIs create the largest practical blast radius in enterprise identity programmes.
• The evidence points to a persistent exposure problem, with leaked machine secrets remaining usable long after they are discovered.
• Practitioners should prioritise inventory, rotation, offboarding and task-scoped access as one lifecycle control model, not four separate fixes.

Key terms

• Non-Human Identity: A Non-Human Identity is any credentialed identity used by software, infrastructure or automation rather than a person. It includes service accounts, API keys, tokens, certificates and workload identities. In practice, these identities need ownership, expiry and review just like human accounts, but at machine speed.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, chat, configuration files and cloud systems. The problem is not only exposure but also fragmentation, because the organisation loses track of where a secret exists, who can use it and how quickly it can be revoked.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. For NHIs, standing privilege is especially dangerous because machine credentials are often reused automatically and without interactive warning, which makes any compromise easier to weaponise at scale.
• Just-in-Time Access: Just-in-Time access is a model where permission is issued only for the duration of a specific task and then removed. For non-human identities, it reduces the time a stolen credential can be used and creates a clearer audit trail than permanent access models.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keeper Security: Top 7 NHI Risks and How To Mitigate Them. Read the original.