Encrypted traffic inspection in 2026: how SASE handles TLS 1.3, QUIC and certificate pinning

TL;DR. Roughly 94% of web traffic now runs over HTTPS, and the protocols underneath have changed. TLS 1.3 removed cleartext metadata, QUIC encrypts almost the entire handshake over UDP, and Encrypted ClientHello hides the destination from passive proxies. Modern SASE platforms inspect selectively, combining protocol-aware decryption with category-based exclusions for privacy-sensitive traffic. The question in 2026 is no longer whether to decrypt everything, but which traffic genuinely needs inspection given protocol changes and EU privacy constraints.

Around 94% of web requests use HTTPS in 2026, and the cryptographic protocols underneath the lock icon have evolved in ways that break legacy inspection. If your secure web gateway explained for SASE was designed for TLS 1.2 over TCP, it is already partially blind. This piece is for senior IT and security leads choosing how their Secure Access Service Edge platform should handle the inspection trade-offs. We assume you already know what a secure web gateway does, so we focus on the part most vendor documentation glosses over: how decryption actually works on TLS 1.3, what QUIC does to proxy-based architectures, and why selective decryption has become the prevailing model in European deployments.

Why TLS 1.3 broke legacy inspection

TLS 1.3, defined in RFC 8446, was designed with privacy first. It removed the cleartext key exchange that TLS 1.2 exposed, encrypts the server certificate immediately after the handshake, and mandates ephemeral Diffie-Hellman keys for every session. Perfect Forward Secrecy is no longer optional. Out-of-band passive decryption, where an inspection appliance kept a copy of the server’s private key and decrypted captured traffic offline, no longer works.

The shared session secret is negotiated using ephemeral ECDHE parameters, signed per-session, and discarded when the connection ends. Compromising the server’s long-term key tomorrow would not let you retroactively decrypt traffic captured yesterday. Enterprise inspection now requires an active proxy at the SASE gateway that terminates the connection, decrypts, re-encrypts to the destination, and relies on managed devices that trust the gateway’s root certificate authority.

In TLS 1.2 an inspection device could parse the SNI and the server’s certificate in cleartext. In TLS 1.3 the certificate is encrypted as soon as the key exchange completes. Combined with 0-RTT early-data resumption, this gives proxies less metadata to work with before deciding whether to allow the connection. For unmanaged devices without an enterprise root CA installed, TLS 1.3 inspection is not a tuning problem. It is impossible.

Encrypted ClientHello changes the SNI assumption

The last cleartext signal in a TLS 1.3 connection, the SNI extension in the initial ClientHello, is now disappearing. Encrypted ClientHello, specified in RFC 9849, splits the handshake into an outer ClientHello with a generic cover domain and an inner ClientHello encrypted using Hybrid Public Key Encryption with a key the server publishes through DNS.

ECH adoption is concentrated rather than universal. Cloudflare enforces ECH across its edge, although roughly 30% of Cloudflare-hosted origins still do not publish an ECH configuration. Chrome from version 117 and Firefox both negotiate ECH natively when they resolve the HTTPS resource record under RFC 9460. Edge follows Chrome’s behaviour.

SNI filtering, the lightweight technique where a proxy reads the destination domain from the unencrypted ClientHello, breaks when ECH is in play. Two enterprise mitigations are emerging. The first is to push browser policy disabling ECH on managed devices, such as Chrome’s EncryptedClientHelloEnabled setting. The second is to control the DNS path: a SASE-controlled resolver can strip HTTPS resource records or return NXDOMAIN for the records that publish ECH keys, which causes browsers to fall back to standard SNI behaviour. Neither is elegant. Both work.

QUIC, HTTP/3 and the inspection blind spot

QUIC, defined in RFC 9000, is not TLS over UDP. It is a new transport protocol that integrates TLS 1.3 directly into the connection layer, encrypts most packet headers including connection IDs and packet numbers, and runs over UDP/443 instead of TCP/443. HTTP/3, specified in RFC 9114, sits on top. For inspection architectures built around TCP proxies, QUIC is a harder problem than TLS 1.3.

