TLS Inspection in SASE Explained

TLS inspection is non-negotiable — 95%+ of web traffic is encrypted, and without decryption your security stack is blind. Deploy root CA certificates to all endpoints two weeks before go-live. Maintain a bypass list for certificate-pinned apps (banking, healthcare, government sites). The number one SWG deployment killer is breaking a revenue-generating app and taking hours to unblock it.

TLS inspection (also called SSL inspection or break-and-inspect) is the process by which a SASE platform's Secure Web Gateway terminates the client's TLS session, decrypts the traffic, inspects the cleartext content for threats and policy violations, and then re-encrypts the traffic over a new TLS session to the destination server. This man-in-the-middle decryption is the foundational capability that makes SWG, inline CASB, and DLP effective against encrypted traffic — which is over 95% of all web traffic in 2026. Without TLS inspection, your entire cloud security stack is inspecting metadata (SNI hostnames, IP addresses, certificate fields) while the actual content — including malware payloads, data exfiltration, and policy violations — flows past uninspected inside encrypted tunnels.

How TLS inspection works technically

The TLS inspection process involves four parties: the user's browser (or application), the SASE SWG proxy, a custom Certificate Authority (CA) controlled by your organization, and the destination web server. When a user navigates to https://example.com, the request is intercepted by the SWG proxy (via PAC file, endpoint agent, or tunnel onramp). The SWG terminates the TLS handshake with the browser, presenting a certificate for example.com that is dynamically generated and signed by your organization's custom CA. The browser trusts this certificate because your custom CA is installed in the endpoint's trusted root certificate store. The SWG simultaneously initiates a separate TLS handshake with the real example.com server using the server's legitimate certificate.

With both TLS sessions established, the SWG decrypts traffic from the browser, inspects the cleartext HTTP content through its security pipeline (URL categorization, malware scanning, DLP pattern matching, CASB controls), and if the content passes policy, re-encrypts it and forwards it through the server-side TLS session. Response traffic follows the reverse path: decrypted from the server session, inspected, re-encrypted for the browser session. This entire process — TLS termination, decryption, inspection, re-encryption, and forwarding — adds latency to every request. Well-optimized SASE platforms add 2 to 8 milliseconds per request; poorly optimized ones add 20 to 50 milliseconds, which users notice.

Certificate deployment: the operational foundation

TLS inspection does not work until your custom CA certificate is installed on every endpoint. This is the single most common source of deployment delay and user frustration. Every operating system and browser has its own certificate store with its own deployment mechanism, and some applications maintain their own certificate stores independent of the OS.

• Windows: Deploy via Group Policy (Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root CAs) or Intune configuration profiles. Covers Edge, Chrome, and Internet Explorer. Firefox maintains its own certificate store — deploy separately via Firefox enterprise policy or about:config settings.
• macOS: Deploy via MDM profiles (JAMF, Mosyle, Kandji, or Intune) as a trusted root certificate payload. Covers Safari, Chrome, and Edge. Firefox again requires separate deployment through its own certificate store.
• iOS: Deploy via MDM as a supervised device management profile. The certificate must be both installed AND trusted (Settings > General > About > Certificate Trust Settings). Unsupervised personal devices require user action to trust the certificate.
• Android: Deploy via Android Enterprise managed device profiles for fully managed devices. Work Profile deployments install the certificate in the work profile only — personal apps in the personal profile will not trust it. This is by design for employee privacy.
• Linux: Deploy to the system CA bundle (/etc/pki/ca-trust/source/anchors/ on RHEL, /usr/local/share/ca-certificates/ on Ubuntu), then run the update-ca-trust or update-ca-certificates command. This covers system tools and most browsers but NOT application-specific certificate stores. Python uses certifi, Java uses its own keystore (cacerts), Node.js uses an environment variable (NODE_EXTRA_CA_CERTS), and Go uses the system store. Developer workstations require per-language certificate configuration.

What breaks under TLS inspection

Certificate-pinned applications

Certificate pinning is a security mechanism where an application embeds (pins) the expected server certificate or public key directly into the application code. When the SWG re-signs the traffic with your custom CA certificate, the pinned application sees a certificate that does not match its pinned expectation and refuses to connect. This is working as designed — certificate pinning exists to prevent exactly the kind of man-in-the-middle interception that TLS inspection performs. Applications that commonly use certificate pinning include banking and financial applications, healthcare portals, government services, mobile banking apps, some EDR and security tool phone-home connections, Windows Update and Microsoft Defender, and Apple services (iCloud, App Store).

The only solution for certificate-pinned applications is to bypass TLS inspection for those specific domains. You cannot modify the application's pinned certificate expectations (unless you control the application). This is why every SWG deployment needs a well-maintained bypass list from day one. Every SASE vendor publishes a recommended bypass list — start there and add to it aggressively during your first two weeks of deployment.

Mutual TLS (mTLS) applications

