Quick answer: Certificate pinning is an app hard-coding which certificate it will accept, so any security control that decrypts its traffic gets rejected. It does not defeat SSL inspection in general, it defeats proxy SSL inspection in particular, because a cloud proxy sitting in a data center can only ever identify the traffic it broke by destination, which is why every legacy SWG ends up with a long global bypass list. dope.security inspects on the device, so the agent knows which process threw the error, reports the exact app and URL to the admin, and scopes the bypass to that app instead of switching off inspection for a domain everyone else uses too.

If you have ever been handed a spreadsheet of bypassed domains by your SWG vendor and told it is normal, this post is about why that spreadsheet exists and how short it can actually be.

For the architectural version of the same argument across two named vendors, see our breakdown of how Zscaler and Netskope compare on inspection and performance. For the mechanics of break and inspect itself, start with SSL inspection explained: on-device versus the cloud proxy model.

What is certificate pinning?

Certificate pinning is a defense an application ships with. Instead of trusting any certificate that chains up to a certificate authority the operating system trusts, the app hard-codes the exact certificate, public key, or issuing CA it expects from its own server. When the app opens a TLS connection and gets back anything other than that pinned value, it refuses the connection outright. No warning page, no click-through, no fallback.

The point of pinning is to stop a man in the middle. If an attacker gets a fraudulent certificate issued for your banking app, pinning means the app still says no. Developers of banking apps, payment SDKs, messaging clients, and a lot of enterprise SaaS desktop clients pin deliberately, and they are right to.

You will see the same idea called SSL pinning, TLS pinning, public key pinning, or cert pinning. They all describe the same behavior: the client decides in advance what it will accept, and the operating system trust store no longer gets a vote.

Why pinning breaks SSL inspection

SSL inspection works by becoming a deliberate man in the middle that you control. The security control terminates the TLS session from the client, presents its own certificate signed by a root you pushed to the device through MDM, opens a second session to the real destination, and inspects the plaintext in between. That is how a secure web gateway can categorize a URL, classify a file upload for DLP, scan a download for malware, or tell a corporate SaaS tenant apart from a personal one.

A pinned app breaks that chain on purpose. It never consulted the trust store, so the root certificate you distributed is irrelevant. It expected one specific certificate, got yours, and closed the connection. The app is not misbehaving. It is doing precisely what it was built to do.

This is the part worth internalizing: pinning is not a bug in your SWG and it is not a bug in the app. It is two correct security controls disagreeing, and somebody has to make a policy decision about which one wins for that app.

The bypass list is where the real cost lands

Every SSL inspection product on the market answers pinning the same way. It bypasses. The traffic from the pinned app gets excluded from decryption and passes through untouched. That fixes the broken app in about thirty seconds.

It also creates a hole. Whatever you bypassed is now traffic your DLP cannot read, your malware scanner cannot open, and your Cloud Application Control cannot evaluate. If the bypass is written broadly, and most of them are, you did not exclude one stubborn app. You excluded a whole domain, and every other app and browser tab that talks to that domain came along for the ride.

So the honest question when you are evaluating SSL inspection is not "does it handle pinned apps." They all do. The question is how precisely it can carve out the thing that broke, and how quickly you find out something broke at all.

What a cloud proxy can actually see when an app breaks

Here is the constraint that decides everything downstream. A cloud proxy sits on the network, so its view of a failed handshake is a network view: a source IP, a destination IP, an SNI hostname if one was sent, and a TLS alert. It does not know that the process behind that socket was Docker, or the ChatGPT desktop client, or a payroll thick client, because process identity does not travel over the wire.

That is not a product gap anyone can patch. It is where the software runs. And it has one direct consequence: a proxy can only express a bypass in the vocabulary it can see, which is destinations. Domain, hostname, IP range, URL category. Never "this application, and only this application."

An agent running on the endpoint sees the other half. It knows which binary opened the socket before a single packet leaves the machine, so it can describe the failure as an app and a destination together, and it can act on either one.

