Reducing NHI risk without breaking core infrastructure

At a glance

What this is: This article argues that NHI risk can be reduced without breaking core systems by applying deny-based quarantine instead of deleting or modifying credentials.

Why it matters: It matters because IAM and PAM teams need a way to reduce standing NHI exposure without disrupting the applications, pipelines, and workflows those identities support.

By the numbers:

• The ratio of NHIs to humans has jumped to 45:1.

Context

Non-human identity governance breaks down when teams treat revocation as the only safe response to excess privilege. In practice, service accounts, API tokens, and CI/CD integrations are often wired into production paths tightly enough that a blunt permission change can interrupt deployments or customer-facing services.

This is an NHI lifecycle problem as much as an access-control problem. Many NHIs are created ad hoc, granted elevated access for convenience, and then left outside normal lifecycle processes, which leaves security teams with dormant identities, unclear ownership, and no reliable view of actual usage.

The article’s central point is that risk reduction and service continuity do not have to be mutually exclusive. The challenge is to distinguish between removing dangerous access and preserving the identity object that dependent systems still expect to exist.

Key questions

Q: What breaks when organisations remove NHI access without understanding dependencies?

A: Service accounts, automation tokens, and CI/CD integrations can fail immediately when permissions are removed without mapping downstream dependencies. The practical risk is not just outage, but the incentive to leave overprivileged identities untouched because teams fear service disruption more than excess access.

Q: Why do service accounts and API tokens make application exploits worse?

A: Service accounts and API tokens extend a host compromise into other systems because they carry machine authority beyond the vulnerable process. If those identities are overprivileged or long-lived, the attacker can pivot from code execution to persistence, data access, or cloud control. NHI governance is therefore part of incident containment.

Q: How should security teams reduce NHI risk without breaking production systems?

A: Start by identifying which machine identities are actually embedded in live workflows, then apply the least disruptive control that reduces exposure. Deny-based quarantine is useful when you need immediate containment but cannot yet prove an identity is safe to remove. The key is to tie remediation to dependency evidence, not just privilege level.

Q: What is the difference between quarantine and revocation for non-human identities?

A: Quarantine blocks access while keeping the identity object and underlying infrastructure intact, so it is reversible and less disruptive. Revocation removes the permission path entirely, which is safer only when the dependency impact is known and the identity is no longer operationally required.

Technical breakdown

Why revocation can break NHI-dependent systems

Non-human identities often sit on the execution path of infrastructure, data movement, and automated workflows. If a service account or token is removed outright, the dependent process may fail immediately because the identity is not just authorized, it is operationally embedded. That makes revocation a high-friction control when ownership is unclear or when the identity was created for convenience and never revisited. The result is a governance deadlock: teams know the access is too broad, but they fear the side effects of changing it. Practical implication: treat NHI access changes as dependency-sensitive operations, not simple entitlement edits.

Practical implication: Map the systems that depend on each NHI before changing its access scope.

How deny-based quarantine changes the control model

A deny-based quarantine leaves the identity in place but blocks its access at the authorization layer. That matters because it separates risk reduction from identity destruction: the platform can suppress use without altering the underlying infrastructure or forcing immediate code changes. In governance terms, this is closer to controlled containment than cleanup. It also creates a reversible state, which is useful when a dormant identity later turns out to be business-critical. Practical implication: use quarantine as an intermediate control when you need to cut exposure without triggering outage risk.

Practical implication: Apply deny-based containment first when the blast radius of full revocation is unknown.

Why visibility is the prerequisite for NHI remediation

The article ties remediation to discovery, risk prioritisation, and ongoing reassessment. That sequence matters because teams cannot safely quarantine or tighten access if they do not know which identities exist, who owns them, what they touch, or whether they are still in use. The underlying problem is not simply too much access. It is unmanaged identity inventory combined with weak lifecycle oversight. Practical implication: remediation should begin with inventory and usage context, then move to targeted containment rather than mass removal.

