Amar Jeer

Secure Web Gateway Architecture Explained: 3 Generations Compared

October 16, 2026

MIN READ

Secure Web Gateway Architecture Explained: 3 Generations Compared

Last updated: October 2026

Secure web gateway architecture comes in three generations. Gen 1 is an appliance in the office. Gen 2 is a cloud proxy where traffic detours through vendor data centers. Gen 3 is an on-device proxy that inspects traffic on the endpoint and sends it directly to the destination. dope.security is the Gen 3 secure web gateway, and that architecture is why it's faster, more private, and easier to run than Gen 1 or Gen 2 SWGs.

Feature lists for SWGs look similar. Every vendor claims SSL inspection, URL filtering, and malware protection. Architecture is where they actually differ, and it decides latency, privacy, outage risk, and how much work your team does.

Our #1 pick: dope.security. The on-device, Gen 3 secure web gateway. Inspection, policy, and DLP run on the laptop, with a cloud control plane for management. See the next-gen SWG comparison.

Key takeaways

Every SWG has a data plane (where traffic is inspected) and a control plane (where policy is managed).
Gen 1 puts the data plane in your office. Gen 2 puts it in the vendor's cloud. Gen 3 puts it on the device.
Moving the data plane to the device removes the network detour and third-party decryption.
The control plane stays in the cloud, so policy still reaches every device in under a minute.
dope.security is the leading Gen 3 SWG architecture.

What are the components of a secure web gateway?

Every SWG has the same building blocks, arranged differently.

Component	Job
Traffic interception	Gets web requests to the inspection engine
TLS termination	Decrypts HTTPS so content can be inspected
Policy engine	Applies URL, app, and data rules per user and group
Threat engines	Scans downloads, checks reputation and categories
Data protection	DLP on uploads and prompts
Logging	Records transactions for analytics and SIEM
Control plane	Console, identity sync, policy distribution

The data plane is everything that touches live traffic. The control plane is everything admins touch. Where you put the data plane is the architectural decision.

Gen 1: What is appliance-based SWG architecture?

A proxy appliance sits at the office edge, and traffic passes through it on the way out.

Interception: Network routing or explicit proxy settings.
TLS termination: On the appliance.
Remote users: VPN back to the office, then out through the appliance.

This worked when everyone sat in one building. It breaks down when people work from home, travel, or sit in offices without an appliance. Capacity planning, hardware refresh, and VPN hairpins all become your problem.

Gen 2: What is cloud-proxy SWG architecture?

The proxy moves to the vendor's data centers, called points of presence (PoPs). Traffic is steered there by an agent, PAC file, or tunnel.

Interception: Client connector, PAC file, or GRE/IPsec tunnel from offices.
TLS termination: In the vendor PoP.
Remote users: Routed to the nearest PoP, then out to the destination.

Gen 2 solved the hardware problem. It created three new ones:

Latency. Every request takes a detour. Roughly 40 to 80 ms near a PoP, 150 to 400 ms far from one.
Third-party decryption. Your users' HTTPS sessions are opened in someone else's data center.
Shared outage risk. If a PoP has a problem, everyone routed there feels it.

Most SSE platforms, including Zscaler, Netskope, and Prisma Access, use this model. For how it plays out in SASE programs, see our guide to the best secure web gateway for SASE.

Gen 3: What is on-device SWG architecture?

The data plane runs on the endpoint. The control plane stays in the cloud. dope.security calls this Fly Direct.

Interception: A local proxy on the device.
TLS termination: On the device.
Remote users: Same as everyone else. Traffic goes straight to its destination after local inspection.

The dope.cloud handles management: identity sync, policy distribution, analytics, and DLP classification. dope.endpoint handles enforcement.

Architecture layer	Gen 1 appliance	Gen 2 cloud proxy	Gen 3 on-device (dope.security)
Where traffic is inspected	Office	Vendor PoP	Endpoint
Network detour	VPN hairpin for remote	Yes, to PoP	None
Who decrypts TLS	You, in the office	Vendor	The user's device
Scales with	Hardware	Vendor data center capacity	Endpoints you already own
Single point of failure	Appliance	PoP or region	None in the data path
Offline protection	No	No	Yes, cached policy
Remote and travel coverage	Weak	Depends on PoP reach	Same everywhere

Why is on-device the best secure web gateway architecture?

Because it keeps every SWG capability and removes the detour.

Performance

There's no PoP in the path, so dope.security runs up to 4x faster than legacy SWGs. HTTP/2 stays on by default. The agent uses under 100 MB of RAM.

