TLS inspection is one of those ideas that sounds completely reasonable right up until you try to turn it on.
On a Zero Trust slide, it’s neat and obvious. In a real environment, it’s where security goals collide with fragile apps, privacy constraints, and the realities of how people actually work.
Why TLS inspection exists in GSA #
Without TLS inspection, GSA can still enforce useful controls:
- Destination filtering
- SNI-based policy
- Identity and device context
- Traffic category enforcement
That’s good, but it’s not enough when:
- Malware is delivered over HTTPS
- Command-and-control traffic blends effortlessly in with “normal” SaaS applications.
- Risky uploads are encrypted end-to-end
TLS inspection exists to give you payload visibility where metadata alone can’t help.
The risks vendors downplay #
TLS inspection is not a free security win. You are deliberately inserting a trusted man-in-the-middle into user traffic. That has consequences.
1. Privacy and legal exposure #
Once you decrypt traffic, you own:
- What you inspect
- What you log
- How long you retain it
- Who can access it
If you can’t explain that clearly to legal or HR, stop here.
2. Application breakage #
Some things will break:
- Certificate pinning
- Modern mobile apps
- Weird Electron apps
- Authentication and SSO flows
This isn’t a “maybe”. It’s guaranteed.
3. PKI blast radius #
Your TLS inspection CA becomes one of the most powerful trust anchors in your environment.
If it’s:
- Reused
- Poorly protected
- Badly rotated
…you’ve just created your own internal nightmare scenario.
Certificate strategy that won’t haunt you #
The only sane approach is a dedicated TLS inspection CA.
Do not:
- Reuse your enterprise issuing CA
- Reuse a VPN inspection CA
- Use a long-lived root with no rotation plan
What actually works #
- Dedicated inspection CA (used only for GSA TLS inspection)
- Strong key protection and access controls
- Short-lived leaf certificates
- A documented rotation and incident plan
Gut check:
If you had to rotate the inspection CA in a week due to compromise, could you do it without breaking the org?
If the answer is no, you’re not ready for broad inspection.
A rollout plan that won’t melt your helpdesk #
Phase 1 — Baseline first #
- Enable GSA routing and policies without TLS inspection
- Understand traffic patterns
- Build a do-not-decrypt list early:
- Banking
- Healthcare
- Identity providers
- Authentication endpoints
Phase 2 — Narrow inspection #
- Small pilot group (IT, security, and a few brave users)
- Inspect only high-value categories:
- Known malware delivery paths
- High-risk download categories
- Track breakage like a product backlog, not a blame exercise
Phase 3 — Expand by traffic, not org chart #
- Scale inspection by traffic category
- Keep exclusions explicit and reviewed
- Time-bound exceptions — nothing lasts forever by default
Things that will bite you #
You can pretend these won’t happen, but they will:
- Certificate pinning silently bypassing or breaking inspection
- Authentication loops when TLS inspection touches login flows
- Performance issues under peak load
- Log volume explosions if you don’t scope telemetry carefully
Plan for them up front and you’ll look smart later.
What I recommend for most environments #
Start with minimum viable inspection.
Decrypt only what supports a control you can clearly justify:
- Malware prevention
- Known bad categories
- Specific upload and download paths
You still get real security value without turning TLS inspection into an ideological crusade.
What we actually inspect (and where to see it) #
In GSA, TLS inspection is not enabled globally. It’s deliberately scoped to traffic where decryption gives real security value and low operational risk.
Entra Portal → Global Secure Access → Internet Access → TLS Inspection
https://entra.microsoft.com/#view/Microsoft_AAD_NetworkAccess/TlsInspectionMenuBlade
We inspect traffic when #
TLS inspection is enabled only if both of these are true:
- The traffic is high-risk or commonly abused for malware delivery or data exfiltration
- There’s no certificate pinning or known application behavior that would break the connection
If either condition isn’t met, inspection stays off.
Typical traffic we allow inspection on #
This is where inspection consistently pays off without causing outages:
- Random or unknown CDNs
- File-sharing and download platforms
- Low-reputation or newly registered domains
- Non-critical SaaS where inspection failure is acceptable
If breaking inspection would impact revenue, authentication, or core workflows — it doesn’t belong here.
How we validate a domain before inspecting it #
Before enabling TLS inspection for a domain or category, we check what certificate it actually presents. This catches pinning, unusual chains, and vendors doing “creative” TLS things.
macOS / Linux (OpenSSL) #
openssl s_client -connect example.com:443 -servername example.com </dev/null \
| openssl x509 -noout -issuer -subject