What is a secure web gateway and what does it do?

A secure web gateway, or SWG, is a forward proxy that sits between users and the internet and enforces web policy. It filters by category and URL, scans downloads, can inspect encrypted traffic, and logs requests. It is a control point for outbound web use, not a replacement for endpoint or identity controls.

What is it, technically?

An SWG is an application-layer proxy, which RFC 9110 describes as an agent that makes requests on behalf of the client. Users reach it through browser configuration, a client agent, a routing rule or a transparent redirect. Because it understands HTTP, it can apply policy to the URL and request, not only to an IP address and port.

Whether it sits in your data center or runs as a cloud service, the function is the same. What changes is where traffic goes and whether remote users are covered.

What does it enforce?

Category and URL policy. Block known-malicious or unwanted sites, and allow only approved categories for sensitive roles.

Malware checks. Inspect or sandbox downloaded files before they reach the endpoint.

Data controls. Block uploads of marked files to unapproved sites, or restrict personal accounts on approved services.

Logging. Record who requested what and when. This is often the most valuable output during incident response, because it shows which host first contacted a bad domain.

What about encrypted traffic?

For HTTPS the client asks the proxy to open a CONNECT tunnel, and without more, the proxy sees only the host and port. To see paths and content, the SWG must terminate TLS and present its own certificate, which clients trust through an installed root. TLS 1.3, defined in RFC 8446, keeps more of the handshake encrypted, so even the destination name may be less visible than before unless the proxy decrypts.

Inspection has a cost. The gateway holds decrypted data and signing keys, which makes it a high-value target. Some applications pin certificates and break under inspection. Banking and health traffic is often excluded by policy for privacy reasons.

A constructed example

A finance team receives a link in an email to a document-sharing site that was registered two days ago. The SWG category for newly registered domains is set to warn. The user sees a block page with a reason and a way to request review. The request log shows 14 other users in the company received the same link and two clicked before the rule fired, which tells the response team where to look first.

Where does it fall short?

An SWG covers web traffic that goes through it. Applications that use other protocols, direct-to-IP connections and devices that bypass it are outside its view. It does not replace endpoint protection, since malware can arrive by other paths, and it does not decide whether a person should have access to a system.

NIST SP 800-207 frames a gateway like this as a policy enforcement point in a larger design, where a policy engine evaluates identity and device posture. The SWG enforces. Something else decides.

How to check or apply this

1. Decide how every device reaches the gateway, including remote and unmanaged ones, and test the bypass cases.
2. Start with a short category policy and move to enforcement after a monitor period.
3. If you decrypt TLS, publish the scope, exclude sensitive categories, and protect keys and logs.
4. Keep an exception process with expiry dates for blocked sites that teams need.
5. Send gateway logs to central storage and alert on new domains contacted by many hosts.
6. Test block pages and allowlists after each policy change.
7. Review which apps break under inspection and exempt them by documented rule.

Quick check

Sources

• RFC 9110, HTTP Semantics
• RFC 8446, TLS Protocol Version 1.3
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy

Last reviewed: 18 October 2026.