Notifications
Clear all
Topic starter
10/06/2026 10:52 pm
TL;DR: Stored AWS credentials create attack surface in environment variables, config files, CI/CD pipelines, and secrets systems, and leaked credentials can trigger immediate cloud abuse, delayed detection, and weeks of recovery work, according to Riptides. Eliminating stored secrets changes the control problem from rotation and audit to ephemeral workload identity.
NHIMG editorial — based on content published by Riptides: The Hidden Cost of Stored Credentials
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map every credential storage location Catalogue environment variables, config files, CI/CD logs, container images, mounted secrets, and developer endpoints where reusable credentials persist.
- Reframe rotation as containment Keep rotation for existing exposure, but do not let it become the programme's end state.
- Prioritise secretless migration by blast radius Start with services that call cloud APIs frequently, run on shared infrastructure, or handle sensitive data.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- A kernel-level explanation of how on-the-wire credential injection works without code changes.
- The specific workflow for intercepting requests and issuing temporary credentials at request time.
- The operational trade-offs of secretless authentication compared with traditional stored-secret patterns.
- The implementation context for workloads that already use AWS, GCP, or other external services.
👉 Read Riptides' analysis of the hidden cost of stored credentials →
Stored credentials and NHI risk: what IAM teams should know?
Explore further
12/06/2026 4:36 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Stored AWS credentials create a hidden NHI risk surface
