The Question
The Secure Web Gateway is typically described as the control point for enterprise web traffic — the platform that enforces acceptable use policy, detects malware in web downloads, and blocks access to malicious or inappropriate content. Security teams budget for it, vendors market it extensively, and compliance frameworks cite it as a required control for internet-bound traffic.
Here is the question that is asked less often: what percentage of that traffic is actually being inspected?
Google's HTTPS Transparency Report has tracked the share of web traffic encrypted with TLS for years. The current figure — consistently above 95% for Chrome desktop traffic — represents the floor for any enterprise with a managed Chrome deployment. Nearly every web page, file download, cloud application API call, and browser-based communication the average enterprise user generates is encrypted before it leaves the endpoint.
A Secure Web Gateway that does not perform TLS inspection — that does not decrypt, inspect, and re-encrypt HTTPS traffic — can apply URL reputation filtering and domain categorization to the destination addresses it sees. It cannot inspect what is inside those encrypted streams. It cannot detect malware in an HTTPS download from a compromised but trusted domain. It cannot identify sensitive data in an HTTPS upload to an unapproved service. It cannot see command-and-control traffic in encrypted HTTPS sessions.
The protection that most SWG deployments are implicitly assumed to provide requires TLS inspection. For the majority of enterprise SWG deployments, TLS inspection is either disabled entirely, configured with so many bypass exceptions that coverage is functionally minimal, or operating at reduced fidelity due to performance constraints.
A Secure Web Gateway that doesn't inspect TLS traffic is a threat detection tool with a 90% blind spot — and most enterprise SWG deployments have TLS inspection either disabled or configured with so many bypass exceptions that the coverage is effectively the same.
Why This Matters Now
The scale of the gap became undeniable as malware delivery shifted decisively to encrypted channels. Zscaler's ThreatLabz 2024 Encrypted Attacks Report documented that 87% of all threats analyzed by the platform were delivered over HTTPS — up from 70% in their 2021 report. The trend line is not ambiguous: threat actors have followed enterprise traffic patterns and migrated malware delivery to the same encrypted channels that enterprises use for legitimate business traffic.
The specific delivery mechanisms that make this dangerous are worth enumerating. Phishing pages are almost universally served over HTTPS, with valid TLS certificates obtained through free CAs like Let's Encrypt. A phishing page with a valid TLS certificate is indistinguishable to an SWG without TLS inspection from any other HTTPS site — the certificate validates, the connection is encrypted, and the malicious HTML payload is never seen by the gateway.
Malware downloads from compromised legitimate infrastructure are particularly difficult to catch without TLS inspection. When threat actors compromise a legitimate website — a content delivery network endpoint, a software distribution platform, a cloud storage bucket — and use it to serve malware, URL reputation filtering does not help. The domain has a clean reputation because it is a legitimate domain that has been temporarily compromised. The only way to detect the malicious payload is to inspect the content of the download, which requires decrypting the HTTPS connection.
Command-and-control traffic presents a similar problem. Modern malware increasingly uses HTTPS for C2 communications precisely because it blends with normal business traffic and is invisible to network security tools that cannot inspect encrypted traffic. Cobalt Strike, the most widely deployed commercial attacker toolkit in 2024 and 2025, defaults to HTTPS C2 channels and includes malleable C2 profiles specifically designed to make C2 traffic look like legitimate web application traffic.
In November 2024, the Cybersecurity and Infrastructure Security Agency (CISA) updated its advisory on TLS inspection specifically noting that organizations that had not enabled TLS inspection in their gateway products were operating with a significant blind spot against current threat actor techniques. The advisory cited multiple specific APT campaigns where encrypted C2 traffic was the detection failure point — the organizations had network security tools deployed, but the tools could not see the traffic carrying the threat.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated SWG and SSE platforms specifically on TLS inspection performance, scalability under inspection load, and bypass policy management — the three dimensions where platforms diverge most significantly.
Zscaler led the Leaders tier on TLS inspection scale, with its cloud-native architecture enabling full TLS inspection across large enterprise deployments without the performance degradation that characterizes hardware-based or VM-based inspection solutions. Zscaler's purpose-built TLS inspection infrastructure — operating at cloud scale rather than on customer-managed appliances — is the strongest argument for cloud-delivered SSE over on-premises SWG for enterprises that require comprehensive TLS inspection coverage.
Netskope placed competitively on inspection policy granularity, with fine-grained bypass control that allows enterprises to define exactly which traffic categories are inspected versus bypassed, enabling compliant, well-documented bypass policies that reduce privacy and compliance risk without eliminating coverage for high-risk traffic categories.
Palo Alto Networks' Prisma Access and Cloudflare Gateway both received strong marks for hardware-assisted decryption performance in their respective architectures. Palo Alto's integration with its threat intelligence infrastructure (WildFire, Unit 42) adds a threat intelligence dimension to inspected traffic analysis that pure URL-filtering approaches do not provide.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
Every enterprise that has considered TLS inspection has confronted the same set of objections. Understanding which objections are technically valid, which are operationally manageable, and which are risk acceptance decisions in disguise is essential to making an informed architecture choice.
Performance degradation under inspection load
This objection was more valid in 2018 than it is in 2026. On-premises hardware SWG appliances and first-generation virtual appliances were genuinely constrained on TLS inspection throughput — full inspection of a large enterprise traffic volume required hardware investments that were not always in security budgets.
Cloud-delivered SSE platforms have largely eliminated this constraint. When TLS inspection runs in a purpose-built cloud service rather than on a customer-managed appliance, the compute resources scale horizontally with demand. The performance argument is a valid reason to prefer cloud-delivered SSE for TLS inspection over on-premises hardware solutions. It is not a valid reason to forgo TLS inspection entirely.
Privacy concerns for sensitive traffic categories
Some traffic legitimately warrants bypass from TLS inspection: online banking sessions, healthcare portal access, personal email accessed on corporate networks. Employees have reasonable expectations that their bank account interactions will not be decrypted and inspected by their employer's security infrastructure. Regulated industries have additional compliance considerations around decrypting traffic that may contain customer financial data or protected health information.
The correct response to privacy concerns is a well-defined, documented bypass policy — not disabling TLS inspection globally. Modern SSE platforms support granular bypass policies by URL category, domain, application, and user group. A bypass policy that excludes financial services domains, personal email providers, and healthcare portals while maintaining full inspection of all other HTTPS traffic preserves meaningful privacy while providing substantial threat coverage.
The SSL-pinned app problem
Some mobile applications and thick client software implement SSL pinning — they only accept connections signed by a specific certificate chain and reject enterprise CA certificates used for TLS inspection. SSL-pinned apps break under TLS inspection environments. The practical resolution is an application-specific bypass for pinned apps — the same bypass policy mechanism used for privacy-sensitive traffic categories.
Certificate trust chain management
TLS inspection requires deploying an enterprise CA certificate to managed endpoints so they trust the SWG's re-signed certificates. This is a standard enterprise PKI operation, well-supported by MDM platforms and Group Policy. It is an operational task, not a technical barrier. The complexity is proportional to the organizational diversity of the managed endpoint population.
The bypass exception accumulation problem
The most common failure mode in TLS inspection deployments is not a single exception — it is exception accumulation over time. Each new application that breaks under TLS inspection generates a helpdesk ticket. The fastest resolution is a bypass exception. Over months and years, bypass exception lists grow to the point where the categories of traffic excluded from inspection constitute a majority of enterprise traffic volume. The security team believes TLS inspection is providing coverage; the bypass exception list tells a different story.
Preventing this failure mode requires treating bypass exceptions as security policy changes — requiring documented justification, periodic review, and ownership assignment. It requires a process, not just a technical control.
Questions Your Buying Team Should Be Asking
1. What percentage of our current web gateway traffic is subject to TLS inspection, and can you show us the bypass exception list?
This question forces an accurate current state assessment. Many security teams believe TLS inspection is active and providing coverage because the feature is enabled — but the bypass exception list may cover 50–70% of actual traffic volume. Run the traffic volume through the bypass categories to understand actual inspection coverage versus nominal inspection capability.
2. What is the performance impact of full TLS inspection on our current SWG platform, and have we actually measured it?
In cloud-delivered SSE platforms, the performance impact of TLS inspection on the endpoint user experience should be minimal — the compute overhead is absorbed by the cloud service. In on-premises or hybrid deployments, this requires measurement. Require the vendor to provide inspection throughput benchmarks at the traffic volumes relevant to your deployment, not theoretical maximums.
3. How does your platform handle certificate pinning in mobile apps and thick clients, and what is the recommended bypass approach?
Understand the vendor's recommended process for identifying and handling certificate-pinned applications. Verify that the bypass mechanism is granular — per-application or per-domain bypass rather than categorical bypass of all mobile traffic or all client software traffic.
4. What bypass policy management capabilities does your platform provide, and how do you prevent bypass exception accumulation over time?
Ask specifically about bypass policy governance features: approval workflows for new exceptions, periodic review scheduling, traffic volume reporting by bypass category, and audit logging of bypass policy changes. A platform with strong bypass governance reduces the operational risk of exception accumulation that erodes TLS inspection coverage over time.
5. What threat detection capabilities does your platform apply to inspected TLS traffic, and how does that integrate with your threat intelligence feeds?
TLS inspection that produces decrypted traffic which is then passed through only basic URL filtering has limited additional value over non-inspected filtering. Understand what the platform does with access to the decrypted payload: malware signature scanning, behavioral sandboxing for suspicious downloads, DLP policy application to uploads, C2 traffic behavioral analysis. The threat detection capability applied to decrypted traffic determines the security value of the inspection investment.
The Stackcurve Take
The TLS inspection decision is the single most consequential configuration choice in a Secure Web Gateway deployment. It is not a feature toggle — it is an architectural decision that determines whether the platform is operating as a genuine threat detection control or as a sophisticated URL filter with a compliance checkbox next to it.
The objections to TLS inspection are real but manageable. Performance constraints are largely resolved by cloud-delivered architectures. Privacy concerns are addressable through well-designed bypass policies. Certificate trust chain management is a standard IT operation. The argument that TLS inspection is too complex or too costly to implement is, in 2026, an argument that SWG investment is providing capabilities the organization is choosing not to use.
The more honest framing is that TLS inspection requires organizational commitment — to bypass policy governance, to certificate management, to the occasional helpdesk ticket when an application breaks. Organizations that are not willing to make that commitment should calibrate their expectations for what their SWG is actually detecting accordingly.
For organizations that are making the commitment, the cloud-delivered SSE market has matured to the point where TLS inspection at enterprise scale, with adequate performance and granular bypass policy management, is available from multiple vendors. The capability gap that existed in 2018 has been closed. What remains is the organizational will to close the inspection gap.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers SWG platforms and TLS inspection capabilities in detail, including performance benchmarks and bypass policy management comparisons by vendor. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.