Secure Web Gateway vs NGFW: Deciding Where Web Filtering Belongs

Most organisations now own two places that can filter web traffic, a next-generation firewall (NGFW) at the network edge and a secure web gateway (SWG), often delivered from the cloud as part of a security service edge (SSE), and running the same policy in both wastes money while running it in the wrong one leaves remote users or servers uncovered. Both can categorise URLs, decrypt TLS and scan files, so the real question is not which product is better but which traffic each one actually sees and which inspection it does well. This guide compares the two by threat model, architecture, TLS inspection behaviour, remote user coverage and failure modes, then gives decision criteria, worked scenarios and a consolidation plan. It is for network and security architects, firewall owners and anyone deciding whether to retire on-premises web filtering. For each control in depth see the Secure Web Gateway and Web Filtering Guide and the NGFW vs UTM comparison.

Key takeaways

• The SWG follows the user, the NGFW guards a network. A cloud SWG inspects a managed device's web traffic wherever it is; an NGFW only inspects traffic that is routed through it, which for most remote staff means none of their SaaS and web use.
• Web is one protocol for the SWG and one of many for the NGFW. The SWG is a forward proxy built for HTTP and HTTPS from people; the NGFW is a layer 3, 4 and 7 policy point for every protocol, including server, OT and guest traffic that no SWG agent will ever touch.
• Decrypt once, in one place, per traffic flow. Double TLS inspection breaks certificate pinning, adds latency and splits the exemption list in two. Decide per flow which engine decrypts and set the other to trust it.
• Encrypted Client Hello erodes SNI-only filtering. RFC 9849 encrypts the server name in the TLS handshake, so an NGFW that categorises HTTPS from the SNI without decrypting will see less over time; a proxy that terminates the session is less affected.
• Consolidate by traffic class, not by product. User web traffic usually moves to the SWG, while the NGFW keeps inbound, east-west, server egress and non-web protocols. Retiring either completely is the exception.

The short answer

If most of your users work away from the office and most of their applications are SaaS, put user web filtering in a cloud SWG and stop backhauling that traffic to a data centre firewall. If your users sit on networks you control, or you are a small site with one internet breakout, NGFW URL filtering is usually enough and a separate SWG adds cost without much coverage. Keep the NGFW in every design for what an SWG does not handle: inbound services, segmentation between zones, server and workload egress, and protocols other than HTTP and HTTPS. NIST SP 800-215 makes the same split in its own terms: it describes an SWG as fundamentally a web filter for outbound user traffic, and an NGFW as a firewall with application data awareness across layers 3, 4 and 7, which can itself be delivered as firewall as a service (FWaaS).

How each works, in words

Secure web gateway

An SWG is a forward proxy with a policy engine. On a managed laptop an agent or a PAC file sends web requests to the nearest gateway point of presence; in an office the branch router can tunnel traffic there instead. The proxy terminates the user's TLS session with a certificate signed by an interception certificate authority the device trusts, applies URL category, reputation, file scanning, sandboxing, data loss prevention (DLP) and cloud application controls, then opens its own TLS session to the destination. Because it is the endpoint of the session, it sees full URLs, file content, the authenticated user and, with inline CASB functions, the SaaS tenant. In SSE the SWG sits beside CASB and zero trust network access (ZTNA) on the same platform; NIST SP 800-215 lists firewall, SWG, anti-malware, IPS, CASB and DLP as the minimal services in most commercial SASE offerings. See the SASE and SSE Guide.

Next-generation firewall

An NGFW is a stateful firewall that identifies applications and users and can inspect payloads. Traffic reaches it because it is the routed path: the internet edge, a data centre core, a cloud VPC egress point or a branch. URL filtering on an NGFW normally works in-line without being a proxy: it reads the host from the TLS server name indication (SNI) or the HTTP Host header, looks up the category and allows or resets the session. With decryption enabled it acts as a transparent man in the middle and can apply the same file and threat engines it uses for other protocols. Its strength is breadth: the same rule base controls DNS, SMB, SSH, database ports, industrial protocols and web, for every device behind it, managed or not.

Comparison table

Threat model for each

Both controls address the same web threats in principle: drive-by compromise (T1189), malware and tool downloads (T1105 Ingress Tool Transfer), command and control over web protocols (T1071.001) and exfiltration to cloud storage (T1567.002). They differ in what they assume about where the attacker and the victim are.

TLS inspection: who decrypts what

