Remediation is the hardest problem in NHI security

At a glance

What this is: This is a blog analysis of why NHI remediation is harder than discovery, with the key finding that fixing machine identities can interrupt production if teams lack runtime context.

Why it matters: It matters because IAM, PAM, and IGA teams have to govern service accounts, workloads, and agentic systems without destabilising the business processes those identities keep running.

By the numbers:

• 45:1.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Token Security's analysis of why NHI remediation is the hardest security problem

Context

NHI remediation is the point where identity governance turns from visibility into operational risk management. Non-human identities include service accounts, workloads, CI/CD runners, and other machine credentials that can be tightly coupled to production dependencies, so a change that looks safe in a console can still break deployments or data flows if the surrounding context is missing.

This article argues that the hardest part of NHI security is not discovering credentials or mapping ownership, but fixing entitlements and secrets without causing outages. That is a familiar failure mode in mature IAM programmes: teams know something is wrong, but they do not trust the blast radius of the change enough to act.

For practitioners, the governance question is whether remediation decisions can be made with enough runtime and dependency awareness to be safe. That is why NHI security increasingly sits across IAM, PAM, IGA, secrets management, and workload identity rather than any single control plane.

Key questions

Q: What breaks when NHI remediation is attempted without dependency visibility?

A: Remediation fails when teams cannot see which workloads, pipelines, and integrations depend on a credential or permission. In that state, even a correct security fix can interrupt production, so the organisation delays action or makes risky changes blindly. The remedy is not faster revocation alone, but confidence in downstream impact before change approval.

Q: Why do service accounts and workload identities make remediation harder than human account fixes?

A: Service accounts and workload identities are embedded in runtime systems, code, and automation, so their access is often shared across processes rather than owned by one person. That makes entitlement changes harder to isolate and test. Human account fixes usually have clearer boundaries, while machine identity fixes can cascade across environments.

Q: How can security teams know if NHI remediation is actually working?

A: Look for safe change outcomes, not just fewer findings. Good remediation is visible in lower rollback rates, fewer production incidents during credential rotation, and faster movement from risk identification to controlled change. If teams still avoid fixing known issues because they fear outages, the programme is not yet working.

Q: What is the difference between finding an NHI issue and fixing it safely?

A: Finding an issue tells you that a secret, account, or permission is risky. Fixing it safely means changing that identity without breaking the systems that rely on it. The second step requires dependency knowledge, rollback planning, and operational validation, which is why remediation is a governance problem as much as a security one.

Technical breakdown

Why NHI remediation fails without dependency context

Non-human identities are rarely isolated objects. They are embedded in pipelines, applications, vaults, schedulers, and service meshes, so a credential or permission change can affect multiple runtime dependencies at once. Traditional IAM and PAM tooling often knows the entitlement state, but not the operational chain that depends on it. That leaves teams unable to tell whether a service account is safe to rotate, revoke, or re-scope. The technical problem is not just identity data quality. It is the absence of a usable dependency graph that links identity, ownership, and live runtime use.

Practical implication: do not approve remediation until the identity's consuming systems and runtime dependencies are mapped.

How secret rotation and privilege changes break production

Rotation and privilege reduction are safe only when every downstream consumer can tolerate the change. In machine environments, a secret may be embedded in application code, CI/CD jobs, environment variables, or third-party integrations, which means a single update can fail authentication across multiple services. The same applies to permission changes on workloads that expect broader access during a deploy or data transfer window. Without a clear understanding of where the credential is used, remediation becomes guesswork. That is why remediation is not the same as revocation; it is controlled change management for machine identities.

Practical implication: test rotation and entitlement reduction against consuming services before applying them to production identities.

Why AI-assisted remediation only works with machine-readable identity data

The article points to machine-readable remediation instructions as a way to reduce manual error, but automation only helps when the underlying identity data is structured and trustworthy. AI cannot safely infer the impact of a change if the inventory is incomplete, ownership is unclear, or runtime behaviour is hidden. In NHI governance terms, the value is not the AI itself. It is whether the system can translate context into safe action paths, such as targeted permission changes, automated rotation, or offboarding of orphaned identities. Without that data foundation, AI simply accelerates uncertainty.

Practical implication: use automation only after identity, ownership, and runtime signals are normalised into a reliable remediation workflow.

Threat narrative

Attacker objective: The attacker seeks sustained use of machine credentials that defenders cannot confidently remediate without disrupting business operations.

1. Entry occurs when an attacker or misconfiguration exposes a service account, API key, or workload credential inside the machine identity estate.
2. Escalation follows when that standing credential can be reused across environments because the organisation cannot safely revoke or narrow access without breaking production.
3. Impact arrives when delayed remediation leaves the identity active long enough for lateral movement, data access, or persistent abuse.
4. The attacker objective is to keep exploiting exposed machine access while defenders hesitate to fix it for fear of outages.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Remediation trust debt is the real NHI governance problem. Discovery creates inventory, but inventory does not create confidence that a change can be made safely. When teams cannot see which systems depend on a service account or secret, every remediation action becomes a production-risk decision, not a security decision. The practical conclusion is that NHI governance must measure safe changeability, not just asset count.