Practical implication: Build an inventory baseline before trying to reduce NHI privilege or exposure.

Breaches seen in the wild

• Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

NHI blast-radius control is becoming more important than access removal. The article shows that the real operational constraint is not whether a risky identity should lose access, but whether a control can reduce exposure without breaking production dependencies. That shifts governance from a revocation-first mindset to one that recognises dependency-aware containment as a legitimate state. For practitioners, the key question is how to reduce blast radius without forcing infrastructure change.

Ad hoc NHI creation has outgrown lifecycle models built for human identity. The article describes NHIs that are created quickly, granted convenience access, and then fall outside normal lifecycle processes. That is a structural governance gap, not a minor hygiene issue, because unmanaged identities do not naturally pass through ownership, review, or retirement checkpoints. Practitioners should treat NHI lifecycle coverage as incomplete until machine identities are inventoried and governed alongside human access.

Quarantine is best understood as an identity governance state, not a workaround. A deny policy that blocks access while preserving the identity object gives security teams a reversible control surface for dormant or overprivileged NHIs. That is materially different from deletion, because it acknowledges that service continuity and access reduction often have to be staged. The implication is that remediation programmes need a graduated response model for machine identities.

Governed non-human identity inventory: The article makes clear that teams cannot reduce NHI risk if they do not know what exists, who owns it, and where it is used. Visibility is not an administrative nicety here; it is the prerequisite for deciding whether quarantine, scope reduction, or revocation is safe. Practitioners should treat inventory quality as the first control gate in NHI governance.

Mismanaged NHI visibility converts security work into outage avoidance. When teams cannot distinguish active from dormant identities, every access change looks like a potential incident. That incentives inaction and leaves privileged NHIs untouched even when they are unnecessary or overexposed. The practical conclusion is that governance must make change safer than stasis.

From our research library:

• 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Governed NHI quarantine changes the remediation sequence. The main shift is that access reduction no longer has to wait for full confidence about downstream dependencies. That gives teams a way to act on high-risk machine identities without turning every cleanup into a potential outage.

NHI visibility is the control before the control. If an organisation cannot identify service accounts, tokens, and pipeline identities consistently, it will continue to over-rely on caution instead of governance. Discovery, ownership, and usage context have to be reliable before privilege reduction becomes operationally safe.

For practitioners

• Build a complete NHI inventory Discover service accounts, API tokens, CI/CD integrations, and other machine credentials across cloud, infrastructure, and SaaS environments. Record ownership, privilege scope, and last-use context so each identity can be evaluated without guesswork.
• Quarantine before revoking access Use deny policies to block risky or dormant NHIs first when their downstream dependencies are unclear. Preserve the identity object while you validate whether a service still requires it.
• Prioritise high-blast-radius identities Focus first on privileged NHIs, dormant identities, and accounts that span multiple environments. These identities create the largest exposure if they are abused or left unmanaged.
• Add periodic reassessment to NHI governance Review quarantined and low-activity identities on a recurring basis, then tighten scope further where usage data supports it. Make reassessment part of the normal lifecycle, not a one-time cleanup.

Key takeaways

• NHI risk management fails when teams assume revocation is the only safe response to excess privilege, because many machine identities are embedded in production workflows.
• The article links this problem to scale and visibility gaps, including a 45:1 ratio of NHIs to humans and a common lack of lifecycle coverage for machine identities.
• A deny-based quarantine model can reduce exposure while preserving service continuity, but it depends on discovery, ownership, and usage context before action.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• NHI Quarantine: NHI quarantine is a containment state that blocks a machine identity’s access without deleting the identity object or changing dependent infrastructure. It lets teams reduce risk reversibly when full revocation could interrupt business processes or automated services.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Identity Lifecycle Event: A business event that changes a person’s access, obligations, or record status, such as hiring, role change, or offboarding. In HR programmes, these events often drive entitlement changes and evidence requirements, so they need to be governed as part of the identity lifecycle rather than handled as isolated paperwork.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.