TL;DR: Non-human identities now outnumber human users by 45:1, and Token Security argues that remediation is the hardest NHI security problem because revoking credentials or changing permissions can break workloads, deployments, and pipelines, according to Token Security. The real governance gap is not discovery but trusted remediation that preserves operational continuity.
At a glance
What this is: This is a blog analysis arguing that NHI remediation is harder than discovery because fixing service-account and workload access can disrupt production systems.
Why it matters: IAM, PAM, and NHI teams need to treat safe remediation as an operational control problem, not just a hygiene task, because broken workloads create paralysis that attackers can exploit.
By the numbers:
- Non-human identities now outnumber human users by 45:1 in the modern enterprise.
Context
Non-human identity remediation is the control point where visibility turns into operational risk. In environments built on service accounts, workloads, and CI/CD pipelines, the issue is not whether an access problem exists, but whether a team can change it without taking down the dependent system.
The article argues that traditional IAM, PAM, and IGA models were built for human access patterns and do not reliably explain downstream impact for NHIs. That gap matters because the remediation decision itself can break production, which is why teams delay action even when the risk is known.
Key questions
Q: What breaks when teams revoke NHI access without dependency mapping?
A: Without dependency mapping, teams can interrupt deployments, stop workloads, or break data pipelines that still depend on the identity. The practical failure is not just access loss but accidental service disruption, which is why remediation has to start with consumption and runtime context.
Q: Why does NHI remediation stay delayed even when the risk is obvious?
A: Teams delay because they cannot confidently predict the operational impact of changing an identity that is embedded in systems and code. When the blast radius is unclear, security teams choose inaction over a change that could break production, leaving known risk in place.
Q: How should security teams decide whether an NHI is safe to remediate?
A: Security teams should require evidence, not intuition. A remediation decision should include ownership, active dependency signals, usage patterns, and the expected blast radius if access changes. When those inputs are missing, the finding should stay in investigation rather than being forced into action. That is the difference between visibility and enforceability.
Q: What is the difference between discovery and trusted remediation for NHIs?
A: Discovery tells you that an identity exists and may be risky. Trusted remediation tells you whether you can change that identity without breaking a live dependency, which is the control that actually reduces exposure in production environments.
Technical breakdown
Why NHI remediation is different from human access changes
Non-human identities are embedded in runtime systems, build flows, and application dependencies, so a permission change is rarely isolated. A service account may authenticate successfully while also supporting a deployment job, a data pipeline, and a background workload. Remediation therefore changes behaviour in a live dependency graph, not just an access record. The hard part is not identifying that access exists. It is understanding whether that access is still required by something else before the change is made.
Practical implication: treat every NHI change as a dependency-aware operation, not a simple permission edit.
Why legacy IAM and PAM struggle with NHI remediation
Legacy IAM, PAM, and IGA controls were built around predictable human lifecycle events and stable ownership. NHIs do not behave that way. They are often ephemeral, reused across systems, and consumed by code that no access review can fully describe on its own. When a tool cannot trace who provisioned the identity, what consumes it, and what it is doing right now, remediation becomes guesswork. That is why teams end up choosing delay over action.
Practical implication: inventory and ownership data must be tied to runtime usage before remediation can be trusted.
What contextual identity graphs change in remediation
A contextual identity graph links provisioning source, ownership, secrets, runtime use, and consumption paths into one view. That does not remove risk, but it changes the decision from blind revocation to informed action. In practical terms, teams can distinguish an orphaned service account from one still driving a production pipeline, and they can see where a credential or policy change is likely to propagate. This is the difference between remediation as interruption and remediation as controlled change.
Practical implication: build remediation around dependency mapping, not isolated credential records.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- 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
Trusted remediation is now a governance control, not a cleanup task: In NHI programmes, the hardest part is often not finding the issue but proving that a fix will not break a dependent workload. That makes remediation quality a measure of identity maturity, because unresolved risk persists whenever teams cannot act with confidence. The practitioner conclusion is straightforward: if remediation is unsafe, discovery alone does not reduce exposure.
Legacy identity controls create a remediation blind spot for machine identities: IAM, PAM, and IGA processes were designed around human access lifecycles and cannot reliably interpret the operational blast radius of an NHI change. They often lack the runtime context needed to judge whether a credential supports a deployment, a pipeline, or a data flow. The practitioner conclusion is that remediation must be governed as a dependency problem, not a ticket closure problem.
Identity blast radius is the real problem hidden inside NHI remediation: The article exposes a governance gap where each credential change has an uncertain downstream footprint across workloads and pipelines. That uncertainty delays action and gives attackers time to exploit known exposure. The practitioner conclusion is to measure and reduce the blast radius before attempting broad revocation or entitlement changes.
NHI remediation exposes the limits of static lifecycle thinking: Service accounts and workload identities often outlive the assumptions under which they were created, yet traditional controls still assume stable ownership and predictable usage. That assumption breaks when identities are embedded in code and infrastructure. The practitioner conclusion is that lifecycle governance has to account for runtime dependency, not just creation and removal events.
From our research library:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Service Account Security Guide
What this signals
Identity blast radius: NHI programmes need to move from counting identities to understanding what each identity can break. Once access is embedded in deployments and pipelines, the relevant control question becomes whether the change can be made safely, not whether the issue exists.
A remediation programme that cannot explain runtime dependency is not ready for scale. The next maturity step is to connect ownership, consumption, and usage context so teams can sort safe fixes from disruptive ones before revocation begins.
For practitioners
- Map remediation dependencies before changing access Trace which workloads, pipelines, and data flows depend on each NHI before revoking credentials or changing permissions. Use that dependency map to classify changes as safe, risky, or requiring staged execution.
- Separate orphaned identities from active production identities Identify whether the identity still has a live owner, a current consumer, or a runtime dependency. Only identities with no clear consumer should be candidates for immediate offboarding or revocation.
- Prioritise remediation by operational blast radius Rank NHI issues by the systems they can disrupt, not just by severity scores. A lower-risk credential with a wide dependency footprint may need a safer change path than a higher-risk credential with no live consumers.
- Require machine-readable remediation instructions Standardise how fixes are expressed so changes can be applied consistently across credential rotation, access revocation, and policy enforcement. The goal is to reduce manual judgement in the moment of change.
Key takeaways
- The article argues that NHI remediation is the hardest security problem because access changes can break the systems that depend on them.
- The scale problem is already large, with non-human identities outnumbering human users by 45:1 in the enterprise.
- The practical answer is dependency-aware remediation that reduces risk without guessing at the blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article focuses on safely removing or changing NHI access without breaking dependent systems. |
| NHI-05 — Overprivileged NHI | Remediation depends on reducing excess access while understanding runtime dependency and operational impact. | |
| NHI-07 — Long-Lived Secrets | Credential changes are central here because stale secrets create both exposure and remediation risk. | |
| Recommendation — Review offboarding and revocation paths so NHI access can be removed without disrupting production dependencies. Reduce overprivilege only after mapping which active workloads still depend on each entitlement. Shorten secret lifetime where possible and verify that rotation will not break consuming systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle management governs safe credential rotation and revocation for NHIs. |
| Recommendation — Apply authenticator management controls to rotate or revoke NHI credentials with dependency awareness. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account management discipline is needed to track ownership and remove stale machine identities safely. |
| Recommendation — Maintain authoritative account inventories and remove unused NHI accounts through controlled offboarding. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes how NHI credentials become attack paths when remediation is delayed or unsafe. |
| Recommendation — Map exposed NHI credentials to credential-access and lateral-movement scenarios to prioritise remediation. | ||
Key terms
- Trusted remediation workflow: A cleanup or protection process that runs with elevated authority to remove malicious content or restore security state. If attackers can influence that workflow, they can convert a defensive control into an escalation path and gain more privilege than the original user had.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Runtime Dependency Risk: Runtime dependency risk is the gap between what a software manifest says will run and what a live workload is actually executing. It matters because malicious or altered packages can behave differently at runtime, especially when they touch secrets, spawn processes, or call external endpoints.
- Contextual Identity: Contextual identity is identity data enriched with business information such as employment status, department, role, and accountable owner. It improves governance decisions by linking entitlements to real operating context, which is especially important when contractors, third parties, and non-human identities are involved.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org