TL;DR: Cloudflare’s breach shows how one missed access token and three service accounts, after the October 2023 Okta incident, enabled lateral movement into Confluence, Jira, and Bitbucket and forced a long secret-rotation campaign, according to Oasis Security. The lesson is that NHI governance fails when inventory, ownership, and rotation speed cannot keep pace with exposed credentials.
At a glance
What this is: This is an analysis of the Cloudflare breach, where missed NHI rotation left one access token and three service accounts available to an attacker.
Why it matters: It matters because IAM and PAM teams need to treat service-account inventory, credential rotation, and offboarding as breach-limiting controls, not cleanup tasks.
👉 Read Oasis Security's analysis of the Cloudflare breach and NHI exposure
Context
A non-human identity breach happens when exposed credentials, tokens, or service accounts are reused to move from one system to another. In this case, the Cloudflare incident began after the Okta compromise and then expanded because four NHI credentials were not rotated or were incorrectly assumed to be unused.
The governance gap is not simply secret exposure. It is the inability to prove which NHI credentials still matter, which systems depend on them, and how fast they can be safely removed without breaking production.
Key questions
Q: What breaks when an exposed service account is not rotated after a breach?
A: A missed service account stays usable after the incident that exposed it, which lets an attacker reuse valid access instead of forcing a fresh compromise. That is how a single breach expands into lateral movement across multiple systems. The control failure is not just delayed cleanup, but leaving a live identity in place after it should have been removed or reissued.
Q: Why do service accounts and access tokens create more breach risk than human accounts?
A: Service accounts often lack MFA, are reused across systems, and remain active long after the person who created them has moved on. When that happens, attackers can pivot through trusted machine identities instead of fighting interactive authentication. The risk rises when ownership, dependency mapping, and rotation discipline are incomplete.
Q: How do security teams know whether NHI rotation is actually working?
A: Rotation is working only if teams can show that every exposed credential was found, replaced, and validated against downstream dependencies without disrupting production. If the environment still contains unknown service accounts or untracked tokens, rotation is partial at best. The useful signal is complete coverage, not just a completed change ticket.
Q: Who is accountable when stale NHI credentials survive a breach response?
A: Accountability sits with the identity, application, and platform owners who control the credential lifecycle, not just the incident response team. Frameworks such as OWASP Non-Human Identity guidance and NIST CSF both expect ownership, asset visibility, and recovery discipline. If a credential remains active, someone still owns the risk.
Technical breakdown
How exposed NHI secrets become a lateral movement path
Once an attacker has administrative access to an identity system, any unrotated access token or service account becomes a ready-made bridge into downstream tools. In this case, the compromised Okta environment gave the attacker a starting point, and the missed NHI credentials opened paths into Confluence, Jira, and Bitbucket. The technical failure is not only secret leakage. It is that the credential remained valid long enough to be reused across multiple applications, turning one incident into a wider access problem.
Practical implication: maintain an accurate inventory of every NHI credential and rotate exposed secrets before attackers can reuse them.
Why secret rotation fails when identity ownership is unclear
Secret rotation is operationally hard because service accounts are often embedded across applications, pipelines, and integrations. If teams do not know what depends on a credential, they hesitate to rotate it or rotate it too slowly. Cloudflare’s case shows the cost of assuming a token or service account is unused when its dependencies are simply not visible. The failure is not the concept of rotation itself. The failure is the lack of context needed to rotate safely at scale.
Practical implication: tie every service account to an owner, a workload, and a rollback plan before allowing rotation workflows.
Why NHI governance must include decommissioning and dependency mapping
A stale NHI is not harmless just because no one thinks it is active. If an access token or service account still authenticates successfully, it remains a live attack path until it is removed or reissued. The Cloudflare incident shows that decommissioning is part of identity governance, not an optional cleanup step. Without dependency mapping, teams cannot tell whether a credential is truly retired or simply forgotten.
Practical implication: pair rotation with decommissioning workflows that confirm every stale identity is removed from all dependent systems.
Threat narrative
Attacker objective: The attacker’s objective was to turn initial Okta access into broader footholds across internal collaboration and development systems.
- Entry occurred after the attacker gained administrative access to Cloudflare’s Okta system during the earlier Okta breach.
- Credential access followed when one access token and three service accounts were missed during the rotation effort and remained usable.
- Escalation and impact came when those NHI credentials were used to reach Confluence, Jira, and Bitbucket, extending the breach into multiple production systems.
Breaches seen in the wild
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Unrotated NHI credentials create an attack window, not just a hygiene issue. The Cloudflare case shows that a single missed access token and three service accounts were enough to extend an incident from identity compromise into multiple downstream systems. That is the practical difference between secret exposure and operational breach amplification. Practitioners should read this as evidence that NHI lifecycle failure changes incident scope.
The 52 NHI breaches Report remains the clearest proof that secret sprawl is a repeatable failure mode. Cloudflare’s experience matches a wider pattern: credentials are often discovered late, rotated slowly, and reused across systems long after teams believe they are retired. The field should treat this as a lifecycle governance problem, not a one-time response problem.
OWASP Non-Human Identity Top 10 maps directly to this breach pattern. Unused-seeming service accounts, incomplete inventory, and delayed rotation all sit inside the same control boundary. The lesson is simple: if NHI ownership and dependency mapping are weak, attackers inherit the gap before defenders can close it.
Secret rotation only works when decommissioning is equally strong. Cloudflare’s post-incident workload shows that rotation alone does not eliminate exposure if stale identities remain discoverable and usable. The governance conclusion is that lifecycle closure, not just credential replacement, is the control that limits repeat access.
Guide to the Secret Sprawl Challenge helps frame the operational burden behind this breach. The challenge is not only volume. It is the mismatch between the number of secrets, the number of dependent systems, and the speed teams can safely remediate. Practitioners should expect this mismatch to keep driving breach impact until identity ownership is explicit.
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, which helps explain why leaked credentials persist in live environments.
- The operational answer is not more confidence, but faster secret discovery, tighter ownership, and lifecycle controls that shorten the window before reuse.
What this signals
Ephemeral trust debt: when exposed credentials remain valid after discovery, the security programme inherits a hidden liability that outlives the incident. Cloudflare’s case shows that remediation speed matters as much as detection speed, because the attacker’s opportunity persists until the final dependent system is cleaned up.
A mature NHI programme now needs explicit ownership for every service account, token, and integration path. That means rotation can no longer be treated as a background hygiene task. It has to be measured as a containment control, with dependency mapping and decommissioning tied to incident response.
The next operational benchmark is whether teams can remove a compromised credential without guessing what breaks downstream. If they cannot, the environment still depends on undocumented trust relationships, and those relationships are what attackers exploit first.
For practitioners
- Map every exposed credential to a live owner Build a complete inventory of service accounts, tokens, and access keys, then link each one to a named system owner and dependent application before the next rotation cycle.
- Rotate compromised and adjacent NHI credentials together When one identity system is breached, rotate the directly exposed token plus any service accounts that were provisioned through the same trust chain, not just the credential that triggered the alert.
- Block reuse by confirming downstream dependencies Before decommissioning a stale credential, validate every application, pipeline, and integration that still references it so rotation does not leave hidden access paths behind.
- Treat identity cleanup as incident containment Include stale credential removal, dependency review, and re-authentication checks in the containment plan so non-human access cannot persist after the initial breach path is closed.
Key takeaways
- The breach shows that missed NHI rotation can turn one identity compromise into multi-system lateral movement.
- The scale problem is not theoretical, because leaked secrets often take weeks to remediate while attackers can reuse them immediately.
- The control that matters most is complete lifecycle closure, including ownership mapping, safe rotation, and decommissioning of stale identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret rotation and exposure are central to this breach. |
| NIST CSF 2.0 | PR.AC-1 | Identity access control failed when stale NHI access remained usable. |
| NIST Zero Trust (SP 800-207) | The breach depended on trusted credentials moving laterally across systems. |
Apply continuous verification and limit trust propagation between identity systems and downstream apps.
Key terms
- Non-Human Identity: A non-human identity is any credentialed entity used by software, infrastructure, or automation rather than a person. It includes service accounts, tokens, API keys, and certificates. In breach analysis, the critical issue is not whether the identity is human or machine, but whether it can still authenticate and move laterally.
- Secret Rotation: Secret rotation is the replacement of credentials so a previously exposed token, key, or password can no longer be reused. It only works when teams know where the credential is used, who owns it, and what downstream systems depend on it. Without that context, rotation becomes risky or incomplete.
- Lifecycle Decommissioning: Lifecycle decommissioning is the controlled removal of an identity after it is no longer needed. For NHI governance, this means revoking access, deleting unused credentials, and confirming that dependent systems no longer rely on them. It is the point where stale trust is actually closed, not just reviewed.
- Lateral Movement: Lateral movement is the act of using one compromised access path to reach additional systems or higher-value resources. In NHI incidents, reused tokens and service accounts often make this easier because they are already trusted by multiple applications. The control problem is trust propagation across systems.
Deepen your knowledge
NHI lifecycle governance, secret rotation, and decommissioning are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a breach-response process for service accounts and tokens, it is worth exploring.
This post draws on content published by Oasis Security covering the Cloudflare breach: Securing Non Human Identities: Lessons from the Cloudflare Breach. Read the original.
Published by the NHIMG editorial team on 2026-05-01.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org