Some applications use mutual TLS where both the client and server present certificates to each other. Corporate VPN clients, some API integrations, IoT device communications, and certain financial services applications use mTLS. TLS inspection breaks mTLS because the SWG terminates the client-side connection — the client's certificate is presented to the SWG, not to the destination server. The server-side connection initiated by the SWG does not carry the client certificate. Bypass TLS inspection for all mTLS traffic. Some vendors support mTLS passthrough where the SWG relays the client certificate without terminating the client session, but support for this is inconsistent across vendors.

Performance-sensitive applications

Every TLS-inspected request incurs additional latency from decryption, inspection, and re-encryption. For web browsing, the 2 to 8ms overhead is imperceptible. For real-time applications — video conferencing, VoIP, high-frequency trading platforms, gaming — even small latency additions compound across hundreds of concurrent connections and degrade user experience. Most SASE vendors recommend bypassing TLS inspection for real-time communication protocols (Microsoft Teams, Zoom, WebEx media streams). These platforms already encrypt their traffic and have their own security controls; inspecting them adds latency without meaningful security benefit.

Building and maintaining bypass lists

Your TLS inspection bypass list will be your most frequently updated security artifact for the first 6 months of deployment. Start with your vendor's recommended bypass list, which typically includes 30 to 50 domains covering certificate-pinned services, OS update mechanisms, EDR phone-home domains, and major real-time communication platforms. Then add your own entries based on application inventory: banking websites your finance team uses, healthcare portals your HR team accesses, government services for compliance reporting, and any internal application that uses mTLS or client certificates.

Establish a bypass request process: when a user reports that an application is broken after TLS inspection is enabled, the helpdesk should be able to add a bypass entry within minutes, not days. Create a rapid-response bypass workflow: user reports the issue, L1 support validates that TLS inspection is the cause (check the SWG logs for certificate errors), L1 adds the domain to the bypass list (or escalates to L2 if the domain requires security review), and the bypass takes effect within 5 minutes. If this workflow takes hours, you will lose organizational trust in the SASE deployment after the first broken application.

Review your bypass list quarterly. Over time, bypass lists grow as entries are added reactively but never removed. Some bypassed domains may have resolved their certificate pinning issues, some may have been acquired by different companies, and some may represent security blind spots that you accepted temporarily but should revisit. A bypass list with 500+ entries suggests that TLS inspection is providing less security value than advertised — each bypassed domain is a channel where malware and data exfiltration can flow uninspected.

Performance impact measurement

Measure TLS inspection latency impact explicitly during your PoC and early deployment. Use synthetic monitoring tools (your SASE vendor's DEM, ThousandEyes, Catchpoint, or simple curl timing scripts) to measure page load times with and without TLS inspection for the same set of test URLs. Measure: DNS resolution time (should be unchanged), TCP handshake time (should be unchanged), TLS handshake time (will increase — this is where inspection adds latency), time to first byte (will increase proportional to inspection depth), and total page load time (the user-visible metric).

Acceptable performance impact varies by application. For general web browsing, up to 50ms total additional page load time is imperceptible. For SaaS applications where users make hundreds of requests per session, even 10ms per request compounds to noticeable slowness. For API-driven integrations with tight timeout settings, any added latency can cause timeout failures. Tune your inspection policies accordingly: full inspection for web browsing, selective inspection for SaaS (inspect file uploads and downloads, skip API calls), and no inspection for real-time and latency-sensitive applications.

Compliance and legal considerations

TLS inspection means your organization is decrypting and inspecting employee web traffic, including traffic to personal banking, healthcare, and other sensitive sites (unless bypassed). This has legal and compliance implications that vary by jurisdiction. In the European Union, intercepting employee personal communications may conflict with GDPR privacy provisions — consult legal counsel and implement appropriate bypass lists for personal finance and healthcare domains. In the United States, most states allow employer monitoring of corporate device traffic with appropriate notice. In healthcare environments, ensure TLS inspection bypass lists include patient portals and telehealth platforms to avoid compliance issues with HIPAA.

Regardless of jurisdiction, notify employees that web traffic on corporate devices is monitored and inspected. Include this in your acceptable use policy and display it during the SWG captive portal for first-time users. Transparency about inspection practices avoids legal issues and reduces employee pushback. From a technical compliance perspective, ensure that your TLS inspection architecture maintains PCI DSS compliance if you process credit card data — inspected traffic must remain encrypted in transit, and the SWG's cleartext inspection must not expose cardholder data to unauthorized systems or personnel.

Sources & further reading

• IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — rfc-editor.org/rfc/rfc8446
• Cloudflare, "What is TLS/SSL inspection?" — cloudflare.com/learning/security/what-is-https-inspection
• NIST SP 800-52 Rev. 2, "Guidelines for the Selection, Configuration, and Use of TLS Implementations" — nist.gov/publications/guidelines-selection-configuration-and-use-tls-implementations
• Cisco, "TLS/SSL Decryption Best Practices for Secure Access" — cisco.com/c/en/us/products/security/secure-access
• SANS Institute, "SSL/TLS Interception Proxies and Transitive Trust" — sans.org/white-papers/ssl-tls-interception

Related on sase.cloud

One email per publish. Unsubscribe anytime.