Last updated: October 29, 2026

On September 22, 2026, Netskope's Secure Web Gateway, Cloud Firewall and Proxy Chaining services were impaired across all of its data plane data centers for about four hours, because Google began throwing CAPTCHA and security challenges at traffic leaving Netskope's egress IPs. The lesson is structural: a cloud proxy's shared egress IPs are a failure point you can't fix from your side, and an on-device SWG like dope.security, which sends traffic straight out from the user's own connection, doesn't have that failure mode at all.

Most SWG outages start with a bad config push or a maintenance window gone sideways. This one started somewhere else entirely: on Google's side of the internet. Nothing inside your network changed. Nothing on your laptops changed. Your users simply started seeing challenges and broken Google services because they were sharing an address with thousands of other companies' traffic.

If you're weighing what this means for your renewal, we keep a running, sourced comparison of Netskope alternatives and competitors. This post sticks to the incident itself, why it happened, and the questions it should raise about any cloud-proxy architecture.

What happened during the Netskope outage on September 22, 2026?

Netskope's own Trust Portal is the primary record here. The incident (number 6529345) was opened at 17:01 UTC on September 22 and listed the affected scope as all data plane data centers. The services named were Cloud Firewall, Gateway, Proxy Chaining and Secure Web Gateway.

By 17:44 UTC Netskope said it was investigating. At 19:01 UTC the update said Netskope was coordinating with Google while Google worked on a fix for the increased security challenges. At 21:01 UTC the incident was marked resolved, with Netskope noting that telemetry showed no further CAPTCHA errors or increased security challenges, and that it would keep monitoring before closing the incident formally.

So the timeline, from Netskope's own portal, is roughly four hours of impairment across the data plane for one of the most-used destinations on the internet. For a typical company running Google Workspace, Google Search and Google-hosted login flows, that's not a cosmetic issue. It's a workday.

A few things the public record does not show, and that we won't speculate about: the exact trigger on Google's side, how many tenants were affected, and whether a full root-cause analysis was published to customers. If you're a Netskope customer, the RCA is the document to ask your account team for.

Why did Google CAPTCHAs break a secure web gateway?

Because a cloud proxy makes thousands of users look like they come from a small pool of shared IP addresses. That's how every proxy-in-the-cloud SWG works, and it's not unique to Netskope.

Here's the mechanism in plain terms. Your user's browser connects to the nearest Netskope NewEdge data center. Netskope decrypts, inspects and then re-originates the request to the destination from one of its own egress IPs. To Google, that request doesn't come from your user. It comes from Netskope.

Large web platforms constantly score incoming traffic for abuse. When an unusual volume or pattern shows up from a set of IPs, they respond with challenges: CAPTCHAs, interstitials, extra verification. That's a reasonable defense for Google. It's a terrible experience for an employee who just wants to open a spreadsheet, and it turns into an outage when the challenges hit every tenant sharing those egress addresses at once.

The uncomfortable part for security leaders is that nothing in your own change control could have prevented it. You can't tune a policy to make Google trust a vendor's IP range. You wait for two other companies to coordinate a fix.

Is this a one-off, or part of a pattern?

To be fair to Netskope: every large cloud security vendor has incidents, and Netskope publishes its incident history openly on its Trust Portal, which is more transparency than some competitors offer. Netskope was also named a Leader in the 2026 Gartner Magic Quadrant for Security Service Edge. This is a capable vendor.

But the architecture keeps producing the same kind of event. Netskope's Trust Portal shows an incident affecting all management plane data centers in May 2026, and regional data plane incidents at SJC1, SV5 and FRA2 between July and September 2026. Those are documented, dated entries on the vendor's own status history, not third-party guesses.

And Netskope isn't alone. We've documented the same pattern in Zscaler's outage history and control-plane incidents and in the Cloudflare One Gateway outage from October 20, 2026. Different vendors, different triggers, same root shape: when all of your users' traffic depends on someone else's data centers, someone else's bad day becomes yours.

Shared egress IPs are a new failure mode for cloud proxies

