Credential chaining: how one leaked key leads to the next

Most serious NHI breaches are not one stolen credential but a chain, where each secret the attacker finds unlocks the place where the next one is stored. A contractor password reaches an internal share, a token in source code reaches a database, a service account in a support tool reaches customer session tokens. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) puts it plainly: one leaked key rarely stays one key, and 56% of the breaches it analysed involved more than one kind of non-human identity. This guide is for identity, cloud and security engineering teams who want to find and break those chains before an attacker walks them. It draws the cross-breach lesson from cases including Uber, Okta, Cloudflare, the Internet Archive and Midnight Blizzard, then sets out the controls, detections and steps that cut the links.

Key takeaways

• Chains are the norm, not the exception. The report found 56% of breaches involved more than one kind of NHI, and secret or password was the most-exploited identity type (84 breaches).
• Every link is a place where a credential is stored next to access. Scripts, repositories, support tickets, password vaults and CI/CD stores each held the next key in a real breach.
• Rotation must be complete to break a chain. Cloudflare's 2023 intrusion used four credentials from the Okta breach that were not rotated because they were believed to be unused.
• Scope decides how long the chain gets. A credential scoped to one system and one environment ends the chain at the first hop; a broad one hands over the next store of secrets.
• Detect the hop, not only the entry. New credentials added to apps, bulk secret reads and a known NHI used from a new place are the signals that a chain is in progress.

What credential chaining is

Credential chaining is the pattern where an attacker uses one identity's access to reach a location that holds another identity's credentials, and repeats until they reach something valuable. It is lateral movement driven by secrets rather than by exploits. Each hop needs two things to be true: the current credential can read a store, and that store holds a usable secret for a different system. Break either condition and the chain stops.

In ATT&CK terms a chain usually combines T1552 Unsecured Credentials (and T1552.001 Credentials In Files) for finding the next secret, T1078.004 Cloud Accounts or T1550.001 Application Access Token for using it, and T1098.001 Additional Cloud Credentials when the attacker plants their own secret to keep the access. For the general movement picture see the Lateral Movement Guide; this guide is about the NHI links specifically.

What the breach data shows

The figures below are taken as printed in NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026), covering 200+ breaches from November 2017 to October 2026. A breach can have more than one route and more than one identity type, so counts overlap.

The report's own conclusion is that attackers use one key to find the next credential, then the next, which is why inventory, scope and short lifetimes matter more than any single control.

Five chains from real breaches

Each case below is summarised from its NHI Mgmt Group breach page and the sources cited there. The point is the shape of the chain and where it could have been cut.

Two patterns stand out. First, the middle link is almost always a store of secrets that is not a secrets manager: a share, a browser profile, a ticketing system, a repository. Second, the response often had to be far larger than the chain: Cloudflare rotated more than 5,000 production credentials and triaged 4,893 systems because it could not be sure where the chain ended.

Map your chains before an attacker does

You cannot cut chains you have not drawn. Treat it as a graph problem: nodes are identities and stores, edges are "can read" and "contains a credential for".

1. List the stores that hold credentials. Secrets managers, CI/CD variable stores, repositories, wikis and ticketing systems, shared drives, browser password stores on managed devices, configuration files on servers, container images and HAR or log uploads. Use the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments for the cloud, SaaS and CI/CD side.
2. Scan each store for live secrets. Run secret scanning over repositories with full history, CI logs, wiki spaces and ticket attachments, and record which system each found secret opens. See the Git Secret Scanning Guide.
3. Record who can read each store. For every store, list the human and non-human identities with read access, including integrations and bots.
4. Join the two lists. Any identity that can read a store containing a credential for a more privileged system is a chain edge. Flag edges where the target is tier zero: identity providers, secrets managers, CI/CD, cloud organisation admin, backup and signing keys.
5. Rank by path length to tier zero. A chain of two hops from an internet-facing token to a cloud admin key is a priority over a five-hop path.
6. Fix the edge, then re-run. Remove the stored secret, narrow read access, or replace the credential with a short-lived one, and repeat the join to prove the edge is gone.

Controls that cut each link

The biggest single lever is replacing static secrets with short-lived, federated credentials, because a token that expires in an hour and cannot be minted outside its workload makes a poor link. See the Workload Identity Federation Guide and the Secrets Management Guide.

Rotation that actually breaks the chain

