How should security teams handle web traffic inspection when SaaS apps use certificate pinning?

Why certificate pinning changes the inspection model

Certificate pinning changes the problem from “can we decrypt?” to “where can we still observe safely?” If a SaaS app validates a specific certificate or public key, a traditional SSL inspection proxy can break the session or be bypassed entirely, so security teams need to decide whether the control objective is visibility, prevention, or both. That distinction matters before they tune the network stack.

In practice, pinning often shifts enforcement away from the network boundary and toward the endpoint or browser layer. That can preserve visibility into user sessions without forcing a broad exception for the entire application, but it also means the inspection point must be trusted, consistently managed, and compatible with the app's update cadence.

Where inspection fails and what that means operationally

Pinning reduces the value of middlebox-based decryption because the application is explicitly checking that the server endpoint matches an expected certificate chain or key. When that check fails, teams may see failed logins, broken transactions, or repeated reconnect attempts, which can look like an app outage even though the root cause is the inspection design.

The operational risk is that teams treat inspection as an on-off switch instead of a compatibility decision. A full bypass restores functionality quickly, but it also removes a layer of monitoring for all traffic through that path, so the fallback should be narrow, documented, and tied to the exact app, domain, or workflow that cannot tolerate interception.

For SaaS environments, the harder issue is that the business may depend on browser sessions, API calls, and embedded authentication flows that all behave differently under inspection. A control that works for one vendor login page can fail on a richer SaaS app with pinned traffic, certificate rotation, or transport assumptions that change without notice.

What a safer inspection strategy looks like

The practical answer is to move inspection closer to the place where traffic is already trusted for policy enforcement, usually the browser or managed endpoint. That lets teams inspect content before encryption or after decryption inside the trusted runtime, rather than forcing a man in the middle device to impersonate every certificate path on the wire.

That approach works best when it is paired with policy for exception handling, certificate trust management, and clear ownership of which controls are supposed to see content. If the organisation also needs to understand how certificates, trust bundles, and workload or service identity fit into the larger trust model, TLS Inspection Guide provides the broader inspection context.

When the SaaS app is part of a larger authentication or token flow, browser-layer inspection should be paired with strong SaaS posture controls so that visibility loss in the network layer does not become a blind spot everywhere else. That is especially important when the app is high value, high privilege, or tied to data movement, admin access, or third-party integrations.

Risk and Threat Considerations

Certificate pinning can create a visibility gap if teams assume the old decryption model still applies. The main risk is not just lost telemetry, but control erosion: once inspection starts breaking business sessions, teams may expand bypasses faster than they can scope them, leaving sensitive SaaS traffic outside normal monitoring.

Failure mechanism: A pinned client rejects the inspection proxy's presented certificate or key path, so decrypted proxy inspection fails and administrators either disable pinning, exempt the app, or bypass inspection for broad traffic groups.

Impact: Security tools lose visibility into content, sessions, and suspicious behaviour in the affected flow, while users may experience failed access or unstable SaaS workflows until a compatible inspection point is used.

Practitioner Guidance

What to prioritise: Classify each pinned SaaS flow by business criticality and sensitivity before deciding on a bypass. The key question is whether the control failure is acceptable for that exact app, not whether “SSL inspection” works in the abstract.

What to verify: Confirm where inspection can still occur without breaking the app, then validate that the chosen control sees the traffic you actually need to monitor, including authentication redirects, API calls, and post-login session activity.

Decision rule: If the SaaS app cannot tolerate interception, do not force a universal network workaround. Use the narrowest exception possible and move detection to the browser, endpoint, or another trusted control plane that can still observe the user session.

Practitioner takeaway: The goal is not to preserve network decryption at all costs, but to keep visibility and control at the first point in the stack where inspection is technically and operationally trustworthy.

Related resources from NHI Mgmt Group

• Web Traffic Inspection
• Traffic Inspection
• Why does certificate pinning create more risk for web security controls in SaaS environments?
• How should security teams handle SaaS offboarding when users also use AI tools?