Most SWG resilience conversations focus on two risks: the vendor's control plane (can admins log in and push policy?) and the vendor's data plane (can traffic flow through the PoPs?). September 22 adds a third: reputation of the vendor's egress.

Shared egress creates three practical problems that are easy to miss in a proof of concept:

• Collateral reputation. Your traffic shares addresses with every other tenant on that PoP. If another tenant's traffic, or a burst of automated traffic, trips a destination's abuse controls, your users can get challenged too.
• Geolocation weirdness. Destinations see the PoP's location, not the user's. That can trigger region-specific content, extra login verification or fraud checks for traveling and remote staff.
• Allowlisting friction. Partners and SaaS vendors that IP-allowlist your company now need the vendor's egress ranges, which change and are shared with other customers.

Vendors offer workarounds, such as dedicated egress IPs, usually as an extra line item. That fixes allowlisting. It doesn't change the fact that every request still has to make the round trip through the vendor's infrastructure.

Cloud proxy SWG vs. on-device SWG: what changes during an incident like this

The cleanest way to evaluate the September 22 incident is to ask what each architecture would have done at 17:01 UTC that day. Here's the head-to-head.

Cloud proxy SWG (Netskope, Zscaler, and similar)

Every web request leaves the device, travels to a vendor data center, gets decrypted and inspected there, and is re-sent to the destination from the vendor's egress IP. When the destination starts challenging those egress IPs, every user steered through the affected data centers sees it. Recovery depends on the vendor and the destination working it out.

On-device SWG (dope.security)

The dope.endpoint agent decrypts and inspects traffic on the laptop itself, then sends the request directly to the destination from the user's own internet connection. Google sees the user's home, office or hotel IP, the same as it would with no SWG at all. There's no shared vendor egress for a destination to challenge, so this specific failure can't happen.

Side by side

• Egress identity: a cloud proxy re-originates traffic from shared vendor IPs; dope.security traffic leaves from the user's own connection.
• Blast radius: a cloud proxy incident can hit every tenant on the affected data centers at once; an on-device SWG has no shared data plane for web traffic to fail.
• Inspection location: a cloud proxy decrypts in the vendor's data center; dope.security does SSL inspection on the device, so decrypted traffic never leaves the laptop.
• Your control during the incident: with a cloud proxy, you usually wait or fail open via steering changes; with dope.security, there's nothing in the path to fail over.

The everyday cost hiding behind the outage: the detour

Outages make headlines. The detour costs you every single day. Netskope's own published SLA targets under 10 ms of added latency for non-decrypted traffic but 50 ms for decrypted traffic, which is a 5x penalty on exactly the traffic you most want inspected. We've unpacked those numbers in our breakdown of Netskope latency and decryption performance.

Fifty milliseconds sounds small until you remember a modern web app makes dozens of requests to render one page. Industry measurements put cloud-proxy detours at roughly 40 to 80 ms when users sit near a point of presence, and 150 to 400 ms when they're far from one. Remote staff, travelers and international offices pay the most.

See the detour for yourself. Our Fly-Direct Speed Test measures your live connection and shows how common apps load through a legacy cloud proxy versus on-device inspection. Run it on the dope.security Fly-Direct SWG page, or book a 20-minute demo and we'll walk through it with your own numbers.

Takeaway: every request that detours to a data center pays a latency tax on normal days and inherits that data center's problems on bad ones.

What should Netskope customers ask after September 22?

If you run Netskope today, you don't need to panic. You do need answers. These are the questions we'd put to any cloud-proxy vendor after an incident like this:

• Root cause: What specifically triggered the Google challenges on your egress IPs, and what has changed so it can't recur?
• Egress design: How many tenants share the egress ranges my users exit from? Are dedicated egress IPs included in my contract or an add-on?
• Fail-open behavior: During a data plane incident, what happens on my endpoints by default? Do users lose connectivity, or does traffic bypass inspection entirely?
• Admin visibility: Were dashboards, logs and the console available to my team throughout the incident?
• Credits: Does a four-hour, all-data-plane impairment trigger an SLA credit under my agreement?

