Removing static NHI credentials from service access workflows

At a glance

What this is: This is an analysis of why static NHI credentials keep leaking across service access workflows and why removing them from the path changes the control model.

Why it matters: It matters because IAM teams can only govern what they can inventory, scope, and revoke, and static service secrets keep escaping those controls across NHI and workload access paths.

Context

Static NHI credentials are long-lived secrets such as API keys, passwords, connection strings, certificates, and tokens that service accounts, workloads, and integrations use to reach other services. When those credentials are stored in commits, artifacts, config files, or environment variables, the security model shifts from governed access to persistent secret handling.

The article argues that this is a structural governance problem, not a cleanup problem. Different services issue different credential types, so teams end up with fragmented rotation rules, inconsistent storage practices, and no reliable way to prevent exposure once humans have to touch the credential at all.

Key questions

Q: What breaks when service access still depends on static NHI credentials?

A: The workflow breaks at the point where credentials must be copied, stored, and later recovered. That creates exposure in repositories, build artifacts, config files, and runtime environments, so the real failure is persistent secret handling. Once the secret exists outside the live access request, compromise becomes a search problem instead of an authentication problem.

Q: Why does rotating exposed secrets not fully solve credential leak risk?

A: Rotation is reactive, because the secret has already existed and may already have been copied into places the team cannot reliably enumerate. In mixed estates, different services use different credential types, which makes rotation uneven and easy to miss. Preventing persistence removes the need to chase every place a secret may have landed.

Q: How can security teams reduce the blast radius of service-to-service access?

A: Issue credentials only at runtime to a verified workload identity and make the credential expire when the job ends. That reduces the blast radius because there is no standing secret to steal from code, storage, or deployment objects, and the access scope is limited to the exact workload that was attested.

Q: What should teams do with legacy services that still require stored credentials?

A: Treat them as exceptions and isolate them behind the smallest possible access scope, then plan their replacement with an issuance-based model. Legacy static secrets should be the temporary outlier, not the normal pattern, because every persistent credential keeps reintroducing leak and rotation problems.

Technical breakdown

Why static service credentials keep leaking

Static credentials leak because they must exist somewhere before a workload can use them. Once a secret is created for a service account, database, API, or cloud integration, developers and operators often need to place it into a commit, artifact, ConfigMap, S3 file, or CI environment. That creates exposure across build, deploy, and runtime paths. The technical failure is not only storage, but persistence: the secret remains valid after it has been copied into places the governance model never intended.

Practical implication: treat persistent credential creation as the risk event, not just the storage location.

Why rotation does not solve the underlying workflow

Rotation helps only after a secret already exists, is distributed, and may already be exposed. In a fragmented estate, API keys, passwords, x.509 certificates, IAM roles, and service tokens follow different operational rules, which makes a single rotation policy hard to enforce consistently. The result is a control that reacts to leakage instead of preventing it. If credentials are part of the access path, every downstream system that copied them becomes part of the cleanup problem.

Practical implication: use rotation as a backstop, but do not rely on it as the primary control for service access.

How runtime-issued access changes the identity model

Runtime-issued access replaces stored secrets with short-lived credentials bound to workload identity. In the model described here, the workload presents a SPIFFE identity, the access layer verifies it, and a scoped credential is issued only for the job that needs it. Because the credential is not persisted, there is nothing for an attacker to recover later from source control, object storage, or build artifacts. That changes the governing question from who holds the secret to which workload is allowed to receive access at runtime.

Practical implication: move enforcement to issuance time and bind access to verified workload identity.

Threat narrative

Attacker objective: The attacker’s objective is to reuse a leaked service credential to reach the protected workload or data store without needing to break the service itself.

1. Entry occurs when a static credential is copied into a repository, artifact, config file, or environment where it can later be discovered.
2. Credential access happens when an attacker finds the leaked secret and uses it against the downstream service exactly as intended.
3. Impact follows when the abused credential grants access to data or infrastructure that the attacker can query, exfiltrate, or manipulate.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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 NHI credentials are a persistence problem, not a storage problem. The article shows that service credentials leak because they are designed to exist as movable artifacts across commits, artifacts, config files, and runtime environments. That means the breach surface is the credential lifecycle itself, not one bad repository or one careless engineer. Practitioners should stop treating leakage as an exception and start treating persistence as the flaw.

Rotation advice is a post-exposure control, not a prevention model. When every service issues a different credential form, teams cannot realistically enforce one consistent rotation regime across passwords, API keys, certificates, tokens, and IAM roles. That fragmentation turns governance into exception handling. The stronger control is to remove the standing secret from the workflow so there is no reusable artifact to find later.

Runtime identity is the more durable governance boundary. A workload that proves its identity at request time can receive narrowly scoped access without ever handling a stored secret. That shifts the control plane from secret custody to identity attestation and issuance policy, which is a better fit for modern service-to-service access. Practitioners should reframe the problem as governed credential elimination, not better secret care.

Secretless access creates an identity blast radius reduction. If a credential never becomes static, compromise of repositories, artifacts, or object storage no longer exposes the same attack path. That does not eliminate all abuse, but it removes the easiest reuse path that breach reports keep describing. The lesson is straightforward: access workflows should be designed so there is nothing persistent to steal, copy, or rotate.

SPIFFE-style workload proofing changes the trust assumption. The article’s model assumes the workload can prove who it is before any credential is issued. That is a stronger boundary than trusting whatever process already has the secret in hand. Practitioners should use that assumption shift to redesign service access around verified workload identity and ephemeral issuance.

What this signals

Static secret elimination is becoming the cleaner governance boundary for NHI programmes. When service access depends on a credential that can be copied, the programme is managing evidence of access instead of access itself. Moving issuance to runtime gives teams a boundary they can actually enforce: a verified workload receives a short-lived credential, and nothing persists for later reuse.

The practical signal for IAM and platform teams is that secret rotation should no longer be the primary design target for service access. The stronger target is secret absence, especially where workloads can prove identity at request time and receive narrowly scoped access without ever holding a reusable artifact.

For practitioners

• Eliminate static secrets from service access paths Replace stored API keys, passwords, tokens, and connection strings with runtime-issued access so the workload receives credentials only for the duration of the job.
• Bind issuance to workload identity Require the accessing workload to prove identity before any credential is delivered, and scope the resulting access to the exact service and operation needed.
• Inventory every service that still defaults to long-lived credentials Map each database, SaaS app, cloud service, and broker that still expects static secrets so you can remove persistence from the highest-risk workflows first.
• Redesign rotation programs around elimination Use rotation only as a fallback for legacy systems, and set the target state as no persistent credential existing in source control, artifacts, or config files.

Key takeaways

• Static service credentials create a governance problem because they must persist long enough to be copied, stored, and leaked.
• The article’s core point is that rotation is a cleanup tactic, while removal from the access path is a prevention tactic.
• Runtime-issued, workload-bound access changes the control point from secret custody to verified identity at issuance time.

Key terms

• Static NHI Credential: A static NHI credential is a long-lived secret such as an API key, password, token, certificate, or connection string used by a non-human identity. It persists outside the live request, so it can be copied, leaked, rotated, or reused long after issuance. That persistence is the core governance problem.
• Runtime-Issued Access: Runtime-issued access is a pattern where credentials are created only when a verified workload requests them and expire when the task ends. The identity proves itself at request time, and the system issues a short-lived credential instead of storing a reusable secret. This reduces persistence and narrows abuse opportunities.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.

Deepen your knowledge

NHI governance, workload identity security, and secrets 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.