The Mobile TLS Inspection Gap: No SASE Vendor Scores Above 60%

The Blind Spot in Your SASE Deployment

Mobile devices now account for over 60% of enterprise network traffic. Employees access corporate SaaS apps, email, and sensitive documents from phones and tablets throughout the day — often on networks you do not control. TLS inspection is the foundation of any SASE security stack: without decrypting and inspecting traffic, your DLP policies, threat prevention, and access controls are operating blind.

So how well do SASE vendors actually inspect TLS traffic on mobile devices?

We tested 8 major SASE platforms across 10 specific mobile TLS inspection checks, covering iOS and Android, managed and unmanaged devices, native apps and browsers, and edge cases like certificate pinning and QUIC/HTTP3. The results are sobering.

The best score in the industry is 60%. The worst is 10%. And there are specific scenarios — like inspecting traffic from cert-pinned apps or operating without MDM — where no vendor has a complete answer.

The Scores: Vendor by Vendor

For context, these same vendors score 70-90% on desktop TLS inspection. Mobile is a fundamentally harder problem, and the gap is significant.

Zscaler leads with 6 out of 10 confirmed capabilities — a clear first place, but still leaving 40% of checks as PARTIAL. Netskope, which competes head-to-head with Zscaler on desktop security features, manages just 1 YES out of 10 on mobile TLS. Palo Alto Networks, a top-3 vendor in our overall SASE ranking, scores only 20%.

The PARTIAL answers are not consolation prizes. PARTIAL means the capability technically exists but comes with meaningful limitations — requiring specific OS versions, MDM enrollment, manual configuration, or only covering certain traffic types. In security, partial inspection creates a false sense of coverage.

The Three Questions That Break Every Vendor

Across the 10 checks, three questions exposed gaps that span the entire industry.

1. Works Without MDM Enrollment

Result: No vendor scores YES. Netskope scores NO.

This is arguably the most important question for organizations with BYOD policies or contractors. If your mobile TLS inspection requires MDM enrollment, you are either forcing personal device management (which employees resist and privacy regulations may prohibit) or you are not inspecting that traffic at all.

Every vendor we tested returned PARTIAL or worse on MDM-free operation. The "partial" implementations typically involve a lightweight app-based approach that can inspect browser traffic but misses native app traffic, or requires manual certificate installation steps that reduce adoption rates. Netskope returned a hard NO — its mobile TLS inspection architecture depends on device management infrastructure.

For organizations where 30-50% of mobile devices are unmanaged, this single gap means a substantial portion of mobile traffic flows uninspected regardless of which SASE vendor you choose.

2. Inspects Native App Traffic on iOS

Result: Only Zscaler scores YES. All others PARTIAL.

Apple's iOS imposes strict restrictions on traffic interception. Unlike Android, where a VPN-based approach can capture most traffic, iOS sandboxes apps aggressively and limits what third-party software can intercept. The technical challenge is real: iOS does not allow global proxy configurations to be enforced programmatically without MDM, and even with MDM, certain system-level traffic bypasses inspection.

Zscaler's approach uses a combination of its mobile agent (Zscaler Client Connector) and tunnel-based interception that covers native app traffic on iOS more completely than competitors. The other seven vendors technically intercept some native app traffic but with documented gaps — certain apps, certain network conditions, or certain iOS versions where inspection fails silently.

This matters because on iOS devices, the majority of enterprise-relevant activity happens in native apps: Outlook, Teams, Slack, Salesforce, and dozens of line-of-business applications. If you are only inspecting Safari traffic, you are missing most of what your users are doing.

3. Handles Certificate-Pinned Applications

Result: Palo Alto and Fortinet score NO. Everyone else PARTIAL. Nobody scores YES.

Certificate pinning is a technique where an application hardcodes the expected TLS certificate, refusing to accept the SASE vendor's inspection certificate even if it is trusted by the OS certificate store. Many popular apps use cert pinning — including banking apps, some healthcare apps, and increasingly, major SaaS platforms in their mobile clients.

No SASE vendor fully solves certificate pinning on mobile. The PARTIAL approaches involve maintaining bypass lists for known cert-pinned apps (letting that traffic flow uninspected) or attempting to use vendor-specific hooks that work on some apps but not others. Palo Alto Networks and Fortinet do not attempt to handle cert-pinned traffic at all on mobile, returning a clear NO.

This is not just an edge case. As more app developers adopt certificate pinning for their own security reasons, the percentage of mobile traffic that SASE platforms cannot inspect will grow over time. It is a structural gap, not a temporary limitation.

Where Vendors Do Deliver

Not every check was a failure. Two areas showed strong results across most vendors.

Always-On Enforcement