Adoption settled differently than early forecasts suggested. HTTP/3 traffic sits at roughly 21% of global web requests in Q2 2026, well below the 30% threshold some predicted. HTTP/2 over TCP still dominates at 51%, and HTTP/1.x retains around 28%. Distribution is regional: Italy sees HTTP/3 shares above 30%, while the Netherlands and Singapore stay closer to 8-10%. The services that push QUIC hard, Google, YouTube, Gmail, Meta, WhatsApp and parts of Microsoft’s stack, account for a disproportionate share of end-user time.

Three architectural patterns dominate vendor responses to QUIC. Block and fall back drops outbound UDP/443, and HTTP/3-capable browsers fall back to TLS 1.3 over TCP automatically. This is the dominant pattern, used by default in Zscaler, Cato and Palo Alto Prisma Access. Native QUIC proxying terminates the incoming QUIC stream at a UDP-aware proxy, decrypts the payload, and connects to the origin either over QUIC or downgraded to HTTP/2 over TCP. Cloudflare One supports this, as does FortiSASE. UDP rate limiting with behavioural analysis allows unclassified UDP but applies strict per-connection limits and heuristic detection, usually as a containment layer behind one of the other two.

The practical implication for mid-market buyers: if your SASE vendor’s answer to “how do you handle QUIC?” is “we block it,” that is honest, but plan for user complaints about video and chat performance. If the answer is “we inspect it natively,” ask for documentation of the proxy architecture and which browser-origin combinations have been tested.

Certificate pinning and the apps you cannot decrypt

Even with native QUIC inspection and a perfectly deployed root CA, some traffic will not decrypt. Application-level certificate pinning, where an app’s binary embeds the public key fingerprint of its expected server certificate and rejects anything else, has spread well beyond banking apps. HTTP Public Key Pinning has been deprecated since 2018, but pinning inside native mobile and desktop apps is alive and growing.

When a SASE proxy intercepts a pinned connection, it presents the user device with a leaf certificate signed by the enterprise’s root CA. Browsers accept this. Pinned apps do not. They compare the certificate’s public key against the hardcoded pin, find a mismatch, and tear down the connection with a TLS fatal alert. The user sees the app failing to connect, often with no actionable error message.

The list of commonly pinned applications in 2026 is long enough to shape policy design rather than being a corner case.

Pinning defends users against rogue or compromised certificate authorities, which is a legitimate concern. Treating it as an obstacle to overcome is the wrong framing. Some traffic categories will not be decrypted regardless of vendor capability. Modern SASE platforms maintain dynamically updated bypass lists that exempt pinned services and substitute alternative controls: DNS-layer filtering, IP reputation, and endpoint posture checks. This is one reason selective decryption beats full decryption in practice.

Encrypted DNS is bypassing SASE policies by default

DNS used to be the simplest layer in a security stack. UDP/53, cleartext, easy to log and filter. That assumption no longer holds. By mid-2026 roughly 81-83% of global DNS queries use encrypted transport, with DoH at around 72%, DoT at 10-12%, and DoQ marginal at under 1%. Plain UDP/53 has decayed to roughly 17%.

Browser defaults are the practical pressure point. Chrome and Edge auto-upgrade DNS to DoH when the system resolver is a known major public provider that supports it, such as Cloudflare 1.1.1.1, Google 8.8.8.8 or Quad9. Both respect enterprise group policy. Firefox is more aggressive: it enables DoH by default in most regions and uses a canary check against use-application-dns.net to decide whether to defer to local DNS. If that domain returns NXDOMAIN, Firefox steps back. If it returns a normal answer, Firefox proceeds with DoH and ignores the local DNS server entirely.

For SASE platforms relying on DNS-layer filtering, this is structural. A user running Firefox on an unmanaged laptop can issue DNS queries that never touch the corporate resolver, never get logged, and never get filtered. Malware authors have noticed. DoH-based command and control channels are a routine assumption in incident response now.

