What Is a Secure Web Gateway (SWG)?
What a secure web gateway (SWG) does, how it differs from a DNS filter, proxy and firewall, what TLS inspection breaks, where SSE and SASE fit, and when a small IT team needs one.
A DNS filter stops a laptop from reaching a bad domain, and a firewall stops it from reaching a bad port, yet a user on hotel Wi-Fi still uploads a client list to a personal cloud drive over plain HTTPS. The control that sees that upload sits one layer up, in the web traffic itself. That is the job of a secure web gateway, and this post covers what SWG means, how it differs from a DNS filter, a proxy and a firewall, and when a small IT team needs one.
TL;DR
- A secure web gateway (SWG) is a checkpoint that every web request from a managed device passes through. It filters by URL and category, scans downloads, controls what users can do inside web apps, and logs the lot, wherever the device is.
- A DNS filter sees domain names. A firewall sees addresses and ports. A proxy sees HTTP. An SWG sees the full request and, with TLS inspection on, the content inside HTTPS.
- TLS inspection is where the value and the trouble both live. It needs a root certificate on every device, and it breaks certificate-pinned apps, mutual TLS, Encrypted Client Hello and QUIC unless you plan for them.
- Vendors now sell SWG inside Security Service Edge (SSE) bundles with CASB and ZTNA. SASE adds SD-WAN on top. You can buy the gateway alone.
- Small teams: start with DNS filtering, add an SWG when you need download scanning, app control or data controls for remote users.
What a Secure Web Gateway Does
A secure web gateway is a policy checkpoint for web traffic. Every request a managed device makes to the internet is routed through it, and the gateway decides whether the request goes out, what comes back, and what gets recorded.
Early gateways were appliances in the office rack. Today the gateway is almost always a cloud service, and the device reaches it through an agent, a proxy setting or a tunnel. That change matters because the office is no longer where the devices are. Microsoft describes its own gateway, Entra Internet Access, as an "identity-centric Secure Web Gateway" that protects users "whether they're remote or within the corporate network," which is the whole pitch in one line.
The gateway runs four checks on each request:
| Check | What it does | Example |
|---|---|---|
| URL and category filtering | Allows or blocks the destination by domain, full URL or category | Block gambling, allow the client's portal |
| Malware scanning | Scans files on the way down, and sometimes on the way up | Stop a disguised installer from a file-sharing site |
| Application control | Lets you allow an app but limit what users do in it | Allow personal webmail, block attachments |
| Data controls | Spots sensitive data leaving in uploads or posts | Flag a spreadsheet of card numbers heading to a personal drive |
Two of those checks only work on encrypted traffic if the gateway can open it. That is the TLS inspection question, and it gets its own section.
SWG vs DNS Filter vs Proxy vs Firewall
The four controls get confused because they overlap, and the overlap is what each one can see. A control can only block what it can read.
A DNS filter sees the name lookup before any connection opens. It knows the device asked for drive.example.com; it has no idea which page, which file or which direction the data went. It is fast, cheap and blind to anything after the lookup.
A stateful firewall sees addresses, ports and connection state. It can allow outbound 443 and block everything else, and our post on the stateful firewall explains what the state table remembers. It does not know what travels inside the 443 session.
A proxy server sees HTTP. It can read the full URL, the method and the headers for plain HTTP, and it can do the same for HTTPS if it is set up to intercept TLS. A proxy on its own is a forwarding device with a policy file; a gateway is the proxy plus the scanning, categorisation and reporting layered on top.
An SWG uses the proxy's position and adds the checks from the table above. With TLS inspection off, it still sees the hostname from the TLS handshake (the Server Name Indication, or SNI), so category filtering works. With TLS inspection on, it sees everything.
| Control | Sees | Blocks on | Blind to |
|---|---|---|---|
| DNS filter | Domain name at lookup | Domain, category | Pages, files, uploads |
| Firewall | IP, port, state | Port, address, protocol | Anything inside the session |
| Proxy | HTTP, and HTTPS if intercepted | URL, method | Content, unless scanning is added |
| SWG | Full request and response | URL, file, app action, data pattern | Pinned apps and anything it cannot decrypt |
TLS Inspection: Where the Value and the Trouble Live
Almost every site now runs HTTPS, so a gateway that cannot open TLS is mostly a category filter with better logs. Opening it is called TLS inspection, SSL inspection or decryption, and every gateway does it the same way.
Microsoft's documentation for Entra Internet Access lays out the mechanics. The gateway sets up two TLS connections: one from the browser to the gateway's edge, one from the edge to the real site. Your organisation signs an intermediate certificate for the gateway, the gateway uses it to mint a short-lived certificate for each site on the fly, and your root certificate authority has to sit in the trusted store on every device so the browser accepts the swap. Cloudflare's Gateway documentation (June 2026) describes the same sequence: decrypt, apply policy, re-encrypt with a user-side certificate.
Once the gateway can read the request, the two checks that need content start working: file scanning on downloads and uploads, and data controls on what leaves. Microsoft's own note on the feature says the point is "making content available" for malware detection, data loss prevention and, in the age of chatbots, prompt inspection.
What inspection breaks is a longer list than vendors put on the front page. Cloudflare's documentation names the categories its gateway cannot decrypt: applications that use certificate pinning, self-signed certificates, mutual TLS, ESNI and ECH handshake encryption, and automatic HTTPS upgrades. It adds that "most mobile applications" use certificate pinning, which is why the first week of inspection fills the service desk with phone apps that stopped working.
Three of those deserve a sentence each:
- Certificate pinning. The app expects one specific certificate and refuses the gateway's substitute. Banking apps, many vendor agents and some update services behave this way. The fix is a bypass rule, not a workaround.
- Encrypted Client Hello. ECH encrypts the part of the TLS handshake that carries the hostname. Cloudflare's own description (April 2026) is that an intermediary "will be able to see that you are visiting a website on Cloudflare, but they will not be able to determine which one." A gateway that filters on SNI loses the hostname for ECH sites, so vendors tell you to turn ECH off in the browser policy.
- QUIC and DNS over HTTPS. Microsoft's setup guide for its gateway says UDP traffic (QUIC) is not supported in the current preview and suggests a firewall rule blocking outbound UDP 443 so browsers fall back to TCP. The same guide requires disabling DNS over HTTPS and the built-in DNS client in Chrome and Edge, otherwise the client cannot see the names it needs to route.
The practical rule: run inspection with a bypass list from day one. Banking, health and payroll categories stay out of it for privacy, pinned apps stay out of it for function, and every exception gets a note explaining why it exists.
Where SWG Sits in SSE and SASE
Nobody sells a plain web gateway any more, or at least nobody leads with one. The gateway now arrives inside a bundle with two or three acronyms attached, and it helps to know which parts you are paying for.
Security Service Edge, or SSE, is the cloud-delivered security bundle. Microsoft's description of the category is a "cloud-delivered network perimeter" for a workforce that works "from nearly anywhere," and its own SSE offer pairs Internet Access (the SWG) with Private Access (zero trust network access to internal apps) and Defender for Cloud Apps (the cloud access security broker). Those three, SWG plus ZTNA plus CASB, are what every SSE vendor means by the term, with the names shuffled.
SASE, Secure Access Service Edge, is SSE plus the networking half: SD-WAN, which routes branch traffic across whatever links are available. If you run offices with their own links, our SD-WAN guide covers that side. If every user is on a laptop at home or in a client's building, SSE is the half you care about and the SD-WAN half is dead weight.
Identity is the glue. The gateways that grew out of identity providers tie each web policy to the signed-in user and the device state, so the same person gets a stricter policy on an unmanaged laptop than on a managed one. If you are mapping that out, start with how IAM solutions handle conditional access, because the gateway policy inherits from it.
Setting One Up Without Breaking the Office
The gateway itself takes an afternoon. The rollout takes a month, because every exception surfaces one at a time, in tickets.
Pick the forwarding path. An agent on the device is the usual answer: it tunnels web traffic to the gateway wherever the laptop is, and it can refuse to let the user turn it off. A proxy auto-config file works for browsers on managed desktops. A site-to-site tunnel from the office router catches everything on the LAN, including printers and TVs, but does nothing for the laptop at home. Many shops end up with the agent for laptops and the tunnel for the office.
Start with categories, in monitor mode. Turn the policy on with everything set to allow and log, and read the logs for a week. You will find the SaaS apps nobody declared, the personal cloud drives, and the vendor update services that need an exception before you block anything. Our post on log management covers where those logs should live once the gateway starts producing them.
Turn on TLS inspection last, and by group. Deploy the root certificate first and confirm it landed, then enable inspection for the IT team, then a pilot department, then everyone. Keep the bypass list from the previous section open the whole time.
Decide what the gateway does for unmanaged devices. It does nothing. A contractor's own laptop and a personal phone on the guest network never reach it. That gap is what your BYOD policy and the CASB side of the bundle exist for.
Write down the exceptions. The bypass list is a security decision each time. Name the app, the reason and the owner, and review it quarterly, because an exception for a pinned app that was retired two years ago is an open door with a plausible label. OpenFrame can run a script across a client's devices and collect the output, which is one way to confirm the gateway agent and the root certificate are present on every laptop before you flip inspection on.
This r/msp thread is a small example of the question that starts the whole project: the DNS filter's roaming client went away, and the laptops off the network needed something that followed them.
When a Small Team Needs One
A gateway is the right buy when the question is about content, not destinations. Four gates sort it out.
Do your users work outside the office? If everyone sits behind one firewall with a DNS filter in front of it, the firewall and the filter already cover the destination layer. If half the team is on laptops in other people's buildings, the gateway is the only control that travels with them, and our remote worker support playbook puts it in that context.
Do you need to scan what comes down? Endpoint protection scans files once they land. A gateway scans them in transit and can stop a download before the browser saves it. If your endpoint tooling is solid and patched, this gate matters less; if you are relying on the browser's own warnings, it matters a lot.
Do you need to control what goes up? Uploads to personal drives, pastes into chatbots and attachments on personal webmail all leave over HTTPS. A DNS filter cannot tell an upload from a download. If a client contract or insurer asks how you stop data leaving, the gateway's data controls are the answer short of a full DLP deployment.
Can you live with TLS inspection? If the pinned-app list is long, the devices are mixed, or the privacy conversation with the business is one nobody wants to have, run the gateway with inspection off. You keep category filtering, app visibility by hostname and better logs than a DNS filter, and you lose the content checks. That is still a reasonable place to be for a 30-person firm.
If none of the four gates applies, DNS filtering plus a managed browser policy is enough, and the gateway money is better spent on the controls that shrink the attack surface you already have.
This explainer from Cato Networks is a vendor video, but it walks the core idea in a few minutes for anyone new to the term:
Another r/msp thread, from March 2025, shows the limit of the gateway agent. A shop wants web filtering for a client's shared guest Wi-Fi, where nobody installs anything, so the filtering has to happen at the firewall or DNS layer instead.
The Short Version
A secure web gateway is the checkpoint for web traffic that follows the device wherever it goes. It filters destinations, scans files, controls app actions and watches for data leaving, and it only does the last three properly when it can open TLS. Buy it for content control and remote users, run inspection with a bypass list, and keep the DNS filter underneath it. If you are deciding what sits around it, the posts on DNS filtering and the stateful firewall cover the layers below.
FAQ
What does SWG stand for?
SWG stands for secure web gateway. It is a cloud or on-premises service that web traffic from managed devices passes through, where it is filtered, scanned and logged. The acronym also means standard wire gauge and a Star Wars game, which is why searching for it alone gets odd results.
Is a secure web gateway the same as a proxy?
A gateway uses a proxy's position in the traffic path, but adds the checks a proxy does not do on its own: category filtering, malware scanning, app controls and data inspection, plus the reporting. A plain forward proxy with a policy file is the ancestor; the gateway is the proxy with a security stack bolted on.
Does a secure web gateway replace DNS filtering?
Not usually. The gateway can filter by domain, so it covers the same ground, but the DNS filter is cheaper, catches devices the gateway agent is not installed on, and keeps working when the gateway has an outage. Shops with both tend to keep the DNS filter as the floor and the gateway as the content layer.
What is the difference between SWG and CASB?
An SWG controls traffic to the open web: any site, any file, any upload. A cloud access security broker controls what happens inside sanctioned SaaS tenants, such as sharing settings in a cloud drive or OAuth grants, often through the SaaS provider's API rather than the traffic path. SSE bundles sell the two together because the gateway sees the traffic and the CASB sees the tenant.
Does TLS inspection let the company read everything?
It lets the gateway decrypt the sessions that policy sends through inspection, which is why every gateway ships with category bypasses for banking, health and similar sites, and why the policy should say what is inspected and what is not. Pinned apps, mutual TLS and Encrypted Client Hello sessions cannot be opened at all, so "everything" is never the real scope.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.