Most vendors scored YES on ensuring the mobile agent stays active and cannot be easily disabled by the end user. This is table stakes for mobile security — if users can simply turn off the agent, no amount of inspection capability matters. The implementations vary (VPN profiles that auto-reconnect, device compliance checks, admin-locked configurations) but the outcome is consistent.

Per-App Exception Granularity

Most vendors scored YES on the ability to configure TLS inspection exceptions on a per-app basis. This is critical for handling the cert-pinning problem pragmatically: if you cannot inspect an app, you need to be able to exclude it cleanly rather than breaking the user experience. The irony is that this capability — the ability to NOT inspect specific apps — is better supported than the ability to actually inspect them.

QUIC/HTTP3 Handling

Results were mixed on QUIC and HTTP3 protocol handling. Some vendors block QUIC to force fallback to standard TLS (which they can then inspect), while others have native QUIC inspection capabilities in development. This is a rapidly evolving area — QUIC traffic is growing as more services adopt HTTP3, and vendors that cannot handle it will see an increasing share of uninspected traffic.

Why This Gap Exists

The mobile TLS inspection gap is not a result of vendor negligence. It reflects genuine technical constraints imposed by mobile operating systems.

iOS is the primary challenge. Apple has progressively tightened restrictions on traffic interception, network extensions, and certificate management. Each iOS update can break previously working inspection mechanisms. Apple's stated goal is user privacy, which directly conflicts with enterprise TLS inspection requirements. SASE vendors are building on a platform that is actively working against them.

Android is more permissive but fragmented. Android allows more aggressive traffic interception through its VPN API, but the Android ecosystem spans hundreds of device manufacturers, OS versions, and OEM customizations. What works on a Pixel running stock Android may fail on a Samsung device with Knox or a Xiaomi device with MIUI. Testing and maintaining compatibility across this fragmentation is a massive engineering challenge.

Certificate pinning is an arms race. App developers pin certificates to prevent man-in-the-middle attacks — which is exactly what TLS inspection is, from the app's perspective. There is no standards-based solution that lets enterprise security tools bypass certificate pinning without the app developer's cooperation.

Performance constraints matter. Mobile devices have limited battery and processing power. Full TLS inspection on every network connection introduces latency and battery drain that degrades user experience. Vendors must balance inspection depth against usability, and on mobile, usability constraints are more binding.

What This Means for Your Evaluation

If mobile TLS inspection is a priority for your organization — and given mobile traffic volumes, it should be — here is how to approach your SASE evaluation:

1. Do not assume desktop parity. A vendor's desktop TLS inspection score tells you almost nothing about mobile. Zscaler leads both, but Palo Alto Networks goes from top-3 overall to 20% on mobile TLS. Netskope goes from market leader to last place. Always evaluate mobile capabilities separately.

2. Test on your actual device mix. The PARTIAL answers in our data often mean "works on some devices/OS versions but not others." If your workforce is 70% iOS, test on iOS specifically. If you support BYOD with a mix of device types, test the lowest-common-denominator scenario.

3. Quantify your uninspected traffic. Ask vendors directly: given our device mix and app portfolio, what percentage of mobile traffic will flow uninspected? Demand specifics, not marketing answers. Any vendor that claims 100% mobile TLS inspection coverage is not being honest.

4. Plan for the cert-pinning gap. No vendor solves certificate pinning on mobile. Your security architecture needs to account for a growing category of traffic that cannot be inspected at the network layer. Compensating controls — endpoint-based DLP, app-level security policies, CASB API integrations — become essential for these blind spots.

5. Evaluate MDM dependency carefully. If a vendor's mobile TLS inspection requires MDM enrollment, factor in the operational cost and employee friction of MDM deployment. For BYOD-heavy organizations, MDM-dependent solutions may leave the majority of mobile devices uninspected.

6. Re-evaluate annually. Mobile OS updates (especially iOS) can break existing inspection mechanisms. A vendor that scores well today may regress after the next major OS release. Build re-evaluation cycles into your security program.

The Bottom Line

Mobile TLS inspection is the single weakest capability area across the entire SASE market. The industry's best score is 60%. Three critical scenarios — MDM-free operation, iOS native app inspection, and certificate-pinned apps — defeat every vendor to some degree.

This does not mean SASE is failing. It means mobile security requires a layered approach that goes beyond network-level TLS inspection. Endpoint controls, API-based CASB, app-level policies, and zero trust access controls all play a role in covering the gaps that TLS inspection cannot reach on mobile.

But it does mean that if your SASE evaluation treats mobile TLS inspection as a checkbox — "yes, the vendor supports it" — you are likely overestimating your actual security coverage by a significant margin.

The data is clear. The gap is real. Plan accordingly.

Data based on SASECompare independent testing of 8 SASE vendors across 10 mobile TLS inspection checks. Full interactive results with cited sources available at [TLS Inspection on Mobile](/compare/tls-mobile). Scores current as of March 2026.