IAM controls still fail when credentials are embedded in code

At a glance

What this is: This is an IAM explainer that uses the Uber breach to show how hardcoded credentials and weak lifecycle controls turn identity management into a data exposure problem.

Why it matters: For IAM and NHI practitioners, it reinforces that access control fails when secrets, revocation, and monitoring are not governed as part of the identity lifecycle.

By the numbers:

• 57 million riders and drivers had personal data stolen in the 2016 Uber breach after attackers used hardcoded AWS credentials found in GitHub code.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Unosecur's explanation of IAM failures behind the Uber breach

Context

Identity and access management is often treated as a user directory problem, but the actual failure mode is broader: identities, permissions, and secrets are governed as separate concerns until a breach shows they are the same control plane. When credentials live in code or are tied to identities with broad access, IAM stops being an authorization layer and becomes an exposure surface for NHI governance.

The Uber case in the source article is a familiar pattern rather than an edge case. Attackers did not need to break cryptography or exploit a novel software flaw. They used hardcoded AWS credentials, accessed storage, and showed how weak lifecycle controls around non-human identities can turn a single secret into broad data access.

Key questions

Q: How should security teams prevent hardcoded secrets from becoming a breach path?

A: Security teams should remove credentials from code, store them in managed secret systems, and use runtime injection or short-lived tokens instead. They also need continuous scanning for exposed keys in repositories, build logs, and tickets. The control only works if discovery, rotation, and revocation are automated.

Q: What is the difference between IAM for users and IAM for non-human identities?

A: User IAM focuses on human authentication and session control, while non-human identity IAM governs service accounts, tokens, keys, and certificates that software uses to act. NHI control must add lifecycle management, ownership, rotation, and revocation because machine credentials can spread quickly and persist longer than human sessions.

Q: Why do leaked credentials often create larger incidents than teams expect?

A: A leaked credential can carry broad privileges, be copied across systems, and remain valid long after exposure. That means a single secret can become repeated access rather than a one-time event. The practical response is to reduce privilege, shorten credential lifetime, and make revocation immediate.

Q: Should organisations prioritise secret rotation or permission reduction first?

A: They should do both, but permission reduction usually comes first because it limits blast radius before a credential is lost. Rotation matters most when exposure is already suspected or confirmed. The best programmes pair least privilege with automated rotation so one control does not depend on the other.

Technical breakdown

How hardcoded secrets bypass identity controls

Hardcoded credentials collapse the distance between source code and production access. When an API key, access token, or cloud secret is embedded in code, any person or system that can read the repository can potentially assume the identity attached to that secret. IAM policies may still exist, but they are only effective if the credential lifecycle is controlled, monitored, and revocable. The failure is not limited to exposure at rest. Secrets in code are often copied into logs, build pipelines, tickets, and backups, which multiplies the number of places an attacker can find them.

Practical implication: treat source code as an untrusted secret storage location and remove credentials from it entirely.

Why overbroad non-human identity permissions increase blast radius

A non-human identity is any machine or workload identity such as a service account, token, or key used by software rather than a person. The security problem is not only that the identity exists, but that it often carries far more access than the application needs. If one exposed key can read storage, deploy code, or call multiple services, the compromise becomes an identity blast radius problem. Least privilege only works when permissions are scoped to a specific workload, environment, and task, and when those scopes are reviewed over time.

Practical implication: reduce privilege on every machine identity before revoking or replacing the credential that exposes it.

Why auditing and revocation must be part of the access model

IAM is incomplete if it authenticates and authorizes but does not prove who still has active access. Offboarding, rotation, and revocation are essential because machine identities do not naturally expire the way user sessions do. A stale secret in a repository can remain usable long after the original event that exposed it. That is why auditing must be tied to lifecycle management, not just logging. Continuous review is how teams discover dormant access, duplicated keys, and credentials that outlive their intended purpose.

Practical implication: build revocation and rotation into normal operations, not as a post-incident exception.

Threat narrative

Attacker objective: The attacker objective is to convert a leaked machine credential into direct access to cloud storage and the data inside it.

1. Entry via hardcoded AWS credentials discovered in public GitHub code.
2. Escalation through reuse of a credential tied to broad storage access.
3. Impact in the form of unauthorised access to sensitive user data at scale.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Hardcoded secrets are an IAM failure, not just a code hygiene issue. Once a credential is embedded in source, the access path is no longer governed by the intended runtime controls. The secret can be copied, leaked, and reused outside the application boundary, which means the real control gap is identity lifecycle governance. Practitioners should treat every embedded secret as an unmanaged non-human identity.

