Secure web gateway: what it does, how it works and why SASE changes the equation

What is a secure web gateway?

A secure web gateway (SWG) is a security service that sits between users and the internet, inspecting all web traffic in real time. It enforces access policies, blocks malicious content, prevents data leakage and gives IT teams visibility into how the organisation uses the web. In a SASE platform, SWG shares a single policy engine with ZTNA, FWaaS and SD-WAN, eliminating the need for a standalone product.

Every web request your team makes passes through somewhere. The question is whether that somewhere actually inspects what comes back. A secure web gateway does exactly that. It intercepts outbound web traffic, checks the destination, decrypts and scans the content, applies your policies and either allows or blocks the request before anything reaches the endpoint.

For IT managers evaluating their security stack, SWG is one of those components that sounds straightforward but sits at the centre of several overlapping concerns: malware delivery, shadow IT, data exfiltration, NIS2 compliance and user productivity. This post covers what an SWG does, how it compares to firewalls, CASB and WAF, and why the standalone SWG is rapidly disappearing into SASE platforms.

What a secure web gateway does

An SWG operates at Layer 7 of the OSI model, the application layer. This is what separates it from traditional firewalls that work at Layers 3 and 4. Instead of just checking IP addresses and ports, an SWG understands the content of HTTP and HTTPS sessions. It can distinguish between a user viewing a LinkedIn profile and that same user uploading a confidential document to a personal cloud storage account.

The core functions break down into six areas.

URL and DNS filtering checks every web request against categorisation databases and threat intelligence feeds. Known phishing domains, command-and-control servers and policy-restricted categories get blocked before any content loads.

TLS/SSL inspection decrypts encrypted traffic, scans it, then re-encrypts it before forwarding to the user. Without this, the gateway is blind to anything inside HTTPS sessions, which now accounts for over 90% of all web traffic.

Malware scanning analyses downloads and web content in real time. Advanced gateways combine signature-based detection with sandboxing, where suspicious files run in an isolated environment before reaching the endpoint.

Content categorisation classifies websites into categories (social media, gambling, file sharing, AI tools) and applies policies per category, per user group or per device type.

Data loss prevention (DLP) inspects outbound traffic for sensitive patterns: credit card numbers, national ID formats, intellectual property markers. If a user tries to paste source code into an unapproved AI tool, DLP catches it.

Application control identifies specific web applications regardless of port or protocol. This lets IT teams allow Slack but block file uploads, or permit Google Workspace but restrict sharing to external domains.

How TLS inspection works (and why it matters)

More than 90% of web traffic is now encrypted. That is good for privacy, but it creates an enormous blind spot for security tools that cannot look inside HTTPS sessions. Research consistently shows that a significant share of malware is delivered through encrypted connections. If your security stack cannot inspect TLS traffic, it is effectively ignoring the majority of potential threats.

TLS inspection works through a controlled man-in-the-middle process that the organisation itself manages.

When a user requests a secure website, the SWG intercepts the connection before it reaches the destination. The gateway establishes its own TLS session with the target server, receives the response, decrypts it and runs the content through its inspection engines. If the content passes all checks, the gateway re-encrypts it using its own certificate and forwards it to the user’s browser.

For this to work without triggering browser warnings, the organisation’s root certificate must be installed on every managed endpoint. This is straightforward with an MDM solution like Intune or Jamf, but becomes more complex with BYOD devices.

There are legitimate privacy boundaries to respect. Most organisations exclude certain traffic categories from inspection: banking sites, healthcare portals, government services. A well-configured bypass list is not optional. It is a compliance requirement in many European jurisdictions.

The performance concern is real but often overstated. Older hardware-based SWG appliances struggled with the CPU load of decrypting thousands of concurrent sessions. Cloud-native SWG services handle this at scale because inspection capacity grows with the platform, not with a box in your server room.

SWG vs firewall vs CASB vs WAF

