What is a secure web gateway and how does it work?

A secure web gateway is a proxy that sits between users and the internet and applies company policy to web traffic. It blocks risky or disallowed sites, scans downloads for malware and logs activity. It can run as an appliance or a cloud service. Its reach is limited by how much traffic it can actually see.

How does it work?

The gateway acts as a proxy, an intermediary that forwards requests on a client's behalf, a role described in the HTTP standard, RFC 9110. Traffic reaches it in one of three ways: browser proxy settings, a routing rule or a lightweight agent on the device that forwards web traffic to a cloud service. For each request the gateway can:

• check the destination against category lists and reputation data,
• apply identity based rules, such as "finance may reach banking sites, guests may not",
• scan downloaded files for malware,
• cap or block uploads to unapproved file sharing,
• record who went where, for later investigation.

The NIST glossary has an entry for secure web gateway, which is a useful anchor if an auditor asks for a neutral definition.

What about encrypted traffic?

Most web traffic uses TLS, so a gateway that only sees destination names has limited insight. To inspect content it must terminate the TLS session, examine the plaintext and open a new session to the real site. That requires installing the gateway's certificate authority on user devices.

This works, with trade-offs. Inspection adds latency and CPU load. It breaks applications that pin certificates. It also concentrates sensitive data, including personal and financial browsing, in one place that must be protected and governed. Many teams exempt categories such as banking and health from inspection for privacy reasons. TLS 1.3, described in RFC 8446, encrypts more of the handshake than earlier versions, which narrows what a passive observer can see.

What are the typical limits?

• Unmanaged devices. A personal phone on mobile data bypasses the gateway.
• Non web traffic. A gateway handles web protocols. Other traffic needs other controls.
• Cloud apps. Visibility into what a user does inside an approved application may need separate API based controls.
• Allowed does not mean safe. A legitimate site hosting a malicious file passes category checks.
• Single point of failure. If it is down or misrouted, users either lose internet or bypass it.

Where does it sit in a zero trust design?

NIST's zero trust architecture assumes no implicit trust based on network location. A gateway fits as one policy enforcement point for outbound web use, fed by identity and device signals. It complements, rather than replaces, access control for internal applications.

Constructed example: a 300 person company routes all employee browsers through a cloud gateway. A user clicks a link to a fake file sharing page. The gateway checks the domain, which was registered two days ago, and blocks it under a "newly registered" category. The log shows two other users hit the same domain, so the help desk contacts them.

How to check or apply this

1. Decide what you want it to do first: category blocking, malware scanning, upload control or logging. Do not enable everything at once.
2. List how traffic will reach it and which devices could bypass it.
3. Decide your TLS inspection scope and exemptions, and get legal and HR sign off.
4. Run in monitor mode for two weeks and review what would have been blocked.
5. Create an exception process with an owner and expiry dates.
6. Retain logs for as long as your investigations need and protect them like sensitive data.
7. Test with a safe file such as the EICAR test file to confirm scanning works, and test a blocked category.

Quick check

Sources

• NIST glossary, secure web gateway
• RFC 9110, HTTP Semantics
• RFC 8446, TLS 1.3
• NIST SP 800-207, Zero Trust Architecture

Last reviewed: 18 October 2026.