A Secure Web Gateway (SWG) is a security service that checks and controls users’ web traffic before it reaches the internet. It helps block threats, enforce company policies, and prevent sensitive data from being shared outside the organisation. It also keeps records of users’ web activity for security and compliance.
When most corporate applications ran inside the datacentre and users worked from fixed office networks, a firewall at the perimeter provided a workable first line of defence. That model became insufficient as internet access became the primary way people work. Users now connect from offices, homes, branches, and mobile networks, and the traffic they generate has become one of the most targeted attack paths in the enterprise.
Zscaler ThreatLabz analysis of 32.1 billion threats blocked between October 2023, and September 2024 found that 87.2% were delivered over encrypted channels. This shift reinforces the need to inspect encrypted web traffic, a function SWG is designed to provide. The firewall still protects the network boundary, but it is not primarily designed to inspect web session content in depth without additional inspection features such as TLS decryption. SWG restores visibility, control, and threat protection across web traffic.
Why Organisations Deploy SWG?
Most organisations already have a firewall, endpoint protection, and an identity platform. Users may still encounter phishing pages, download malware, and access unsanctioned applications because those tools were not built to inspect traffic before it reaches the user. Unlike traditional firewalls, SWG is specifically designed to inspect and control web traffic in depth.
The most common deployment triggers:
-
Blind spots in encrypted traffic: Security teams without TLS inspection are working with partial visibility. Threats, data exfiltration, and policy violations may routinely hide inside sessions they cannot read.
-
Remote Workers Outside the Network Perimeter: Remote workers, branch offices, and personal devices connect directly to the internet. Cloud-delivered SWG is designed to enforce consistent policy for users across different locations without requiring traffic to be routed through a central inspection site. Depending on the deployment model, this can extend web security controls to contractors, partners, and unmanaged devices.
-
-
Unsanctioned application usage: Employees adopt web-based tools that IT has never evaluated for risk. SWG can provide visibility into that usage and apply policy before data flows through channels the security team cannot see.
-
Compliance evidence gaps: Acceptable use enforcement, DLP controls on outbound web traffic, and web activity logging are requirements in many regulatory frameworks. Without SWG, security teams may struggle to produce complete evidence that web activity was monitored and controlled.
-
Legacy proxy replacement: Organisations running ageing proxy infrastructure find it cannot decrypt TLS traffic, enforce application-level controls, or cover remote users without backhauling. SWG addresses these limitations directly.
Most organisations begin with monitoring before enforcement, mapping actual web traffic patterns and application usage before introducing blocking policies. In practice, that phase surfaces application usage and data flows that may not be fully visible in existing controls.
How SWG Works
SWG is commonly deployed as a proxy-based inspection layer, though deployment models vary. It is positioned between users and the internet so that traffic can be routed through it for inspection before reaching external destinations.
When a user initiates a web request, the connection is directed to the SWG rather than going directly to the destination. The gateway evaluates the request against URL categories, reputation databases, and policy rules. For HTTPS sessions, the SWG typically establishes separate TLS sessions with the destination server and the user's device, decrypts traffic where inspection is enabled, applies security policies, then re-encrypts and forwards the traffic. When correctly configured, TLS inspection can minimise user disruption, but may still introduce latency or compatibility issues depending on deployment and policy.
Requests that violate policy are blocked at the gateway. Depending on the platform, suspicious files may be analysed in a sandbox environment before delivery. Some platforms also integrate Remote Browser Isolation for high-risk browsing scenarios. SWG maintains logs of web activity and policy events for monitoring, investigation, and compliance reporting.
Core Capabilities of SWG
URL Filtering and Web Control
URL filtering is a core capability of SWG. Web destinations are evaluated against category databases, reputation scores, and policy rules before access is allowed, blocked, or restricted. In some deployments, controls extend to full URL paths, particularly where TLS inspection is enabled. Some platforms also support limited application-level controls, such as restricting uploads within approved services.
TLS / SSL Inspection
Most web traffic is encrypted. Without TLS inspection, an SWG cannot fully evaluate session content, leaving threats and data transfers potentially undetected.
TLS inspection decrypts traffic where enabled, applies security policies, and re-encrypts it before forwarding. This can introduce performance and compatibility trade-offs, particularly where applications use certificate pinning.
Bypass policies are required for sensitive destinations and must be actively managed to prevent reduced inspection coverage.
Threat Detection and Blocking
SWG applies multiple detection and control layers on web traffic. This includes blocking known malicious destinations, detecting phishing pages, and scanning files in transit.
Depending on the platform, unknown files may be analysed in a sandbox. Some platforms also support Remote Browser Isolation for high-risk or uncategorised content.
Data Loss Prevention
Sensitive data can leave organisations through web traffic, including uploads and browser-based activity.
SWG can apply DLP controls within the inspection path, improving visibility and enforcement on outbound data transfers, including encrypted traffic where inspection is enabled.
DLP policies typically require tuning to reduce false positives and maintain effective enforcement.
How Does SWG Relate to SSE and SASE?
A Secure Web Gateway is one of the core security components within Security Service Edge (SSE). SWG focuses on securing user web traffic, while SSE brings together related cloud-delivered security services such as CASB, ZTNA, FWaaS and DLP. Together, these services help organisations apply consistent security policies across internet access, SaaS applications and private application access.
SASE goes one step further by combining the security services in SSE with networking capabilities such as SD-WAN. In simple terms, SWG secures web access, SSE brings together cloud-delivered security controls, and SASE combines security and networking into one architecture.
This means SWG can be adopted as a standalone web security control, as part of a broader SSE strategy, or as one component within a complete SASE deployment. The right approach depends on whether the organisation only needs to secure internet and SaaS access, or whether it also needs to modernise branch connectivity, WAN performance and traffic routing.
How SWG Is Deployed?
Cloud-delivered SWG: Inspection is performed through distributed Points of Presence (PoPs). This removes the need to backhaul traffic through a central corporate site. The provider manages infrastructure and updates; the organisation manages policy. This model suits distributed workforces and organisations without dedicated security infrastructure at branch locations.
On-premises SWG: Appliances within the organisation's own infrastructure process web traffic locally. This model suits regulated industries with strict data residency requirements. TLS inspection adds processing overhead that is typically underestimated at the scoping stage, and appliances sized for current traffic volumes may require replacement as usage grows.
Hybrid SWG: On-premises appliances cover locations with strict data handling requirements while cloud-delivered enforcement covers remote and branch users without backhauling their traffic. This preserves existing infrastructure investment while extending consistent policy to distributed users.
Where SWG Deployments Fall Short
These operational challenges are often less visible in vendor documentation.
TLS bypass lists that grow uncontrolled: Without active governance, bypass policies tend to expand incrementally over time as exceptions are added for application compatibility, performance concerns, and operational requirements. Left unmanaged, this can result in inspection coverage being reduced below what policy documentation assumes. Organisations that periodically audit bypass configurations frequently find that less traffic is being inspected than originally intended, particularly for encrypted sessions where TLS inspection has been selectively disabled.
DLP policies tuned to avoid complaints rather than enforce policy: Operational pressure to reduce false positives can result in rules so conservative they do not meaningfully enforce anything. The policy exists on paper; the enforcement may not exist in practice.
SSE integration that exists on paper but not in operation: SWG deployed alongside CASB, ZTNA, and FWaaS without a shared policy engine may not deliver the contextual enforcement expected from SSE architectures. Identity and device posture from ZTNA do not automatically inform SWG policy unless the integration is explicitly configured and maintained.
Sandboxing latency that can lead to pressure to relax enforcement policies: Where sandbox analysis is available and enabled, latency in high-throughput environments can generate pressure to disable it for broad file categories, reducing the effectiveness of the control.
SWG vs Related Technologies
| Technology | Primary Focus | How It Differs from SWG |
| Firewall | Controls network traffic at Layers 3–4 (IP, port, protocol). | Not primarily designed to inspect web session content in depth without additional inspection features such as TLS decryption. SWG inspects and controls web traffic at the application layer. |
| Legacy Web Proxy | Caching, bandwidth optimisation, and basic URL filtering. | Typically cannot decrypt TLS/SSL traffic. SWG extends proxy functionality with TLS inspection, advanced threat protection, DLP, application control, and in some platforms sandboxing and remote browser isolation. |
| CASB | Visibility and control over activity within SaaS applications. | Focuses on cloud application activity and data. SWG secures broader web traffic. CASB provides application-level visibility, while SWG provides web traffic inspection. Both are commonly deployed together as part of SSE. |
| DNS Filtering | Blocks domain requests during DNS resolution. | Sees only domain names, not full URL paths or session content. It cannot apply DLP or inspect encrypted traffic. SWG provides deeper inspection and policy enforcement. |
| VPN | Provides secure remote access to corporate networks. | Focuses on connectivity rather than inspection. It does not enforce policy on outbound web traffic. SWG inspects web traffic regardless of how users connect. ZTNA is increasingly replacing VPN for application access. |
| WAF | Protects web applications from inbound attacks. | Protects internet-facing applications and servers from inbound threats. SWG protects users by inspecting and controlling their outbound web traffic. The protection scope is different. |
What to Look for When Evaluating SWG
TLS inspection at scale: Ask about inspection throughput, bypass policy configurability, and how bypass lists are governed over time, not just whether TLS inspection is listed as a feature.
Remote and branch user coverage.:Cloud-delivered inspection through distributed PoPs is materially different from a solution requiring remote traffic to traverse a central site. The architecture affects both latency and policy consistency.
DLP integration: Verify whether DLP controls are applied within the proxy inspection path or through a separate downstream tool. Ask whether user identity, device posture, and application context inform DLP decisions, or whether enforcement relies on content pattern matching alone.
Advanced threat protection options: Ask whether the platform includes sandboxing or Remote Browser Isolation, and if so, how those capabilities are deployed. Understand the potential latency impact and how it is managed in high-throughput environments.
Deployment model fit: Match the deployment model to workforce distribution, data residency requirements, and compliance environment. For regulated industries, verify where TLS inspection and decrypted session content are processed and stored.
SSE integration: Ask specifically how policy context is shared across SWG, CASB, ZTNA, and FWaaS, not whether integration is technically possible, but whether identity and device posture from one component actively informs enforcement decisions in another.
How Orixcom Delivers SWG
Orixcom delivers SWG as part of a fully managed SSE and complete SASE service, built on Cisco’s architecture and security platform. SWG is configured within the same policy framework as CASB, ZTNA, and FWaaS, enabling visibility, policy consistency, and access context to be shared across the platform rather than managed in isolation per tool.
For organisations where SWG is the immediate priority, deployment begins with a visibility phase. This phase is used to identify actual traffic patterns, application usage, and potential risks before enforcement is applied. Policy is defined based on observed traffic patterns and usage within the environment, not on assumptions.