How the legacy vendors handle it

Every vendor here scores well overall, and none of them are hiding this. It shows up in their own documentation, which is exactly why it is worth reading.

• Zscaler. Zscaler forwards traffic to a ZEN service edge node for inspection. Its own guidance documents that cert-pinned applications including Microsoft 365, WebEx, and Dropbox cannot be inspected, and developer tooling such as Docker, Python, and Git commonly breaks under inspection and needs exclusion. dope.security keeps inspection on the device and reports the exact application and URL that failed, so the exclusion you write matches the app rather than a whole SaaS domain.
• Netskope. Netskope's NewEdge proxy has the same structural issue and the same answer, with customers maintaining bypass lists for cert-pinned applications. Netskope also documents a real decryption cost: its own SLA is under 10 ms for non-decrypted traffic and 50 ms once traffic is decrypted. dope.security decrypts in-process on the endpoint, so the inspection decision does not come with a round trip.
• Cisco Umbrella. Umbrella's base tier is DNS-layer, so it never sees a certificate at all and cannot make a pinning decision either way. Full HTTPS inspection requires the SIG secure web gateway add-on plus a root certificate installed on every endpoint, and Cisco documents TLS 1.3 and roaming client issues on top of that. dope.security ships inspection, URL filtering, and Cloud Application Control in one agent with no add-on tier to buy first. Our write-up of what Cisco Umbrella SIG can and cannot inspect goes deeper.
• Cloudflare Gateway. Cloudflare documents that its TLS decryption breaks common developer tools including git, aws, kubectl, terraform, and Docker, along with the ChatGPT desktop client. dope.security surfaces each of those as a named application in the console, so an admin fixes the one that is actually breaking instead of bypassing a shared endpoint.
• Menlo Security. Menlo's control point is the isolated browser, so anything that is not a browser session, including desktop AI clients, IDE integrations, and CLI tools, sits outside its enforcement entirely. dope.security inspects at the device egress point, which means non-browser applications are in scope by default rather than by exception.

Where inspection happens changes what a bypass costs

There is a second bill attached to the proxy model, and pinning makes it visible. A cloud proxy inspects in a data center, which means every request takes a detour to a point of presence and back before it reaches its destination. Measured cloud-proxy latency runs roughly 40 to 80 ms when a user is near a point of presence and 150 to 400 ms when they are not. A modern web app chains dozens of requests, so that tax compounds.

When you then bypass a pinned app, you have paid the detour on everything else and still lost visibility on the app you care about. On-device inspection inverts both halves. There is no detour to pay, and the bypass you write is narrower.

See what the detour actually costs on your own connection. Our interactive Fly-Direct Speed Test measures your real round-trip latency in the browser and shows app-by-app load times against a legacy cloud-proxy path. Start with how Fly Direct SWG works, or book a 20-minute demo and we will run it with you.

‍

Takeaway: the pinning bypass and the latency tax come from the same decision, which is putting the inspection point somewhere other than the device.

‍

How dope.security handles a pinned app that breaks

dope.endpoint is a native agent for Mac and Windows that performs SSL inspection locally, and the root certificate deploys with the agent through the MDM channel you already use. When a pinned app rejects the handshake, the agent does not just fail quietly.

The endpoint reports the combination of the application and the URL that hit the error up to dope.console, where it appears as a notification. Admins do not have to reverse-engineer which of forty domains broke. The notification view splits the errors two ways:

• By App. A list of the applications that reported SSL errors, with the URLs each one touched, and a hover to see which users hit the issue. Select the application and add it to the bypass list.
• By URL. Every URL that reported an error, grouped by top-level domain, so you can bypass a single URL or the parent domain if that is genuinely what you need.

Two details matter operationally. An allow rule is not a bypass: allowed traffic is still inspected, so if certificate errors persist after you write an allow rule, you need an actual bypass entry. And if nobody acts on an SSL error notification, it ages out of the view after 14 days rather than accumulating forever.