Legacy IAM, PAM, and IGA controls were built for identities whose dependencies were easier to isolate. Those controls struggle when the identity is embedded in code, pipelines, and runtime workflows, because the platform can see entitlement state but not operational fragility. This is why the article's remediation dilemma is not a tooling gap alone; it is a mismatch between human-era governance models and machine-era identity behaviour. Practitioners should treat dependency visibility as a control requirement, not an enhancement.

Trusted remediation is now a core security control, not a post-incident cleanup task. In environments where an NHI change can break a deployment or block a data pipeline, the ability to fix access safely becomes part of resilience. That aligns naturally with OWASP-NHI and zero-trust thinking, where continuous validation must extend to the consequences of identity change. Security teams should reframe remediation as governed change management for machine identities.

The remediation dilemma will intensify as agentic AI expands the machine identity estate. More autonomous systems mean more identities whose permissions can change quickly, but the underlying operational dependency problem remains the same. The field should expect more organisations to separate visibility from action, because seeing an issue is no longer the hard part. The hard part is proving that the fix will not break the system.

Identity blast radius is the concept this article sharpens. A machine identity is not risky only because it exists; it is risky because its removal or reduction can have outsized operational impact. That makes blast radius a governance metric, not just an incident afterthought. Practitioners should treat remediation success as the ability to reduce risk while containing operational blast radius.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• That confidence gap is why remediation depends on context, and why teams should also review the Guide to the Secret Sprawl Challenge before automating high-risk identity changes.

What this signals

Remediation maturity will become a board-level signal for NHI programmes. Organisations will be judged less on how many machine identities they can enumerate and more on whether they can change them without disrupting revenue-critical systems. The practical signal to watch is whether identity teams can move from issue detection to safe change in a controlled window, because that is where governance credibility will be won or lost.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the remediation problem is no longer confined to vault hygiene. The challenge now spans code, collaboration tools, and runtime services, so remediation programmes must cross IAM, secrets management, and engineering operations. That broader scope is exactly why the Guide to the Secret Sprawl Challenge is relevant to teams building a defensible change process.

Identity blast radius: the next maturity step is proving that a credential or permission can be reduced without creating an outage. As AI-driven infrastructure expands, the organisations that can validate blast radius before change will be the ones that can actually reduce NHI risk at speed. Teams should prepare for remediation workflows that are measured as much by operational safety as by security closure.

For practitioners

• Map consuming systems before changing NHI access Build a dependency view for each high-value service account, API key, token, or certificate before rotation or revocation. Capture which pipelines, applications, and integrations fail if the identity changes, and require that view in the approval path for remediation.
• Classify remediation by operational blast radius Separate low-risk hygiene fixes from changes that can interrupt production workloads. Use a tiered approval model so identity changes tied to data pipelines, deployments, or customer-facing services receive deeper validation before execution.
• Require machine-readable remediation instructions Convert high-frequency identity fixes into structured runbooks that can be executed consistently by operations and security teams. Include ownership, downstream dependencies, rollback conditions, and validation checks for every change.
• Automate rotation where the dependency model is complete Use automation only for identities whose usage is well understood and whose consuming systems can tolerate change. For orphaned or poorly understood credentials, resolve visibility gaps first rather than forcing remediation through uncertainty.
• Track time-to-safe-remediate, not just time-to-detect Measure how long it takes to move from identified risk to a safe change in production, because detection alone does not reduce exposure. Include failed remediation attempts and rollback frequency in the metric set.

Key takeaways

• NHI remediation is hard because machine identities are embedded in production dependencies, so a security change can become an outage risk.
• The evidence points to a governance gap, not just a visibility gap: teams know issues exist, but they lack enough context to fix them safely.
• Practitioners should treat dependency mapping, safe change validation, and controlled automation as core remediation controls, not optional extras.

Key terms

• Remediation dilemma: The remediation dilemma is the point where a security team knows an NHI is risky but cannot safely change it without potentially breaking production. It is not a discovery problem. It is a change-confidence problem created by hidden dependencies, incomplete ownership, and runtime fragility.
• Identity blast radius: Identity blast radius is the operational impact created when a credential, account, or permission is removed, rotated, or narrowed. In NHI environments, it can be much wider than expected because a single machine identity may support multiple services, pipelines, or integrations.
• Machine-readable remediation instructions: Machine-readable remediation instructions are structured change directives that systems and operators can execute consistently. For NHI governance, they matter because they encode ownership, dependencies, rollback conditions, and validation steps, reducing manual error when fixing access or secrets at scale.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• A contextual NHI Risk Graph workflow showing how the platform traces ownership, consumption, and runtime behaviour before remediation.
• Machine-readable remediation instruction generation for permissions changes, credential rotation, and policy enforcement.
• Examples of how the platform models downstream impact before offboarding an orphaned service account or revoking access.
• The integrations used to collect signals from CSPs, IAM systems, IdPs, vaults, logs, and configuration sources.

👉 The full Token Security post covers the identity graph approach, AI-assisted remediation, and runtime context needed to fix NHIs safely.

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.