These four technologies overlap enough to cause confusion, but each serves a distinct purpose. The simplest way to understand the difference is by looking at what traffic each one inspects and in which direction.

SWG vs firewall. A firewall sees an outbound HTTPS connection to port 443 and allows it because the rule permits web traffic. An SWG decrypts that same connection, recognises the destination as a newly registered phishing domain and blocks it. Firewalls are necessary, but they are not sufficient for web security. You need both.

SWG vs CASB. An SWG blocks a user from visiting a malicious website. A CASB in SASE stops that same user from sharing a confidential spreadsheet via a personal Gmail account inside Google Drive. SWG handles general web traffic. CASB handles sanctioned and unsanctioned cloud application usage. In a unified platform, both engines share the same policy framework.

SWG vs WAF. The direction is reversed. An SWG protects your users going out to the internet. A WAF protects your web applications from attacks coming in. If you run customer-facing portals or APIs, you need a WAF. If your team browses the web and uses SaaS tools, you need an SWG. Many organisations need both.

Why standalone SWG is becoming obsolete

For years, organisations bought SWG as a separate product. A dedicated appliance or cloud proxy that handled web filtering independently from the firewall, the VPN and the endpoint protection. That model is breaking down.

Gartner retired its standalone SWG Magic Quadrant and folded web gateway evaluation into the broader Security Service Edge (SSE) and SASE categories. That was not an administrative decision. It reflected market reality: web traffic inspection cannot be separated from access control, cloud security and network policy without creating gaps and duplicating effort.

The problems with standalone SWG are practical, not theoretical.

Separate policies. When your SWG, firewall and ZTNA solution each have their own console, policy inconsistencies are inevitable. A user blocked from a risky site in the SWG can still reach the same content through a different path that the gateway does not cover.

Redundant inspection. In a service-chained architecture, traffic gets decrypted and re-encrypted at every inspection point: once at the firewall, again at the SWG, again at the DLP engine. Each hop adds latency and increases the chance of configuration errors.

No shared context. A standalone SWG does not know that the device making the request just failed a posture check. It does not know the user’s ZTNA session was flagged for unusual behaviour. Without shared context, each tool makes decisions in isolation.

The alternative is a converged platform where SASE architecture delivers SWG, ZTNA, FWaaS, CASB and SD-WAN through a single inspection pipeline. For a clear breakdown of how these components relate, the comparison of SASE vs SSE vs SD-WAN covers the distinctions in detail.

How SWG works inside a SASE platform

In a converged SASE platform, SWG is not a bolt-on. It is one inspection engine among several that process traffic in a single pass.

Here is what that looks like in practice. A user opens their browser and navigates to a website. The SASE agent on their device routes the request to the nearest point of presence. At the PoP, the platform performs a single decryption. The traffic metadata, including user identity, device posture status, geolocation and requested URL, feeds simultaneously into every relevant engine: URL filtering (SWG), application policy (CASB), firewall rules (FWaaS), data loss prevention and malware scanning. One decryption, one inspection pass, one policy decision. The traffic is re-encrypted once and forwarded.

Jimber’s SASE platform operates on exactly this principle. SWG policies, ZTNA access rules and firewall policies live in the same console. A policy that restricts a marketing team’s access to file-sharing sites applies consistently whether the user is in the office, working from home or connecting from a hotel in another country. There is no separate SWG portal to configure.

This integration also simplifies measurement. When your SWG, access control and endpoint policies share a single logging pipeline, you can correlate web activity with access events and device compliance in one view. For guidance on what to measure and why, the post on SWG metrics that matter covers the operational side.

The practical benefit for mid-market IT teams is fewer consoles, fewer configuration errors and faster policy changes. When you need to block a newly discovered phishing campaign, you update one policy that applies everywhere. No syncing between products, no waiting for propagation across separate tools.

Why mid-market organisations need a web gateway