The defensive pattern is layered. Block TCP/853 and UDP/853 at the firewall to remove DoT and DoQ. Resolve the Firefox canary domain to NXDOMAIN on the enterprise resolver. Maintain a denylist of known public DoH endpoints. For traffic decrypted inline, filter the application/dns-message MIME type to stop arbitrary DoH tunnelling. None is bulletproof alone. Together they restore enough visibility to be useful.

Selective decryption is the 2026 best practice

Full inspection of every encrypted session is no longer the goal. It is barely technically possible at scale, and even where it is, the privacy and regulatory cost is rarely proportionate. Modern SASE deployments use selective decryption: a policy decides per traffic category whether to terminate for inspection, bypass decryption, or substitute an alternative control. NIST SP 800-52 Rev 2 and ENISA guidance both point in this direction.

The exclusion list is what distinguishes a credible 2026 policy from a 2018 holdover. Banking, healthcare and personal email are exempt not just because of pinning but because of EDPB guidance on workplace monitoring and the proportionality principle in Article 5 GDPR. Sanctioned SaaS sits in a separate category because the right inspection point is the provider’s API, not the network. For traffic that cannot be decrypted and should not be trusted, browser isolation moves the risk surface into a disposable cloud container instead of trying to inspect what is on the wire.

Privacy and regulatory tensions in EU jurisdictions

The technical capacity to decrypt is not the same as the legal authority to deploy decryption. In every major EU jurisdiction, TLS inspection touches works council co-determination, GDPR proportionality, and the interaction with NIS2 logging. A rollout that ignores these constraints risks the inspection logs being legally inadmissible in any labour dispute, which defeats much of the operational purpose.

Germany’s Betriebsrat holds binding co-determination rights under section 87(1)(6) of the Works Constitution Act over any technical measure capable of monitoring employee behaviour. TLS decryption qualifies. A unilateral deployment without a signed Betriebsvereinbarung is legally void. The Netherlands operates similarly through the Ondernemingsraad under Article 27(1)(l) of the Wet op de Ondernemingsraden, where the works council holds a consent right rather than just a consultation right. France uses the Comité social et économique under articles L2311-1 and L2312-8 of the Code du travail; deploying without the CSE’s formal opinion can be prosecuted as délit d’entrave, with criminal liability for the employer.

Belgium regulates electronic communication monitoring through Collective Labour Agreement 81. CLA 81 permits monitoring for four specific purposes: preventing illegal or defamatory acts, protecting business secrets, ensuring network security, and verifying compliance with company rules. Continuous identified monitoring is forbidden by default. The employer must detect an irregularity at an aggregate level first, notify the employee, and only then move to targeted tracking. That sequence directly shapes how decryption logging should be configured: pseudonymise by default, identify only after a flagged event.

The EDPB’s Guidelines 05/2020 on workplace monitoring reinforce that a signed works agreement does not exempt the deployment from GDPR. The processing still needs a lawful basis, still has to meet Article 5 principles, and still requires a Data Protection Impact Assessment under Article 35. In practical terms, the DPIA is where the selective decryption exclusion list ends up being documented and defended.

NIS2 adds a layer that is often misread. Article 21 requires essential and important entities to implement effective threat detection and logging. It does not specify full TLS decryption. CCB’s CyberFundamentals framework, which Belgian organisations use to demonstrate NIS2 compliance, takes a risk-based view and accepts pseudonymised or aggregated logs as evidence of detection capability. The combination of NIS2’s detection requirement and EDPB’s minimisation guidance pushes practical deployments towards exactly the selective pattern described above.

How SASE platforms approach inspection in 2026

The major SASE vendors have settled into recognisable patterns, and the differences matter when comparing platforms.

A clear architectural split is visible. Vendors built on TCP proxy heritage (Zscaler, Cato, Palo Alto) treat QUIC as something to block. Vendors with edge or NGFW heritage extended for UDP (Cloudflare, Fortinet) inspect it natively. Neither is wrong, but the choice has consequences for user experience on QUIC-heavy services and for the operational complexity of the policy. Ask any vendor for documentation on which specific origins they have tested under each mode.

