Removing static NHI credentials from service access workflows

At a glance

What this is: This is an argument for replacing static service credentials with just-in-time workload access, with the key finding that eliminating stored secrets removes the theft target rather than trying to recover after exposure.

Why it matters: For IAM and NHI practitioners, the issue is not only rotation speed but whether the organisation can govern access without ever persisting a credential that an attacker can later reuse.

👉 Read Hush Security's analysis of removing static credentials from NHI workflows

Context

Static service credentials create a governance gap because they can be copied, cached, exposed, and reused long after the original access decision was made. In NHI environments, that means the control plane is often trying to manage the aftermath of exposure instead of preventing exposure in the first place. The primary question for IAM teams is whether access can be issued at runtime without creating a durable secret.

This article argues that the answer is yes when the credential is bound to workload identity rather than a person, device, or manually handled secret. That framing aligns with broader NHI governance problems around secret sprawl, overprivilege, and third-party risk. For teams that still rely on stored keys, the starting point is typical, not exceptional, which is exactly why the control gap is so widespread.

Key questions

Q: How should security teams handle service access when static secrets keep leaking?

A: They should move the access decision to runtime and bind it to workload identity, so the credential is issued only when a verified workload needs it. That reduces exposure from copies in code, pipelines, and config files. Rotation still matters for legacy systems, but the stronger control is removing the static secret from the workflow entirely.

Q: When does secret rotation stop being enough for NHI governance?

A: Rotation stops being enough when the organisation keeps recreating the same credential in multiple places or cannot prove where it lives. In that situation, the problem is architectural, not procedural. Teams should prioritise systems that issue ephemeral access and eliminate stored secrets before investing in more rotation cycles.

Q: What breaks when machine credentials are stored in configs and artifacts?

A: The credential becomes reusable long after the original authorization event, so exposure can lead to replay, lateral movement, and third-party compromise. Storage also spreads the secret across systems that are hard to audit consistently. The practical failure is not only leakage, but the inability to prove where the credential copied.

Q: Should organisations move from secret rotation to workload-attested access?

A: Yes, where the underlying service supports it and the workload can present a trustworthy runtime identity. Workload-attested access is better suited to ephemeral machine use because it removes the durable artifact attackers want. Rotation remains a backstop, but it should not be the primary control for high-volume NHI access.

Technical breakdown

Why static NHI credentials keep failing in mixed service estates

Different services expose different authentication primitives, including API keys, passwords, connection strings, certificates, IAM roles, and tokens. That heterogeneity makes one universal rotation policy unrealistic because each system has different storage, renewal, and audit mechanics. The result is policy drift, where teams rely on documentation and best effort instead of a consistent control model. In practice, exposure happens wherever credentials are copied for convenience, which means the breach surface is distributed across code, pipelines, and config stores rather than concentrated in one vault.

Practical implication: Practitioners should inventory credential types by service class before trying to standardise lifecycle controls.

How workload identity changes credential delivery

Workload identity shifts authentication from a stored secret to an attested runtime identity. A workload proves who it is, usually through infrastructure-bound identity such as SPIFFE, and a controller issues scoped access only for the duration of the job. That means the access decision is made at the moment of use, not ahead of time by creating a reusable artifact. The security value is less about concealment and more about removing persistence, because ephemeral issuance reduces the time window in which an attacker can reuse stolen material.

Practical implication: Teams should treat ephemeral credential delivery as an identity control, not just a secrets-management pattern.

Why just-in-time access still needs tight privilege scoping

Just-in-time access is not a substitute for least privilege. If the runtime-issued credential can still reach broad datasets, wide database roles, or powerful admin operations, the access path remains too large even if the credential expires quickly. The control objective is to combine ephemeral issuance with narrowly defined privileges and workload-specific attestation. That is what prevents a temporary credential from becoming a high-value pivot point during the job window. The architecture only works when issuance, scope, and identity verification are enforced together.

Practical implication: Practical use means pairing runtime issuance with explicit privilege boundaries and continuous attestation checks.

Threat narrative

Attacker objective: The attacker’s objective is to turn a single exposed secret into repeatable access against multiple services or workloads before defenders can revoke it.

1. Entry occurs when attackers find a credential left in a commit, artifact, config file, or exposed repository.
2. Escalation happens when the stolen credential works across a cloud, data, or AI service without additional runtime verification.
3. Impact follows when the attacker uses the reusable secret to access data, impersonate a workload, or pivot into adjacent systems.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• 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

