TL;DR: Cloudflare’s outage was triggered by a permissions change that expanded an internal feature file until it broke production systems, showing how standing privileges can create operational blast radius even without an attacker, according to Apono. The incident reinforces that access scope and permanence are reliability controls as much as security controls.
At a glance
What this is: Apono examines Cloudflare’s outage and shows how a permissions change inside an internal system cascaded into a production failure when standing privileges were too broad and too permanent.
Why it matters: IAM and PAM teams should treat privilege scope as a resilience control because the same access model that enables routine administration can also amplify accidental outages across cloud and platform services.
Context
Standing privileges are access rights that remain continuously available instead of being granted only for a task. In Cloudflare’s case, a permissions change in an internal database workflow caused a Bot-Management feature file to grow beyond its expected limit and propagate failure across the network.
The governance gap is not limited to attackers or stolen credentials. When service accounts, automation pipelines, or human operators retain broad permanent access, a normal administrative action can become a system-wide reliability event rather than a contained change.
For identity programmes, the key question is whether access is sized and timed to the task or left in place as a permanent operating assumption. That distinction now affects uptime, change safety, and auditability as much as breach prevention.
Key questions
Q: What breaks when standing privileges are left in place for cloud infrastructure changes?
A: Standing privileges increase the chance that a routine change can affect shared systems far beyond the intended task. In cloud environments, that can turn one valid administrative action into a production outage, a security incident, or both. The problem is not just misuse by attackers. Persistent access expands the blast radius of legitimate work.
Q: Why do standing privileges increase outage risk even without an attacker?
A: Because the same always-on rights that make administration convenient also let a normal human or service account make changes that propagate into critical systems. When the access is broad, persistent, and tied to shared infrastructure, one misstep can affect many downstream services. The risk comes from failure propagation, not only from malicious abuse.
Q: How can teams tell whether privilege scope is too broad for operational safety?
A: Look for identities that can modify shared inputs, production configuration, or automation outputs without a narrow task window or explicit containment. If a single change can affect many nodes, that access is wider than the operational risk justifies. The best signal is whether the privilege model limits the blast radius of an ordinary mistake.
Q: Should IAM teams prioritise just-in-time access for reliability or for security?
A: For both. Just-in-time access reduces the time a privileged identity can affect sensitive systems, which lowers the chance of misuse and the chance of accidental propagation. In environments where access can influence production state, JIT is a resilience control as much as an attack-control mechanism.
Technical breakdown
How a permissions change can break a downstream pipeline
A permissions change is not just an authorization event when the affected system feeds generated output into production. In this incident, the internal database workflow produced a feature file that was consumed across Cloudflare’s network, so a change in one place altered a file that had broad runtime impact. The technical failure came from the coupling between privilege and output generation, where the data path assumed the file would stay within a narrow size and shape. Once that assumption broke, valid and invalid states began alternating until the failed state dominated. This is a governance problem expressed through software behaviour, not a classic intrusion chain.
Practical implication: Map which privileged changes can alter shared runtime artifacts and treat those paths as high-risk change surfaces.
Why standing privileges increase operational blast radius
Standing privileges are persistent permissions that remain active outside the moment of need. In cloud and platform environments, that permanence means a single account or role can touch infrastructure that has far wider consequences than the original task suggests. The risk is not only that an attacker could abuse the access, but that an ordinary operator or service account could make a change that propagates into production instability. In this case, the access needed to modify an internal system was apparently sufficient to affect globally distributed services. That is the real control lesson: persistent permission widens the blast radius of both mistakes and malicious actions.
Practical implication: Review persistent access paths to systems whose output feeds production, not just the systems that hold sensitive data.
How just-in-time access contains change risk
Just-in-time access means privileges are issued only when needed, for a specific task, and then removed automatically. That model narrows exposure by limiting how long a given identity can influence a sensitive system and by forcing the access grant to match a concrete operational purpose. It does not eliminate misconfiguration, but it does reduce the chance that a permanent right remains available for an accidental or overly broad change. In environments with databases, Kubernetes, cloud control planes, and automation identities, the control value comes from constraining both scope and duration. The key is that access becomes an event, not a default state.
Practical implication: Use JIT for high-impact administrative paths so sensitive rights expire before they can cascade into wider failure.
Threat narrative
Attacker objective: There was no attacker objective because the incident was operational, not malicious.
- Entry was not malicious in this case: a permissions change in an internal Cloudflare database workflow altered how a recurring query generated a feature file.
- The change created an oversized file that exceeded a built-in limit, and systems loading it began failing immediately across the network.
- Mixed valid and invalid outputs caused the environment to oscillate before locking into a failed global state.
- Impact was widespread service disruption, with major internet properties returning internal server errors until service was restored.
Breaches seen in the wild
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Standing privileges are a resilience problem, not only a security problem. Cloudflare’s outage shows that persistent access can turn an ordinary administrative change into a broad production failure. When the same identity can keep modifying sensitive infrastructure without task-scoped boundaries, the blast radius extends from authorization into availability. Practitioners should treat privilege permanence as part of reliability engineering.
Access governance failed at the point where control assumed the change was local. The permissions model allowed a modification that affected a recurring query and a downstream feature file with network-wide consequences. That means the real gap was not merely excessive permission, but insufficient containment between change authority and production impact. Teams should redesign high-impact paths so a single edit cannot propagate system-wide.
Zero standing privilege now applies to outage prevention as much as breach prevention. The value of JIT is not just shrinking attacker dwell time; it is also reducing the chance that a routine action can persist long enough to destabilise production. In cloud operations, privilege duration and privilege scope are operational controls with direct uptime implications. IAM and PAM teams should manage them accordingly.
Standing privilege debt: persistent access accumulates hidden operational risk because the same rights used for maintenance can later amplify a mistake into an outage. That debt grows where service accounts, automation, and human admin paths are left always-on. The implication is that privilege reviews must consider failure propagation, not only unauthorized access.
Non-human identities inherit the same failure mode as human admins, but at machine speed. Service accounts and automation tokens can hold broad, permanent rights that alter shared infrastructure without the same scrutiny applied to user access. The operational lesson is that NHI governance must cover change authority, not just credential storage. Practitioners should rightsize non-human access around the blast radius of the systems it can affect.
From our research library:
- 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
What this signals
Standing privileges now need to be governed as change-amplifiers. The operational question is no longer only who can access a system, but whether that access can alter a shared artifact that fans out across production. IAM, PAM, and cloud teams should rank privileges by blast radius, not just by sensitivity.
Zero standing privilege is a containment pattern for reliability as well as security. When access is ephemeral, the window for a bad change narrows and the chance of a persistent misconfiguration falling across a live environment drops. That makes JIT especially relevant for database admins, platform engineers, and service identities that touch shared control paths.
For practitioners
- Map high-impact change paths Identify internal workflows where a permissions change can alter shared runtime artefacts, feature files, or production configuration and classify them as high blast-radius paths.
- Replace always-on admin rights Move human admins and service accounts that touch sensitive production systems to just-in-time access so elevated rights exist only for the task window.
- Tighten non-human identity scope Review service accounts, automation pipelines, and API keys that can modify production inputs and remove any rights that exceed the smallest necessary change scope.
- Add change-to-impact guardrails Require approvals, logging, and automatic expiry for modifications that can cascade across distributed services, especially where a single file or query feeds many nodes.
- Test failure containment Simulate oversized outputs, invalid records, and oscillating states in pre-production so you can verify that a bad change cannot propagate globally.
Key takeaways
- Standing privileges can turn an ordinary permissions change into a system-wide outage when access reaches shared production pathways.
- Cloudflare’s incident shows that access scope and permanence affect availability, not only security posture.
- IAM teams should treat high-impact privileges as resilience risks and move them toward just-in-time, task-scoped access.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Persistent broad access is the control problem this outage illustrates for non-human identities and service accounts. |
| NHI-07 — Long-Lived Secrets | Long-lived access paths increase the window in which a single change can cascade into failure. | |
| Recommendation — Reduce always-on access for service accounts and automation that can affect production systems. Shorten privilege duration and rotate access paths that remain valid outside the task window. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether permissions are scoped tightly enough to prevent operational blast radius. |
| Recommendation — Review entitlements so production-facing permissions match the minimum required change scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the main preventive control against broad change authority in this outage pattern. |
| Recommendation — Apply least privilege to administrative paths that can influence shared production artefacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and access scope govern whether human and non-human identities retain unsafe standing access. |
| Recommendation — Harden account management so privileged identities do not retain unnecessary standing access. | ||
Key terms
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org