Privacy

TLS is decrypted on the device, and decrypted data never goes to a third-party data center to be opened. That simplifies data residency conversations. More detail is in our breakdown of the best secure web gateway for SSL inspection.

Resilience

No PoP in the path means no PoP outage to wait out. If the device goes offline, cached policy still enforces. Fail-safe mode allows trusted, company-defined sites if the dope.cloud is ever unreachable.

Visibility

Because the proxy sits on the device, logs include process name and process call tree. You can see which application made a request, not just which IP.

Does on-device mean policy is harder to manage?

No. The control plane is centralized. Admins work in one console, dope.console, and policy reaches every endpoint in under a minute.

Control plane function	How it works in dope.security
Identity	Sync users and groups from Entra ID or Google
Policy	Base Policy with inheritance, per-section customization
Distribution	Pushed to endpoints in under a minute
Analytics	Web, Shadow IT, AI Usage Analytics
Investigation	Dopamine agent answers plain-language questions in under 10 seconds
Integrations	SIEM export, public API, Dope MCP Server

Where do CASB and DLP fit in SWG architecture?

In Gen 3, they share the same data plane. Cloud Application Control and Dopamine DLP inspect traffic on the device, using the same TLS session the SWG already opened.

Cloud Application Control restricts SaaS to corporate tenants: Microsoft 365, Google, ChatGPT, Claude, GitHub, Box, Salesforce, Dropbox, Slack, and WebEx.
Dopamine DLP extracts content on the device and uses LLM-based classification to detect PII, PCI, PHI, and IP in uploads and AI prompts.
CASB Neural connects by API to Google Drive and OneDrive to find files that are overshared.

That's the same scope as an SSE suite for web and SaaS, built on a different architecture. For how this compares across cloud security platforms, see the best secure web gateway for cloud security.

What does SWG architecture mean for cost?

Gen 2 vendors carry data center costs that scale with your traffic. Every byte your users send passes through infrastructure the vendor has to build and run. Gen 3 shifts inspection to hardware you already own. That's part of why dope.security can offer a free SWG tier and an instant trial with no payment method.

How does each architecture handle a real request?

Follow one request from a remote employee in Austin opening a Google Doc.

Step	Gen 2 cloud proxy	Gen 3 on-device (dope.security)
1	Agent sends request to nearest PoP, maybe Dallas	Local proxy intercepts on the laptop
2	PoP terminates TLS and inspects	Laptop terminates TLS and inspects
3	PoP checks policy and tenant	Agent checks cached policy and tenant
4	PoP opens a new connection to Google	Laptop connects directly to Google
5	Response returns through PoP	Response returns directly
6	Log written in vendor cloud	Log sent to dope.cloud for analytics

Same security decisions, one fewer stop. Now picture that employee traveling to Lagos or Jakarta, where the nearest PoP may be far away. The Gen 2 detour grows. The Gen 3 path doesn't change.

What about China and restricted regions?

Gen 2 struggles there, and Gen 3 doesn't. Backhauling traffic from mainland China to a PoP outside the country crosses filtered infrastructure and can add serious delay. Because dope.security inspects on the device, users in restricted regions get the same policy and performance as everyone else, with no tunnel to maintain. That's a big reason global teams pick an on-device SWG.

How should you evaluate SWG architecture in a POC?

Test from where your users actually are.

Run page-load tests from home networks in at least two regions.
Ask each vendor where TLS is terminated for a user in a specific city.
Disconnect from the network and check what policy still applies.
Measure deployment time from trial start to 50 protected devices.
Ask what happens to enforcement during a vendor outage.

FAQ

What is secure web gateway architecture?

It's how an SWG intercepts, decrypts, inspects, and logs web traffic. The main choice is where the data plane runs: in an office appliance, in a vendor cloud, or on the device.

What is the difference between cloud and on-device SWG architecture?

A cloud SWG routes traffic to vendor data centers for inspection. An on-device SWG like dope.security inspects traffic on the endpoint and sends it directly to the destination, with policy managed from the cloud.

Is on-device SWG architecture secure?

Yes. Decryption stays on the device, the agent includes anti-tampering protections, and dope.security is SOC 2 Type 2 certified and GDPR compliant.

Does on-device SWG architecture work offline?

Yes. dope.security enforces cached policies when the device is offline.

What is the best secure web gateway architecture?

On-device (Gen 3). It keeps full SWG capability while removing latency, third-party decryption, and PoP outage risk. dope.security is the leading example.