Inspection is where the two most often collide. CISA's TIC 3.0 Security Capabilities Catalog lists Break and Inspect as a web policy enforcement capability alongside domain category filtering, domain reputation filtering, content filtering and data loss prevention, and the TIC 3.0 Remote User Use Case stresses limiting interception certificate lifetimes and protecting the keying material. The practical rules:

• One decryptor per flow: if user traffic goes to a cloud SWG through a branch firewall, configure the firewall to pass the tunnel or the proxy traffic without decrypting it. Two interception points mean two trust anchors on the device, two exemption lists and harder troubleshooting.
• Shared exemption policy: categories exempt for privacy or legal reasons (health, finance, personal banking) and applications that pin certificates must be the same list in both places, owned by one person. See the TLS Inspection Guide.
• SNI-only filtering is weakening: RFC 9849, TLS Encrypted Client Hello, was published in March 2026 as a Proposed Standard (checked November 2026). It encrypts the ClientHello, including the server name, under a key the server publishes. An NGFW that categorises HTTPS from the SNI alone will see the public outer name instead of the real destination for sites that adopt it. Options are full decryption, managing browser ECH settings on managed devices, or relying on DNS and IP reputation, each with limits. A terminating proxy sees the destination because the client connects to it.
• QUIC and HTTP/3: QUIC runs over UDP 443. Both controls generally fall back to inspecting TCP when UDP 443 to the internet is blocked; leave it open and much browser traffic escapes inspection.
• Performance: decryption is the largest throughput cost on an NGFW. Check the vendor's published decrypted throughput, not the firewall throughput, when sizing. Cloud SWGs move that cost to the provider.

For analysing traffic you choose not to decrypt, see TLS Inspection vs Encrypted Traffic Analysis.

Remote users and the backhaul question

NIST SP 800-215 describes the cost of hair-pinning: remote VPN connections terminate at corporate concentrators, so even cloud-bound traffic crosses the corporate internet edge, adding distance, latency and bottlenecks. Keeping NGFW web filtering for remote users means either full tunnel VPN, with that latency, or split tunnel, with no inspection for internet traffic. The TIC 3.0 Remote User Use Case (version 2.0, April 2023) describes three paths for a remote user to reach the web: through the agency campus, through a cloud security service, or directly, and calls the direct option the riskiest because enforcement may then exist only on the device. A cloud SWG is the cloud security service path. Two details decide whether it works:

1. Agent coverage: the percentage of managed devices with the agent running and enforcing, measured daily. A disabled agent is a direct path.
2. Fail behaviour: decide what happens when the agent cannot reach the service (fail closed with captive portal exceptions, or fail open with logging) and write it down, because it is the most common silent gap.

Users who also need private applications are better served by ZTNA than by keeping the VPN for web traffic; see ZTNA vs VPN.

Failure modes

SWG

• Steering gaps: split tunnel bypass lists that grow every quarter, desktop apps that ignore the proxy, and unmanaged devices that never had the agent.
• Exemption creep: whole categories or large SaaS domains exempted from inspection to stop a complaint, which then become the exfiltration path.
• Provider dependence: outage behaviour, point of presence location for data residency, and log retention set by contract, not by you.
• Servers routed through it by mistake: automated jobs that break on interception certificates, followed by broad bypass rules.

NGFW

• Location blindness: URL policy that looks complete in the console but covers only office traffic.
• SNI-only categorisation: no decryption, so file scanning and DLP see nothing in HTTPS, and ECH reduces what remains.
• Capacity pressure: decryption turned off at peak to protect throughput, usually without telling the security team.
• Weak identity mapping: user-based web policy that maps IP addresses to users and misattributes traffic on shared terminals, VDI and NAT.

Where identity fits

Both controls make better decisions with identity, and both depend on credentials of their own. User-based web policy needs authentication to the SWG or reliable IP to user mapping on the firewall. The machine side matters as much: API tokens that export logs to the SIEM, the identity provider integration, the interception certificate authority's private key and the service accounts that push policy are high-value non-human identities. Store them in a vault, scope them to read or write as needed and rotate them. Workloads that call out to the internet should be controlled by destination allow lists on the NGFW or a cloud egress filter rather than an SWG agent; see Cloud Egress Filtering.

Decision criteria

Small organisations: a single NGFW with URL filtering, DNS filtering and enforced agent based protection on laptops often covers enough. Large organisations: nearly always run both and need a written split of traffic classes so that policy is not duplicated. The DNS Filtering vs Secure Web Gateway comparison covers the cheaper layer beneath both.

Worked scenarios

