Global Secure Access: TLS Inspection (What Actually Matters)

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 deeper visibility where metadata alone can’t help.

#

The risks Microsoft downplays

#

TLS inspection is not a free security win. You are deliberately inserting a trusted man-in-the-middle into user traffic, a step that can have broader implications.

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

In Australia, under the Privacy Act, you’re only allowed to collect personal information if it’s reasonably necessary for your function and collected by lawful and fair means. Blanket TLS inspection struggles here, because decrypting everything inevitably means collecting data you don’t actually need.

If you can’t explain all of this clearly to legal or HR, it’s probably a good idea to 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

#

1. Dedicated inspection CA (used only for GSA TLS inspection)
2. Strong key protection and access controls
3. Short-lived leaf certificates
4. 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