Security teams should avoid assuming SSL inspection will always work. Certificate pinning blocks man in the middle decryption, so traditional network tools lose visibility and may force a full bypass to keep business apps functioning. A stronger approach is to inspect traffic at the browser layer, before encryption and after decryption, so protection remains real time without breaking user access.
Why certificate pinning changes the inspection problem
certificate pinning changes the question from “can we decrypt this session?” to “where can we observe the session without breaking it?” In pinned SaaS applications, the client expects a specific certificate or trust chain, so standard TLS interception often fails or triggers application errors. That is why teams that rely only on gateway decryption can end up with either blind spots or brittle exceptions that weaken policy enforcement. For an overview of the wider trust and identity issues that can emerge around protected application access, the OWASP Non-Human Identity Top 10 is useful when machine-mediated access and credential handling are part of the same control problem. In practice, many security teams discover the pinning constraint only after a business-critical app fails during inspection rollout, rather than during architecture review.
How inspection works when decryption is no longer the control point
When pinning blocks middlebox decryption, security teams need to shift from network-only control to endpoint- or browser-proximate control. The practical objective is not to force every SaaS session through a proxy that can decrypt it, but to regain visibility and policy enforcement at a layer that still has access to the cleartext before it leaves the trusted execution context. That usually means browser-based security inspection, endpoint protection that can observe application behavior, or SaaS-native logging and posture controls that reduce dependence on packet inspection alone.
The key implementation distinction is between transport visibility and content visibility. TLS inspection can still be valuable for unmanaged traffic, legacy applications, and sites that do not pin certificates. But for pinned SaaS apps, teams should classify the app, decide whether inspection is technically feasible, and then document the exception path rather than quietly allowing repeated bypasses. If the SaaS app supports separate admin, audit, or API telemetry, those sources should be used to preserve detection coverage where network decryption is impossible.
- Identify which SaaS apps pin certificates and map them to business-critical workflows.
- Separate “cannot inspect” from “should not inspect” so exceptions stay visible and reviewable.
- Move inspection closer to the browser or endpoint when packet-level decryption breaks the app.
- Supplement network controls with SaaS audit logs, identity signals, and endpoint detections.
This approach breaks down when the browser is unmanaged, the endpoint is untrusted, or the application only exposes meaningful telemetry inside the encrypted session.
When to keep inspection, when to exempt, and what pinning usually hides
Tighter inspection often improves visibility but increases operational friction, requiring organisations to balance detection depth against application compatibility. The common mistake is treating every pinned app as a reason to disable inspection entirely, when the better answer may be selective exemption with compensating controls. Guidance on that balance is still implementation-specific rather than fully standardised, so teams should be explicit about where they are following consensus practice and where they are making a local risk decision.
Pinning is most likely to create problems for applications that embed their own trust logic, ship frequently, or rely on mobile or desktop clients outside the browser. In those cases, a proxy exception may be unavoidable, but it should be narrow and time-bound. For web SaaS accessed through managed browsers, browser-layer inspection is usually the cleaner option because it preserves policy enforcement without relying on a TLS man in the middle model that the application is designed to reject. Teams should also expect pinning to hide more than content: it can reduce the usefulness of inline DLP, malware scanning, and some data-exfiltration detections unless compensating telemetry is in place.
Practitioner Guidance: Focus first on whether the app is browser-managed, endpoint-managed, or effectively unmanaged, because that determines whether inspection is possible at all. Treat a bypass as an exception that needs ownership and review, not as a default technical answer. What good looks like here is a documented inspection strategy per SaaS app class, with clear compensating telemetry for anything that cannot be decrypted safely. Practitioner takeaway: if pinning removes decryption as an option, the control strategy has to move up the stack or the organisation will end up choosing between blind spots and broken applications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS — Data Security | Pinning affects where data can be inspected and protected in transit. |
| Recommendation — Use PR.DS to preserve data protection coverage when TLS decryption is not feasible. | ||
| CIS Controls v8 | 8 — Audit Log Management | Pinned SaaS often requires compensating telemetry from logs instead of packet inspection. |
| 12 — Network Infrastructure Management | Inspection exceptions are a network control decision that must remain documented and limited. | |
| Recommendation — Centralise SaaS and endpoint logs to retain detection when traffic cannot be decrypted. Document and constrain inspection bypasses so network exceptions do not become permanent blind spots. | ||
| MITRE ATT&CK | T1040 — Network Sniffing | TLS inspection is a form of network visibility that pinning can deliberately obstruct. |
| Recommendation — Hunt for alternative telemetry when network sniffing or inline inspection is blocked by pinning. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Secrets Leakage and Exfiltration | SaaS sessions may still expose credentials or tokens even when traffic cannot be decrypted. |
| Recommendation — Reduce secret exposure by shifting detection to browser and endpoint layers for pinned sessions. | ||
Related resources from NHI Mgmt Group
- How should security teams handle SaaS offboarding when users also use AI tools?
- How should security teams handle local accounts in cloud and SaaS apps?
- How should security teams handle SaaS apps that do not expose usable APIs?
- How should security teams handle permission creep for AI agents across SaaS apps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
