Topic starter
06/06/2026 2:02 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Securing Non Human Identities: Lessons from the Cloudflare Breach”.
By the numbers:
- Cloudflare had to rotate more than 5000 secrets during the incident response effort.
Key questions
Q: What breaks when idle NHI secrets are not rotated or revoked?
A: When idle secrets are not rotated or revoked, the organisation loses the distinction between active and abandoned access.
Q: Why do service accounts with standing privilege create such high breach risk?
A: Because a stolen or leaked machine credential often has direct access to production systems, support tools, or data stores without extra user prompts.
Q: How do you know if NHI secret rotation is actually working?
A: Look for fewer unowned secrets, shorter exposure windows, and successful validation after each change.
Practitioner guidance
- Audit exposed NHI credentials immediately Build an incident-time inventory of every token, service account and secret that was touched by the compromise, including identities assumed to be unused.
- Map dependency chains before rotating Document which applications, collaboration tools and build systems depend on each secret so revocation does not interrupt production services.
- Assign explicit ownership for every service account Require a named owner and a decommission date for each non-human identity so no credential is left in a default state of indefinite trust.
Bottom line: The breach shows that a missed token or service account can remain dangerous long after the triggering incident has been recognised.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
06/06/2026 3:29 am
Unrotated NHI secrets create a trust window that outlives the incident response window: This breach worked because the organisation assumed exposed credentials could be retired before they were weaponised. That assumption failed because service accounts and tokens remained valid after the Okta compromise, turning cleanup delay into attacker opportunity. The practical conclusion is that the risk is not just exposure, but the duration of survivable trust.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams decide which NHI secrets to revoke first after a breach?
A: Prioritise the identities that combine exposure, privileged reach and uncertain ownership. In practice, that means tokens and service accounts tied to collaboration, source control or build systems should move ahead of low-value credentials because they expand the attacker's options most quickly.
👉 Read our full editorial: Cloudflare breach lessons expose the cost of unrotated NHI secrets
This post was modified 5 days ago by NHI Mgmt Group