Hybrid professional services firm, 900 users, two offices. Remote staff use full tunnel VPN so that the data centre NGFW can filter web traffic. Video calls and SaaS suffer, and the NGFW runs with decryption disabled at peak. Decision: move user web traffic to a cloud SWG with the agent on all laptops, set the agent to fail closed with a captive portal exception, change the VPN to private applications only, then ZTNA. The NGFW keeps inbound services, office guest Wi-Fi and server egress.

Manufacturer with plants and OT. Plant floors have engineering workstations, HMIs and vendor support connections. An SWG agent cannot run on most of them. Decision: plant NGFWs enforce zone policy and strict destination allow lists for the few internet updates needed; office users move to the SWG.

Consolidating without duplicate policy

1. Inventory traffic classes: user web on site, user web remote, server and workload egress, guest and IoT, inbound services and east-west. Record which control sees each today.
2. Assign one owner per class: write the split down (for example user web to the SWG, all else to the NGFW) and agree who owns category policy, exemptions and the interception certificate authority.
3. Translate, do not copy: map NGFW URL categories to SWG categories explicitly; category names and definitions differ between engines. Review exceptions rather than carrying them over.
4. Pilot in monitor mode: deploy the agent to a pilot ring with log only policy, compare decisions with the NGFW logs for two weeks, then enforce for the pilot ring.
5. Turn off the duplicate: once the SWG enforces for a ring, set the NGFW to pass that ring's SWG tunnel without decryption and remove user URL rules that no longer match anything.
6. Keep a rollback: retain the previous NGFW policy disabled, not deleted, and a documented switch back to full tunnel VPN, until two quarters of stable operation.

For firewall side change control see the Next-generation firewall (NGFW) migration playbook.

Detection and measurement

• Inspection coverage: share of user web requests that reach a policy point, by location (target above 98 percent of managed device traffic).
• Agent health: percentage of managed devices with the SWG agent enforcing, checked daily.
• Decryption rate: share of HTTPS sessions decrypted at each control, and the size of the exemption list over time.
• Duplicate decryption count: flows decrypted twice, which should trend to zero after consolidation.
• Unfiltered egress: sessions from user subnets to the internet on TCP or UDP 443 that bypass the SWG tunnel, seen in NGFW logs.
• Block to incident ratio: web blocks that matched later confirmed incidents, to show the policy is tuned rather than noisy.

Detection content for both log sources is in the Proxy and Web Gateway Log Detection Guide and the VPN and firewall log detection guide.

Framework mapping

Common failure patterns

• Buying the SWG and leaving the VPN full tunnel: traffic is filtered twice and remote users still suffer the latency the SWG was meant to remove.
• Two exemption lists: a site exempt on the SWG but decrypted on the NGFW, or the reverse, so users find the path that works and security loses visibility.
• Assuming the NGFW covers remote staff: a URL policy audit that only reviews the firewall console misses everyone working from home on split tunnel.
• Pointing servers at the SWG: automation breaks on interception, someone adds a wide bypass, and server egress ends up controlled by neither.
• Leaving UDP 443 open: QUIC traffic avoids both engines unless it is blocked or the platform inspects it.
• No owner for the interception CA: certificate expiry or key compromise takes down browsing or silently weakens trust on every device.

Practitioner checklist

• Document the traffic class split between SWG and NGFW and give each class one policy owner.
• Ensure every flow is decrypted at most once, and that the firewall passes SWG tunnels without inspection.
• Keep a single TLS exemption list with a named owner and quarterly review.
• Block UDP 443 to the internet where QUIC cannot be inspected, and manage browser ECH and DoH settings on managed devices.
• Monitor SWG agent enforcement daily and alert on devices that stop reporting.
• Restrict server and workload egress on the NGFW or cloud egress controls with destination allow lists.
• Store log export tokens, policy automation accounts and the interception CA key in a vault, with rotation.
• Export both log sources to the SIEM and alert on user subnets reaching the internet outside the SWG path.

Standards and references

• NIST: SP 800-215, Guide to a Secure Enterprise Network Landscape
• NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• CISA: TIC 3.0 Security Capabilities Catalog
• CISA: TIC 3.0 Remote User Use Case
• IETF: RFC 9849, TLS Encrypted Client Hello
• CIS: Critical Security Controls v8.1
• MITRE D3FEND: URL Analysis

Related NHI Mgmt Group resources: CASB vs SWG, SASE and SSE Buyer's Guide, Firewall Buyer's Guide, M1020 SSL/TLS Inspection.