Large enterprises have had SWG capability for years. The mid-market has often relied on basic firewall URL filtering or endpoint-based web protection. That gap is closing, driven by three factors.

Malware delivery through the web remains the primary attack vector. Ransomware payloads arrive via drive-by downloads, weaponised documents hosted on compromised sites and phishing pages that harvest credentials. Endpoint protection catches some of this, but stopping the download before it reaches the device is fundamentally more effective than trying to contain it after.

NIS2 creates explicit obligations. Organisations that fall under the directive must implement technical measures proportionate to their risk. Web traffic inspection, access logging and incident detection are directly relevant to Article 21 requirements. An SWG provides the inspection capability, while the logging feeds the incident reporting obligations that NIS2 mandates within 24 and 72 hours.

Shadow IT and AI tool usage are accelerating. Employees use dozens of SaaS applications and AI tools that IT never approved. Some of those tools process company data on servers outside the EU. An SWG with application control gives IT visibility into what is actually being used and the ability to set boundaries without blocking everything.

Data exfiltration prevention. DLP capabilities within an SWG catch sensitive data leaving the organisation through web channels. For organisations handling personal data under GDPR or financial data under DORA, this is not a nice-to-have. It is a control that auditors expect to see.

Platforms like Jimber include SWG as a standard component of their SASE offering. There is no separate licence, no additional appliance. SWG capability is available from the moment the platform is deployed. For organisations that also need browser isolation for high-risk browsing scenarios, that runs alongside SWG in the same platform, adding another layer without another product.

For teams that want to balance security with usability, the post on web filtering without blocking productivity covers how to set policies that protect without frustrating users.

FAQ

What is the difference between SWG and CASB?

An SWG inspects general web traffic flowing from users to the internet. It blocks malicious sites, scans downloads and enforces acceptable use policies. A CASB focuses specifically on cloud application usage: discovering shadow IT, enforcing data-sharing rules within SaaS tools and monitoring user behaviour in sanctioned cloud services. In a SASE platform, both share the same policy engine and inspection pipeline, so you do not need to choose between them.

Do I need an SWG if I already have a firewall?

Yes. A firewall operates primarily at Layers 3 and 4, controlling traffic based on IP addresses, ports and protocols. It cannot inspect the content inside encrypted HTTPS sessions, which is where the majority of web-based threats hide. An SWG works at Layer 7, decrypting and analysing web content in real time. They serve complementary purposes.

How does TLS inspection affect performance?

On older hardware appliances, TLS inspection created noticeable bottlenecks because decryption is CPU-intensive. Cloud-native SWG services distribute this load across scalable infrastructure, which largely eliminates the performance concern for end users. The impact on browsing speed is typically measured in single-digit milliseconds per request. Proper bypass lists for high-sensitivity categories (banking, healthcare) further reduce unnecessary processing.

Is a standalone SWG still worth buying?

For most mid-market organisations, no. Standalone SWG products require separate configuration, separate policies and separate logging. They cannot share context with your access control or endpoint policies. A SASE platform that includes SWG alongside ZTNA, FWaaS and CASB in a single console delivers better security outcomes with less operational overhead.

How does an SWG help with NIS2 compliance?

NIS2 requires proportionate technical measures for risk management, incident handling and supply chain security. An SWG directly supports these requirements by inspecting web traffic for threats, logging all web activity for incident investigation, enforcing access policies that limit exposure and preventing data exfiltration through DLP controls. The logging capability is particularly relevant for the 24-hour and 72-hour incident notification obligations.

Can an SWG detect AI tool usage?

Yes. Modern SWG solutions with application control can identify and categorise AI tools like ChatGPT, Gemini, Copilot and hundreds of others. IT teams can set granular policies: allow access to approved AI tools, block unapproved ones, or allow usage but prevent file uploads and data pasting through DLP rules.

Ready to see how SWG fits into a unified SASE platform for your organisation? Book a demo and get a walkthrough of how Jimber combines web security, access control and network connectivity in one console.