Stored AWS credentials create a hidden NHI risk surface

At a glance

What this is: This is an analysis of why stored AWS credentials remain a hidden non-human identity risk, and the key finding is that plaintext credential storage keeps the attack surface alive across applications, containers, pipelines, and devices.

Why it matters: It matters because IAM, PAM, and NHI programmes still inherit risk when credentials persist at rest, even if rotation and logging are in place, while secretless and workload-bound identity models shift the governance baseline.

👉 Read Riptides' analysis of the hidden cost of stored credentials

Context

Stored AWS credentials are not just a hygiene issue. They are a standing identity exposure problem, because any secret left in memory, files, logs, pipelines, or management systems can be copied and reused outside the intended trust boundary. That is the core NHI governance gap in this article: the organisation is trying to control an identity that still exists at rest.

The article argues that rotation, logging, and other incremental controls do not remove the underlying exposure window. For IAM and NHI teams, the question is whether the programme is still managing credentials as durable assets, or whether it is moving toward ephemeral workload identity models that remove stored secrets from the architecture altogether.

Key questions

Q: What breaks when AWS credentials are stored in environment variables or config files?

A: Stored AWS credentials create a reusable identity artifact that can be copied from logs, images, laptops, or pipelines and replayed outside the intended workload. The failure is not just theft, but persistence of access after compromise. That is why stored secrets expand the attack surface even when the application logic itself is unchanged.

Q: Why do stored NHI credentials increase cloud compromise impact?

A: Because the credential becomes a standing ticket into cloud services until it is rotated or revoked. Attackers can create resources, access data, and establish persistence before defenders notice, which turns one exposed secret into spend, data loss, and recovery work. The longer the secret lives, the larger the blast radius.

Q: How do security teams know whether secret rotation is actually working?

A: Rotation is working only if it shortens the window between leak and invalidation, limits dependent-system breakage, and reduces the number of places a secret can still be used. If the same credential exists in many systems or lingers after disclosure, rotation is masking exposure rather than controlling it.

Q: Should organisations replace stored credentials with secretless authentication?

A: For high-risk workloads, yes. Secretless authentication removes the reusable secret from the system and replaces it with short-lived, request-bound identity, which reduces theft value and compliance burden. Organisations should prioritise services with frequent cloud access, sensitive data, or shared infrastructure first.

Technical breakdown

Stored credential exposure paths in cloud and CI/CD

Stored credentials become reusable attack material wherever they are written, copied, or cached. In practice that includes environment variables, config files, secrets managers, CI/CD logs, container images, developer laptops, and mounted volumes. The technical weakness is not one specific platform, but the fact that a secret exists outside the authentication event and can therefore be stolen independently of the application that uses it. That is why plain storage creates a durable exposure window even when the workload itself is otherwise well protected.

Practical implication: inventory every place credentials can persist, then treat each storage location as an attack surface rather than an admin convenience.

Why rotation reduces exposure but does not remove trust assumptions

Rotation shortens the useful life of a leaked secret, but it still assumes the credential can be safely stored, scheduled, distributed, and revoked before abuse. That is an operational control, not a structural fix. The article's deeper point is that every stored credential remains valid until rotated, which means compromise can still happen inside the active window. This is why secret rotation helps with blast radius, but does not eliminate the architecture that created the blast radius.

Practical implication: use rotation as a containment measure, not as proof that stored secrets are an acceptable long-term identity model.

Secretless authentication and ephemeral workload identity

Secretless authentication replaces stored credentials with short-lived proof of workload identity. The application does not hold a reusable secret; instead, identity is asserted at request time and translated into temporary access for the specific call. In zero trust and SPIFFE-aligned models, the credential becomes a transient artifact rather than a durable object. That changes the risk profile materially, because compromise of the workload no longer automatically yields a reusable secret that can be replayed elsewhere.

Practical implication: prioritise high-risk services for secretless or workload-bound identity where stored credentials currently gate cloud access.

Threat narrative

Attacker objective: The attacker wants durable cloud access and monetisable control of AWS resources before defenders notice the credential has been abused.

1. Entry begins when an attacker finds a stored AWS credential in an environment variable, config file, CI/CD log, container image, or similar exposed location.
2. Escalation follows when the attacker uses that credential to call cloud APIs, create resources, access data, or establish persistence with new IAM users and roles.
3. Impact arrives as cloud abuse, data exfiltration, cryptomining spend, incident response overhead, and compliance exposure spread across dependent systems.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline 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

Plaintext credential storage is a governance failure, not a rotation failure. The central mistake is treating credentials as durable assets that can be safely managed at rest. Once the secret exists in files, logs, images, or pipeline output, the organisation has already created a reusable identity artifact that can be copied outside its intended boundary. The implication is that the control model is wrong before the incident begins.

