Summary
- Cloudflare reported disruption to Gateway traffic governed by identity policies between 03:20 and 06:32 UTC on 20 October; rules without identity conditions were unaffected.
- A fix was deployed at 04:44 UTC, with edge services restored by 05:46 UTC and the Access API returning to normal at 06:14 UTC.
- The public incident record did not identify a cause, affected customer count, data exposure, or malicious activity.
Cloudflare restored its Zero Trust connectivity services on 20 October after a fault interrupted traffic passing through Cloudflare One Gateway when access decisions required an identity condition. The provider said the incident affected all routes into Gateway for that class of policy, while Gateway rules without identity conditions continued operating.
Cloudflare opened the incident at 03:20 UTC and declared it resolved at 06:32 UTC, just over three hours later. Its initial notice also reported trouble with the management dashboard. Recovery took place in stages: traffic processing and application logins returned before the Cloudflare Access application programming interface was fully restored.
The failure concerned a service that helps determine which requests should be allowed through a centrally managed security gateway. A destination application can remain operational while access to it becomes unreliable if the gateway cannot process the relevant policy decision. Cloudflare did not publish a root cause in the updates reviewed, and the status record does not identify malicious activity or a data compromise.
Gateway traffic recovered before the Access API
At 04:40 UTC, Cloudflare said it had identified the problem and was implementing a fix. It reported four minutes later that the fix was in place and monitoring had begun. The company did not identify the software component or configuration responsible for the interruption, so the public record does not support attributing it to a particular deployment change.
At 05:46 UTC, Cloudflare said edge functionality had fully recovered, including Cloudflare Access logins and Secure Web Gateway connectivity. The Access API was still experiencing above-normal error rates and latency. Those remaining problems cleared by 06:14 UTC; Cloudflare continued monitoring until the incident was closed at 06:32 UTC.
That sequence separates access to applications from the systems used to manage and automate their protection. Users could regain the ability to sign in and send traffic through the security service before API operations returned to normal. Businesses relying on the API to administer or integrate access controls could therefore have experienced a different recovery timeline from people trying to reach a protected application.
Cloudflare One combines several security functions rather than operating as a single authentication service. Gateway applies web and network traffic policies, while Access protects applications using identity and other conditions. They can share information about users and devices, but an interruption in identity-dependent Gateway decisions does not establish that every Access application was unavailable, or that the provider’s wider network failed.
The phrase “all onramps” in the incident notice referred to ways of sending traffic into the affected Gateway path. It did not mean every Cloudflare product or every customer connection was disrupted. The explicit exception for policies without identity conditions also limits what can be inferred about the breadth of the outage.
Policy enforcement is an availability dependency
Identity conditions may be used to vary which websites, internal tools, or other destinations a worker can access. Cloudflare’s access architecture guidance describes combinations of authentication, client connectivity and device checks that allow companies to protect resources without exposing them directly to the internet. These arrangements depend on policy services making decisions when requests arrive.
A failure of that decision path can prevent legitimate work even if the underlying application and its data remain intact. That is distinct from an attacker bypassing access checks: Cloudflare’s updates describe impaired connectivity and service errors, not evidence that unauthorised traffic was admitted. The company likewise reported no customer-level exposure figures or duration measurements for individual organisations.
Administrative access creates an additional dependency during an outage. Operators trying to determine which policies are affected may need the dashboard or an API to inspect settings, gather logs, and make authorised changes. Cloudflare’s timeline shows why restoration of the edge does not necessarily mean every management function has returned at the same moment.
The provider’s final resolution time is consequently not a reliable measure of how long any particular organisation was disrupted. A connection using an unaffected Gateway rule may have continued working, while an identity-dependent path encountered errors earlier in the incident and an API integration remained impaired after edge traffic recovered.
By the morning of 20 October, Cloudflare had recorded restored Gateway connectivity, Access logins, and normal Access API performance. Its public status history did not yet explain the original failure mechanism or quantify the extent of customer disruption.