This is a small feature with an outsized effect on rollouts. When a Fortune 100 customer scaled from 900 devices to more than 18,000 in a matter of weeks, averaging around 3,000 devices per week, SSL error notifications were one of the four things they credited, because broken traffic from certificate pinning surfaced on its own and admins cleared it in a few clicks instead of filing tickets. The full story is in how a Fortune 100 deployed dope.security on 18,000 devices, and the feature itself is walked through in managing proxy SSL inspection breaking applications.

A practical pinning playbook

Whatever gateway you run, the discipline is the same.

• Bypass by application before you bypass by domain. One thick client refusing your certificate is not a reason to stop inspecting a domain that browsers also use.
• Write the bypass, then log it. A bypass is a documented exception to your inspection policy, not a config detail. It should be reviewable.
• Bypass sensitive categories on purpose, not by accident. Banking, healthcare portals, and your own internal PKI belong on the list for policy reasons. Add them deliberately.
• Re-check the list quarterly. Apps change their pinning behavior between releases. Bypasses added in a panic in 2024 are still costing you visibility in 2026.
• Ask vendors how you learn something broke. If the answer is "a user opens a ticket," you are the detection mechanism. That does not scale past a few thousand endpoints.

The part most buyers get backwards

Certificate pinning is usually filed as a technical footnote in an SSL inspection evaluation. It is not. It is the single clearest test of where a product's inspection point sits, because the quality of the answer depends entirely on whether the software can see the process that failed.

Pinning will keep spreading. More apps ship with it, more developer tooling assumes an unmodified TLS path, and more AI tools now run as desktop clients rather than browser tabs. Every one of those is a future line in somebody's bypass list. The architecture you pick decides whether that line names one application or an entire domain.

Try dope.SWG free and watch what your own fleet reports in the first week, or book a 20-minute demo.

Frequently Asked Questions

Does certificate pinning stop SSL inspection completely?

It stops SSL inspection for that specific application, not for the rest of your traffic. The pinned app rejects the inspection certificate and the connection fails, so the app must be excluded from decryption to work. Everything else on the device is still inspected normally. The practical difference between products is how narrowly the exclusion can be written, which is why dope.security scopes bypasses by application as well as by URL.

What is the difference between certificate pinning and SSL pinning?

There is no functional difference. Certificate pinning, SSL pinning, TLS pinning, and public key pinning all describe an application hard-coding which certificate or key it will accept from its server instead of trusting the operating system's certificate store. The terms are used interchangeably in vendor documentation, and they all break inspection the same way.

Which applications most commonly break under SSL inspection?

Developer tooling and thick clients are the usual suspects. Vendor documentation names git, aws, kubectl, terraform, Docker, Python, and the ChatGPT desktop client, along with Microsoft 365, WebEx, and Dropbox clients depending on version. Banking and payment applications pin almost universally. The list changes with every app release, which is why an automatic report of what broke matters more than a static exclusion list.

Do I still need a root certificate on every device if apps are pinned?

Yes. Pinned apps ignore the root certificate, but every browser and non-pinned application still needs to trust it or users get certificate errors on ordinary web traffic. dope.security distributes the root certificate with dope.endpoint through your existing MDM, so it lands as part of the agent install rather than as a separate project.

If I bypass a pinned app, do I lose all control over it?

You lose payload visibility for that app, which means DLP and malware scanning cannot read inside those sessions. You do not automatically lose everything else: an on-device agent still sees that the application is running and where it is connecting, which keeps it visible for shadow IT discovery and application-level policy even when the contents are not decrypted. That is the practical argument for keeping the bypass scoped to the application rather than opening a whole domain.

Is on-device SSL inspection immune to certificate pinning?

No, and any vendor claiming otherwise is overselling. A pinned app rejects an unexpected certificate regardless of where the inspection runs. The advantage of running on the device is not immunity, it is diagnosis and precision: the agent knows which process failed, tells you without waiting for a helpdesk ticket, and lets you exclude that process instead of the destination it shares with everything else.