Stored credential trust debt: This article names the real problem well: every stored secret accumulates trust debt because the environment must remain correct until the next rotation, revocation, or detection event. That is a brittle assumption in modern cloud and CI/CD estates, where secrets are replicated across systems and teams. Practitioners should recognise that the debt is architectural, not administrative, and it compounds as secrets proliferate.

Secretless identity changes the governance baseline for NHI programmes. When credentials are generated just in time and discarded after use, the audit question changes from 'how are secrets rotated' to 'why do secrets exist at all for this workload'. That is a more durable control posture for services that call cloud APIs frequently or operate on shared infrastructure. The implication is that NHI governance must move from lifecycle management of stored secrets to elimination of unnecessary persistent credentials.

Compliance pressure is now aligned with the security case. The article points to SOC 2, FedRAMP, and zero trust expectations that increasingly view long-lived credentials as liabilities. That alignment matters because it removes the old excuse that secretless approaches are too theoretical for audit. In practice, auditors are already asking where credentials are stored and who can access them. The implication is that governance teams should treat stored secrets as a disclosure and lifecycle problem, not a documentation problem.

Identity blast radius is the right lens for prioritisation. Not every workload needs to be secretless first, but any service with frequent cloud access, shared infrastructure, or sensitive data has a larger blast radius when a credential leaks. That gives IAM and security teams a defensible prioritisation model. The implication is to rank workloads by the cost of credential compromise, not by the convenience of the existing secret store.

From our research:

• 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 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For the broader control model, see the Guide to the Secret Sprawl Challenge, which maps how credential sprawl becomes an operational governance problem.

What this signals

Stored credential risk is becoming a programme design issue, not a cleanup task. When secrets are distributed across apps, pipelines, and developer endpoints, the organisation is really managing identity lifecycle debt. The useful question is no longer how to rotate faster, but which services still require a persistent secret at all, especially where cloud access is frequent and blast radius is large.

Ephemeral workload identity is now the more defensible control direction for modern estates. That is especially true where federated cloud access already exists through OIDC and zero trust patterns. As teams reduce stored secrets, they should also rework audit evidence, because compliance will increasingly look for proof that temporary credentials are issued and discarded rather than merely rotated.

With 27 days to remediate a leaked secret according to the State of Secrets in AppSec, the recovery window is already longer than most incident teams assume. That means the operational standard should be blast-radius reduction before disclosure, not reaction after exposure. For teams still dealing with sprawl, the Guide to the Secret Sprawl Challenge is the right next lens.

For practitioners

• Map every credential storage location Catalogue environment variables, config files, CI/CD logs, container images, mounted secrets, and developer endpoints where reusable credentials persist. Treat each location as a separate control domain and assign an owner for removal or containment.
• Reframe rotation as containment Keep rotation for existing exposure, but do not let it become the programme's end state. Measure whether rotation is reducing the time a leaked secret remains usable, and pair it with migration plans for high-risk workloads.
• Prioritise secretless migration by blast radius Start with services that call cloud APIs frequently, run on shared infrastructure, or handle sensitive data. These workloads have the highest payoff when moved to ephemeral credentials or workload-bound identity.
• Validate audit evidence before the next review Prepare evidence showing where stored credentials have been removed, where OIDC federation is in place, and how temporary credentials are issued and discarded. This turns the compliance discussion from policy text to operating model proof.

Key takeaways

• Stored AWS credentials are a standing identity exposure problem, because every place a secret is saved becomes a separate attack surface.
• The evidence points to real financial and operational loss, including four- and five-figure cloud abuse costs and multi-week remediation cycles.
• The practical pivot is from managing secrets more carefully to removing unnecessary stored credentials from the architecture entirely.

Key terms

• Stored Credential: A stored credential is a reusable secret kept in a file, variable, system, or repository so an application can authenticate later. In NHI governance, the problem is durability: once stored, the secret can be copied, replayed, or exposed outside the intended workload boundary.
• Secretless Authentication: Secretless authentication is a model where the application does not hold a long-lived credential. Instead, it proves identity at request time and receives short-lived access for that specific transaction, reducing the value of theft and the burden of manual rotation.
• Identity Blast Radius: Identity blast radius is the amount of damage possible if a credential or identity is compromised. It depends on privilege scope, credential lifetime, and how widely the secret is reused across systems, which is why workload prioritisation matters as much as rotation policy.

Deepen your knowledge

Stored credential risk and secretless workload identity are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing durable secrets with ephemeral access, it is worth exploring.

This post draws on content published by Riptides: The Hidden Cost of Stored Credentials. Read the original.