When a link is exposed, partial rotation leaves the chain intact. The Cloudflare case is the clearest example in the dataset: thousands of credentials were exposed in the Okta compromise and Cloudflare rotated them, but four that were believed unused were not, and those four were the way in. The Internet Archive case shows the same failure with Zendesk tokens sitting in already-stolen source code.

1. Define the exposed set by store, not by use. If a repository, vault or ticket system was read, every credential in it is exposed, including ones you think are dead.
2. Revoke before you rotate. Disable or delete the old credential, then issue a new one. Rotation that leaves the old value valid for a grace period extends the window.
3. Follow the chain forward. For each revoked credential, check what it could read and add any secrets in those stores to the exposed set.
4. Prove it. Attempt authentication with each old value from a controlled host and record the failure as evidence. See the OAuth Token Introspection and Revocation Guide for token types.
5. Delete what is truly unused. A credential nobody can name an owner for should be removed, not left in place. The NHI Offboarding and Decommissioning Guide covers the process.
6. Roll back safely. Keep a break-glass path to restore a revoked credential for a named system for a limited time, approved by the incident lead, rather than leaving old values valid by default.

Detecting a chain in progress

Entry is often invisible: a valid credential used as intended. The hops are noisier. Build detections for the moment an identity reaches for the next credential.

• Bulk reads of secret stores: an identity listing or reading many vault paths, CI variables or repository files in a short window.
• A known NHI used from somewhere new: service principal sign-ins in Entra ID (a separate log from interactive sign-ins), AWS CloudTrail calls from an unexpected network or user agent, or a service token used from a laptop range. See the Service Account Behavioural Baselining Guide.
• Credential additions: new client secrets or certificates on existing apps, new access keys on existing roles, new OAuth app registrations and consents. Microsoft's Midnight Blizzard responder guidance highlights a rise in Exchange Web Services calls after a credential update as a signal.
• Privilege grants to apps: grants of full_access_as_app or roles that can add members to admin directory roles.
• Repository archive downloads: Cloudflare's attacker downloaded repositories using the Bitbucket git archive feature; archive and clone volume by service accounts is worth an alert.

For rule design see the Detection Engineering for Non-Human Identities Guide.

Metrics that show chains are shrinking:

• Number of chain edges to tier-zero systems (target: falling each quarter).
• Live secrets found per scan of repositories, wikis and tickets.
• Share of NHIs using short-lived or federated credentials instead of static secrets.
• Time from secret exposure to verified revocation.
• Share of exposed-set credentials proven revoked by test after an incident (target: 100%).

Decision guidance: where to start

• Small organisations: start with secret scanning across repositories and the ticketing system, MFA on every human login to source control and cloud, and a rule that no service account password lives in a browser or personal vault. That removes the most common first two links.
• Large organisations: build the chain graph for tier-zero systems first, then fund replacement of static secrets with federation for the shortest paths. Automate exposed-set rotation so it is complete by default.
• Vault or federate? Vaulting moves the secret to one well-guarded store, which helps, but the vault becomes a high-value link. Federation removes the secret. Prefer federation where the platform supports it; vault the rest with tight read scopes.

Framework mapping

Practitioner checklist

• List every store that holds credentials, including tickets, wikis, shares and browser profiles on managed devices.
• Scan repositories with history, CI logs and ticket attachments for live secrets, and record what each one opens.
• Join store contents with store readers to find chain edges, and rank paths to tier-zero systems.
• Remove service account passwords from human vaults and browsers; block personal browser profiles on managed devices.
• Scope every NHI to one system and one environment; remove test-to-production trust.
• Replace static secrets on the shortest tier-zero paths with federated, short-lived credentials.
• Write an exposed-set rotation runbook: revoke by store, follow the chain forward, prove revocation by test.
• Alert on new app credentials, new OAuth apps and consents, app role grants and bulk secret reads.
• Track chain edges to tier zero and time to verified revocation as programme metrics.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: T1552 Unsecured Credentials
• MITRE ATT&CK: T1098.001 Additional Cloud Credentials
• Cloudflare: Thanksgiving 2023 security incident
• Microsoft Threat Intelligence: Midnight Blizzard, guidance for responders on nation-state attack
• CircleCI: CircleCI incident report for January 4, 2023 security incident
• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)

Related NHI Mgmt Group resources: Non-Human Identity (NHI) Guide · Secrets Management Guide · NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments · Lateral Movement Guide