Identity blast radius is the core metric that matters when NHI governance breaks down. The problem in credential leaks is rarely the existence of one key alone. It is the amount of access attached to that key, the number of systems it can reach, and the duration it remains valid. That makes privilege scoping and revocation speed more important than perimeter assumptions.

Secrets management must be operational, not ceremonial. Many programmes say they manage secrets, but still allow keys to survive in code, tickets, and CI/CD tools. A usable control model requires discovery, rotation, offboarding, and monitoring as a closed loop. If a team cannot answer where a secret lives and who can still use it, the programme is already behind.

The Uber pattern remains relevant because most enterprises still do not govern machine access with the same discipline they apply to human users. Service accounts and API keys often outnumber employees by a wide margin, yet they receive less oversight. That imbalance is why NHI governance belongs inside IAM strategy, PAM policy, and secure software delivery at the same time.

Embedded credential exposure is a lifecycle problem disguised as a breach event. The breach begins long before the attacker arrives, at the point where a secret is created, stored, duplicated, or left active beyond its purpose. Practitioners should structure NHI controls around discovery and retirement, not only authentication events.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that remediation often lags exposure by a wide margin.
• That persistence makes the NHI Lifecycle Management Guide a useful next step for teams formalising rotation and offboarding.

What this signals

Credential exposure is now a governance design problem, not a point-in-time hygiene issue. Once secrets are copied into code, tickets, and CI/CD systems, the organisation no longer controls where the identity lives. Teams should assume that every machine credential has a lineage problem unless they can prove otherwise, and they should map that lineage into the Ultimate Guide to NHIs.

With 97% of NHIs carrying excessive privileges, the risk is not only exposure but the size of the access footprint attached to each secret. That is why IAM, PAM, and software delivery controls have to be designed together, with least privilege and rotation tied to release workflows rather than handled as after-the-fact cleanup.

Identity blast radius: this is the practical metric that should shape programme priorities. If a leaked key can reach multiple systems, then discovery speed matters less than how narrowly that key was scoped in the first place. The right benchmark is whether your access model can survive one credential escaping into the wild without turning into a multi-system compromise.

For practitioners

• Remove secrets from source control Scan repositories, build pipelines, and config files for API keys, tokens, and cloud access credentials, then replace them with short-lived references or injected runtime secrets.
• Scope every machine identity to one workload Review service accounts and cloud roles for shared use, broad permissions, and cross-environment access, then split identities so each workload has a narrow purpose and minimal rights.
• Automate rotation and revocation Set rotation intervals, revoke stale credentials on schedule, and tie offboarding to the systems that create secrets so expired access does not persist after code changes or personnel moves.
• Add secret discovery to CI/CD governance Use continuous detection for secrets in code, tickets, and pipeline logs, and alert on newly exposed credentials before they become durable attack paths.
• Track credential lineage and ownership Record which application owns each secret, where it is stored, and who can rotate it so audit teams can trace access without relying on tribal knowledge.

Key takeaways

• Hardcoded credentials turn IAM into a breach surface when secrets are not governed as part of the identity lifecycle.
• The scale of the problem is structural, not isolated, because exposed machine credentials can persist, spread, and stay overprivileged long after creation.
• Practitioners should reduce blast radius through least privilege, secret discovery, and automated revocation before the next leak becomes an incident.

Key terms

• Non-Human Identity: A non-human identity is a digital identity used by software rather than a person. It includes service accounts, API keys, tokens, certificates, and AI agents. These identities need lifecycle ownership because they can authenticate, carry privilege, and outlive the workflows that created them.
• Identity Blast Radius: Identity blast radius is the amount of damage possible when one credential or account is compromised. It depends on how many systems the identity can reach, how long it stays valid, and whether the permissions were narrowly scoped. Smaller blast radius means weaker attacker leverage.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tickets, logs, endpoints, and collaboration tools. It increases the number of places an attacker can find usable access and makes revocation harder because no single system owns the full inventory of copies.
• Credential Lifecycle: Credential lifecycle is the end-to-end management of a secret from creation through storage, use, rotation, and retirement. In mature IAM and NHI programmes, lifecycle control is the mechanism that keeps access current, traceable, and revocable when risk changes.

What's in the full article

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• The specific IAM changes Unosecur says followed the Uber breach, including credential handling and access monitoring.
• How the article frames the move from plaintext keys in code to role-based access patterns.
• The article's own explanation of how IAM failures map to compliance and audit concerns.
• The exact wording used by Unosecur to connect identity controls to the breach narrative.

👉 Unosecur's full article adds the breach context, IAM lifecycle lessons, and the remediation examples it highlights.

Deepen your knowledge

Credential discovery and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is still treating secrets as a code issue rather than an identity issue, it is worth exploring.