Static credential governance is a loss-making model once exposure is assumed. If a secret can be copied into code, a pipeline, or a third-party environment, the defender is already behind. Rotation helps only after discovery, which means the organisation is paying for a control that arrives after the damage path begins. Practitioners should treat stored service credentials as avoidable residual risk, not as an acceptable default.

Ephemeral access is only meaningful when the identity behind it is trustworthy. Runtime issuance shifts the control question to workload attestation, privilege scope, and session duration. That changes NHI governance from secret management to identity validation. The practical conclusion is that teams must align access issuance with verified workload context, or they simply recreate old problems in a shorter window.

Zero standing privilege for machines is becoming the more defensible baseline. Persistent service credentials create standing access even when no human is involved, which conflicts with modern least-privilege expectations. The field needs to move toward no-static-secret architectures for repeatable workloads, especially where data stores, AI services, and SaaS integrations are involved. The governance implication is clear: if no credential exists, there is nothing to leak or rotate.

Secret sprawl is now a design problem, not a hygiene problem. The article correctly points to the fact that teams do not just misplace credentials, they are forced to create them across too many systems. That means NHI governance must evaluate architecture choices before policy choices. The practitioner conclusion is to remove secret handling from the operating model wherever service support allows it.

Runtime access controls will increasingly define the boundary between managed and shadow NHI. If a team cannot explain when a credential exists, who can see it, and how long it lives, it does not really control that identity. The market is moving toward architectures that make hidden credentials harder to create in the first place. Practitioners should assume future governance will reward systems that can prove non-persistence.

From our research:

• 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, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• For teams operationalising this shift, Guide to the Secret Sprawl Challenge explains how to reduce exposure paths before rotation becomes the only remaining option.

What this signals

Static-secret dependence is becoming a structural governance liability. When credentials are created for every integration, teams inherit exposure paths they cannot fully observe or control. The practical signal for practitioners is to prioritise identity-bound issuance and to treat persistent secrets as an exception requiring explicit justification, not as the default operating model.

Secret sprawl is now the better indicator of control maturity than rotation frequency. If access can be issued without storing credentials, the organisation shrinks the attack surface before incident response begins. That is why the governance conversation is moving from “how often do we rotate” to “why does this secret need to exist at all”.

The NHI governance pattern is shifting toward no-standing-secret architectures for workloads that can prove identity at runtime. Teams that delay that shift will keep absorbing the operational cost of leaks, audits, and emergency revocation. The better programme move is to align policy, runtime identity, and service access so the secret never becomes portable in the first place.

For practitioners

• Map every service credential type Catalogue API keys, passwords, certificates, tokens, IAM roles, and connection strings separately because each one has a different lifecycle and exposure path. Use that inventory to identify where static credentials can be removed rather than rotated.
• Bind access to workload identity Require runtime attestation for machine-to-machine access so the workload proves its identity before any credential is issued. Use infrastructure identity signals such as namespace, service account, and node context to constrain issuance.
• Reduce standing privilege for service accounts Replace broad persistent entitlements with short-lived, task-scoped access that expires with the workload session. Keep the issued privilege narrow enough that a stolen credential cannot be reused for lateral movement.
• Remove secrets from developer and pipeline handling Stop asking developers and CI jobs to store credentials in commits, artifacts, environment files, or config maps. The operational goal is to make the secret unavailable outside the runtime path, not merely better protected.

Key takeaways

• Static service credentials create recurring breach risk because they can be copied into code, artifacts, and configuration stores.
• Runtime workload identity changes the problem from secret handling to identity verification and scoped issuance.
• NHI programmes should reduce standing privilege and remove secrets where the architecture allows it, not rely on rotation alone.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service, bot, token, certificate, or AI agent that needs access to systems and data. In governance terms, it is an identity that must be authenticated, authorized, monitored, and retired like any other access path, even though no person is behind the request.
• Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.
• Workload Identity: Workload identity is the practice of authenticating a machine or service by what it is and where it runs rather than by a shared secret. It lets systems issue access based on verified runtime context, which makes it easier to remove stored credentials and narrow the window for abuse.
• Just-in-Time Access: Just-in-time access is a control pattern that grants a credential only when a task needs it and removes it when the task ends. For NHI programmes, the value is not speed alone. It is reducing standing access so stolen or misused credentials have less time to be replayed.

Deepen your knowledge

Static secret elimination and runtime workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning service access around ephemeral credentials, it is worth exploring.

This post draws on content published by Hush Security: removing static credentials from NHI workflows. Read the original.