Every year or two, a major cloud proxy has a bad afternoon and a few million users go dark at the same time. The incident report arrives the next day. It is always something different and always the same: a single point of enforcement in someone else’s data center.
This post is for teams who have lived through that outage at least once and are ready to stop calling it bad luck. It covers why cloud SWG outages keep happening, what changes when enforcement moves to the endpoint, and how to evaluate a replacement without getting lost in datasheet theater.
The Short Answer
A cloud-hosted secure web gateway works by terminating every encrypted session in a vendor data center before letting traffic continue to the destination. When that data center has a bad day, every user routed through it is offline. Moving to an endpoint-first architecture removes the vendor data center from the critical path, so a vendor outage stops being a user outage.
Branding aside, this is the only architectural difference that matters for uptime. Everything else is a feature comparison.
Why Cloud SWG Outages Keep Happening
The failure modes are well understood at this point.
A single PoP serves a region. When the PoP has a bad config push, an upstream peer that flaps, or a capacity spike from a noisy neighbor, every tenant on that PoP feels it. Some vendors fail over to a neighboring region, which helps if the neighbor is not also overloaded.
The management plane is a second failure domain. If the policy control service goes down, agents stop enforcing or stop fetching updates. Users experience this as random breakage with no obvious cause.
The third failure mode is a bad release. A new engine version rolls out, introduces a TLS regression, and specific SaaS apps stop loading until the vendor pulls the release.
None of these modes are fixable by better monitoring. They are properties of routing every packet through someone else’s infrastructure.
A Decade of Notable Cloud SWG Incidents
The pattern is consistent across vendors. Numbers and dates vary; the architectural cause does not.
| Year | Incident Type | User Impact |
|---|---|---|
| 2020 | Major PoP outage, regional | Whole time zone offline for hours |
| 2022 | Config push error | Global blocking spike, rolled back in 90 minutes |
| 2023 | Management plane degradation | Policy updates stalled for a day |
| 2024 | Engine release regression | Specific SaaS apps broken for 4 hours |
| 2025 | BGP peering event | Traffic detoured, latency 3x normal |
What Changes When Enforcement Moves to the Endpoint
An endpoint-first secure web gateway ships the policy engine to the laptop. The agent evaluates URL category, runs SSL inspection locally, and connects directly to the destination. No vendor PoP in the middle. No regional failure domain. No BGP event that takes out a time zone.
The design implications matter beyond uptime.
Fly-Direct Traffic
Connections open to the origin, not to a proxy. Native HTTP/2 stays intact. Users see full link speed minus a small CPU cost. On a fiber line at home, the difference between direct and detoured is often 100 ms on cold connections and measurable MB/s on warm ones.
Local Enforcement Survives Management Outages
If the management plane has a bad hour, the agent keeps the last known policy and continues to enforce. The security control does not disappear just because the vendor’s dashboard is down. This is what “resilient” actually means, and it is the default behavior of a properly designed endpoint agent.
Same Policy on Mac and Windows
Cloud SWG vendors often ship a mature Windows client and a vestigial Mac one. Endpoint-first products build Mac and Windows agents with the same feature set, deployed through Jamf or Intune with one policy model. Teams with a lot of MacBooks stop paying the “Windows-first vendor” tax.
Architecture, not branding, is the real differentiator. If your vendor can describe the difference in one sentence and yours cannot, you have already learned something.
Evaluation Criteria for Switching
A serious switch is not a rip and replace. It is a pilot that gives you measurable answers on five dimensions.
1. Failure Domain
What happens when the vendor has a regional outage? An endpoint-first swg should keep enforcing and routing traffic direct. A cloud-first one will still route through the affected region, just to a different PoP if you are lucky.
2. Platform Parity
Deploy the agent on a representative Mac and a representative Windows laptop. Run the same policy against the same test sites. Parity means byte-for-byte equivalent behavior, not “most features on both.”
3. Performance Cost
Benchmark TTFB, handshake time, and throughput with inspection on. The target is a detectable but small cost. Anything above 10 percent throughput loss or 100 ms added handshake is worth a deeper look. Measure endpoint RAM and CPU under normal browsing. A well-built agent stays under 100 MB.
4. Policy and DLP Model
A modern product should offer zero-config DLP for PII, PCI, and PHI, shadow AI controls, and explainable block decisions. Run a real document through the DLP engine and read the reason string. If it says “pattern match” and nothing else, the product is behind the market.
5. Deployment and Rollback
Package the agent through your MDM, push policy, revert policy, and uninstall. The whole loop should take minutes, not a change window. If rollback is painful, migration is painful, and the team will resist the switch.
FAQ
What is better than Zscaler?
Better is architecture-dependent. For teams that prioritize uptime, an endpoint-first SWG removes the vendor data center from the critical path and eliminates the failure mode that most cloud SWG outages share. For teams that need an agentless proxy for unmanaged devices, a hybrid design makes sense. The right answer follows from the failure domain the team cares about.
What is the Microsoft equivalent of Zscaler?
Microsoft offers Entra Internet Access as part of Global Secure Access. It is a cloud-hosted SWG, so it shares the same architectural tradeoffs as other cloud proxies, including regional failure domains. Teams evaluating a Microsoft-native path still need to benchmark uptime and performance against endpoint-first alternatives.
Is there a Zscaler alternative that runs on the endpoint?
Yes. Endpoint-first products like dope.security run the SWG engine directly on the laptop, inspect TLS locally, and route traffic direct to the destination. The management plane is cloud, but the data plane is not, so vendor outages do not take users offline.
How long does a switch from cloud SWG to endpoint SWG take?
A 50-seat pilot takes two to four weeks. A full migration for a few thousand seats takes two to four months, driven mostly by MDM rollout cadence and policy reconciliation. Teams on Jamf and Intune typically complete the technical work faster than the change-management work.