Jimber takes a cloud-native approach with selective decryption configurable by traffic category. The platform handles TLS 1.3 termination natively and supports QUIC blocking with policy-driven fallback for organisations that prefer the simpler operational model. Jimber’s SASE platform integrates browser isolation for traffic that should not be decrypted but should not be trusted either, and ties the DNS layer to per-user and per-device policy. NIAC hardware extends the same controls to agentless devices like printers, IP cameras and industrial equipment that cannot install endpoint agents. Authentication across these surfaces uses mutual TLS so policy applies the same way to managed laptops and to an IT-OT bridge in a factory. Because the infrastructure is built and operated within EU jurisdiction, the DPIA conversation starts from a stronger position than it does with US-headquartered platforms that have to assemble data residency commitments around the CLOUD Act. For organisations moving from appliance-based inspection to cloud-delivered controls, our piece on Firewall-as-a-Service covers the broader architecture context.

FAQ

Can SASE platforms inspect QUIC traffic in 2026?

Some can natively, others cannot. Cloudflare One and FortiSASE support inline QUIC and HTTP/3 inspection through UDP-aware proxies. Zscaler, Cato and Palo Alto Prisma Access block UDP/443 to force browsers to fall back to TCP-based TLS 1.3.

Does TLS 1.3 prevent enterprise traffic inspection?

No, but it changes how inspection works. TLS 1.3 mandates Perfect Forward Secrecy, so passive out-of-band decryption is no longer possible. Inspection now requires an active proxy that terminates the connection on a managed device that trusts the enterprise root CA.

What is Encrypted ClientHello and does it affect SASE deployments?

ECH, specified in RFC 9849, encrypts the Server Name Indication using a key the server publishes in DNS. It breaks SNI-based filtering for unmanaged devices. SASE platforms typically mitigate ECH by enforcing browser policy on managed devices or by stripping HTTPS resource records at the enterprise DNS resolver.

Which applications use certificate pinning that prevents decryption?

Common examples include WhatsApp, Signal, Apple iCloud and Push Notification services, Microsoft Teams, Slack, Salesforce, Zoom, Google Drive, Spotify, Netflix, and most mobile banking apps. Pinned applications detect the substitute certificate that a SASE proxy presents and refuse to connect.

Is full TLS decryption required for NIS2 compliance?

No. NIS2 Article 21 requires effective threat detection and logging, not full decryption of every session. The CCB’s CyberFundamentals framework accepts selective decryption combined with pseudonymised logging as evidence of detection capability, provided the approach is risk-justified.

How does DNS over HTTPS bypass enterprise filtering?

DoH wraps DNS queries inside standard HTTPS on TCP/443, making them indistinguishable from normal web traffic without inline TLS inspection. Firefox in particular auto-upgrades to DoH and can bypass enterprise resolvers entirely. Mitigations include blocking known DoH endpoints, returning NXDOMAIN for canary domains, and filtering the application/dns-message MIME type.

What is selective TLS decryption and when should it be used?

Selective decryption applies decryption policy per traffic category, exempting sensitive categories like banking, healthcare and sanctioned SaaS while inspecting general web traffic and cloud storage. It should be the default approach for any organisation operating under GDPR or EU works council frameworks, because it directly addresses proportionality and minimisation obligations while preserving meaningful inspection.

Encryption inspection in 2026 has become less a question of technical capacity and more a question of which traffic genuinely needs to be opened. Protocol changes have closed off the easy paths, and EU privacy law has closed off most of the brute-force ones. A SASE platform that handles TLS 1.3 termination natively, makes a deliberate choice about QUIC, supports selective decryption configurable by category, and integrates browser isolation for traffic that cannot or should not be decrypted gives mid-market teams a defensible position under both NIS2 and works council scrutiny. If you want to see how Jimber configures this for a European mid-market environment, book a demo and we will walk through the policy framework with you.