And one question to ask yourself: how many of your users' daily apps depend on the vendor's egress reputation staying clean with Google, Microsoft and every other major platform?

How does dope.security handle its own cloud being unavailable?

Fair question, since no architecture is magic. dope.security still has a cloud: the dope.console for policy and analytics, and dope.cloud services for web categorization and malware lookups. The difference is that user traffic never routes through it.

If the dope.endpoint can't reach dope.cloud's category or malware services, fallback mode kicks in. Sites already cached keep their policy. For new, uncached sites, you choose the behavior: with Fail Close off (the default), new sites are allowed; with Fail Close on, they're blocked. Either way, users keep browsing direct, with SSL inspection still running on the device, and policy already on the endpoint keeps enforcing.

That's the core of the Fly Direct idea. The security runs where the user is, so a problem in somebody's data center doesn't become a problem on your users' screens. It's also why rollouts move fast: a Fortune 100 company scaled from 900 to over 18,000 devices in a matter of weeks, which you can read about in our Fortune 100 deployment story.

Should you replace Netskope over one outage?

Probably not over one outage alone. Replace a vendor because the architecture keeps costing you: in latency your users feel, in incidents you can't control, in agent and steering complexity your team maintains, and in a per-module price list that grows every renewal. If the Netskope Client and its steering configuration already take up more of your week than they should, September 22 is a good prompt to run a side-by-side.

The test is simple. Put dope.security on a pilot group alongside your current SWG. Compare page load times, ticket volume and admin hours for two weeks. Then decide with data, not with a status page.

The thesis, restated: the September 22 incident wasn't a bug you could have tuned away. It was the predictable result of routing everyone's traffic through shared vendor IPs, and the only way to remove that failure mode is to stop routing traffic through someone else's data center. Start a free dope.security trial or book a demo to see on-device inspection on your own fleet.

Frequently Asked Questions

Is Netskope down right now?

Netskope publishes live and historical service status on its Trust Portal at trustportal.netskope.com, which is the authoritative place to check. Third-party outage aggregators can show user reports faster, but treat them as a signal rather than confirmation. If your users are seeing CAPTCHAs or blocked Google services through Netskope, check the portal for an open data plane incident.

What caused the Netskope outage on September 22, 2026?

According to Netskope's Trust Portal, the incident was tied to Google CAPTCHA services and increased security challenges hitting Netskope traffic, affecting Secure Web Gateway, Cloud Firewall, Gateway and Proxy Chaining across all data plane data centers. It opened at 17:01 UTC and was marked resolved at 21:01 UTC after Netskope coordinated with Google on a fix. The public notice does not include a full root-cause write-up.

How often does Netskope have outages?

Netskope's Trust Portal lists a documented pattern of incidents in 2026, including an all-management-plane incident in May and regional data plane incidents at SJC1, SV5 and FRA2 between July and September. Every cloud security vendor has incidents; the useful question is how many of them can reach your users. With an on-device SWG like dope.security, web traffic doesn't route through vendor data centers, so data plane incidents of this kind don't apply.

Would an on-device SWG have been affected by the Google CAPTCHA issue?

No, not by this failure mode. dope.security inspects traffic on the laptop and sends it directly to the destination from the user's own internet connection, so Google sees the user's IP, not a shared vendor egress IP. There was no shared egress pool for Google to challenge.

Does Netskope offer dedicated egress IPs?

Cloud-proxy vendors, including Netskope, generally offer dedicated egress IP options, typically as an additional purchase; confirm the current terms with your account team. Dedicated IPs help with partner allowlisting and reduce exposure to other tenants' reputation, but your traffic still travels through the vendor's data centers. An on-device SWG avoids the question because traffic leaves from the user's own connection.

What happens to dope.security users if the dope.security cloud is unreachable?

Browsing continues direct from the device and SSL inspection keeps running locally. If the endpoint can't reach dope.cloud's category or malware services, cached sites keep their policy and new sites follow your Fail Close setting: allowed when it's off (the default) or blocked when it's on.