A cloud secure web gateway, or cloud SWG, is a hosted service that sits between users and the internet, applying filtering, malware checks and policy to web traffic. It does what an office web proxy did, but for staff anywhere. You need one when your users, not your office, are the perimeter.
How is it different from an office proxy?
An on-premises proxy only sees traffic that passes through the office. When staff work from home, the proxy is out of the path unless they tunnel back through a VPN, which adds delay and load. A cloud SWG moves the control point to a service close to the user. A client agent or a proxy setting steers web traffic to it from any network.
NIST SP 800-215, the guide to the secure enterprise network, discusses secure web gateways with cloud access security brokers, zero trust network access and SASE as parts of the modern enterprise network. It frames them as network configurations for security functions such as cloud services access security, rather than stand-alone answers.
What does it do?
URL and category filtering. Block categories you do not allow, such as known malicious sites.
Malware scanning. Check downloads before they reach the device.
Policy by identity. Apply different rules to different groups, using the user's login rather than their address.
Logging. One record of web activity for people who work off the corporate network.
TLS inspection. Some services decrypt, inspect and re-encrypt traffic. That is the feature with the most trade-offs.
What are the trade-offs?
Inspecting encrypted traffic means the gateway terminates the user's TLS session and starts a new one to the site. You then have to distribute a trusted certificate to every device and protect the gateway's signing key. Some apps break when their traffic is intercepted, and some content, such as health or banking, you may choose to exclude for privacy reasons. TLS 1.3 itself, defined in RFC 8446, is built to resist on-path interference, which is why interception depends on the client trusting your certificate.
Then there is dependence. All web traffic crosses a third party's service. Ask what happens to your staff if it goes down.
A SWG also sees only web traffic. It does not cover a malicious USB drive or a laptop on a hotspot that bypasses the agent.
What does a constructed decision look like?
A 200-person company has two offices and many remote staff. Its old proxy lives in one office. Remote staff bypass it, and the security team has no web logs for them. A cloud SWG with an agent on laptops gives uniform policy and logs. The team excludes banking and health categories from decryption and writes that down as a policy decision.
How does it relate to zero trust and SASE?
NIST SP 800-207 describes zero trust as moving defenses from static network perimeters toward users, assets and resources, with no implicit trust based on network location. A cloud SWG fits that direction, since policy follows the user rather than the office. SASE is the label for combining network and security functions, including a SWG, delivered from the cloud. Treat the acronyms as packaging. Decide the functions you need first, then see which bundles cover them.
How to check or apply this
- List where web traffic leaves today, and which users bypass the proxy.
- Decide which policy goals matter: block malware, enforce acceptable use, get logs, or all three.
- Decide on TLS inspection. If yes, list the categories you will exclude, and who approves exceptions.
- Ask how the client is enforced and how a user is prevented from turning it off.
- Ask how the service behaves on failure: fail open or fail closed, and who chooses.
- Check where logs are stored and for how long.
- Pilot with one team and watch for broken applications before a wider rollout.
Quick check
Is a SWG the same as a firewall?
No. A SWG focuses on web traffic and user policy. A firewall filters at the network and transport level. They are often used together.
Do you have to decrypt traffic?
No. You can filter by domain and category without decrypting. Decryption adds visibility into content and adds complexity and privacy questions.
Sources
- NIST SP 800-215, Guide to a Secure Enterprise Network
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
