Why your Mac fleet has SSL inspection turned off (and how to turn it back on)

Ask a Mac-heavy IT team whether SSL inspection is on and you'll often get a pause, then: "It's on for Windows."

That pause is an admission. The secure web gateway that's supposed to inspect encrypted traffic is inspecting none of it on the devices your engineers, designers, and executives actually use. The policy says protected. The fleet says otherwise.

It isn't laziness. It's a predictable outcome of running a Windows-first product on a Mac-first company. Here's how it happens, and how to fix it.

How a Mac fleet ends up with inspection off

It usually goes in three steps.

Step one, the rollout. The SWG agent lands on Macs through Jamf. SSL inspection is enabled, as it should be. Within a day, developer tooling starts failing. Package managers, CLI tools, container runtimes, anything that pins its own certificate refuses the proxy's cert and errors out. The tickets pile up.

Step two, the triage. Engineers can't ship, so IT does the practical thing. They carve out bypasses one domain at a time, then one subdomain at a time, then a wildcard, then they give up and turn inspection off for the Mac group "temporarily."

Step three, the forgetting. Temporarily becomes permanent. Nobody revisits it because nothing's visibly broken. Encrypted traffic, which is most traffic, passes through uninspected. Your DLP never sees an upload. Your category filters only see the hostname.

Multiply that by every feature that ships Windows-first and reaches macOS a release or two later, and you have a fleet that's enrolled in the SWG but not actually governed by it.

The architecture makes it worse

With a cloud proxy, inspection happens in a data center. Your Mac's traffic has to be redirected there, decrypted, inspected, re-encrypted, and sent on. That redirection is the part that fights with macOS: tunnels, PAC files, network extensions competing with the VPN, and a login gate that can block internet access until the user authenticates.

So even before the cert-pinning problem, Mac users on a backhauling SWG get the captive-portal failures on hotel Wi-Fi, the slow browsing on airline Wi-Fi, and the "can't sign in at all" edge cases. Users learn to disable things. Admins learn to let them. (The architecture side of this is covered in endpoint-based SWG vs cloud proxy SWG.)

Here's how the two models land on a Mac fleet, side by side.

What a Mac-native secure web gateway does differently

dope.security runs inspection on the device. There's no data center to redirect traffic to, so there's nothing to tunnel, no PAC file to maintain, and no login gate standing between the user and the internet. The agent is native on Apple Silicon and Intel, uses under 100 MB of RAM, and runs up to 4x faster than a legacy proxy because the detour is gone.

That changes the SSL inspection conversation in four specific ways.

Inspection on by default, with a real bypass model. You turn SSL inspection on for the whole fleet and add the tools that pin certificates to an Application Bypass in the policy. Not a wildcard that swallows half the internet. A named application. Everything else stays inspected.

SSL error notifications. When a pinned-cert app does fail, the console surfaces it as an SSL error with the process and destination, so the admin creates the bypass in a few clicks instead of reproducing the issue from a user's screenshot. This is the single feature a Fortune 100 customer credited for keeping their 18,000-device rollout moving.

Deployment through what you already run. The agent is a Jamf profile plus a package. Push it, confirm policies, done. Kandji and Intune work the same way. Outreach Health secured 99% of their devices within a week using their existing MDM. No six-page deployment manual.

Policy that follows the user. Policy pushes to every endpoint in under a minute, on the office network or off it. A Mac on hotel Wi-Fi in another country gets the same inspection, the same categories, the same DLP as a Mac in the office. The City of Visalia moved to dope.security for exactly this reason: protections that no longer depend on whether a device is inside the firewall.

The pilot that settles it

If you want to know whether this holds up on your fleet, don't run the pilot on IT's machines. (The full three-week version is in our secure web gateway pilot checklist.) Run it on the Macs that fought the current agent hardest: the developers with the most bypasses, the executive who travels, the one person who could never sign in.

Push the agent through Jamf to that group. Turn SSL inspection on. Add the developer tools to the Application Bypass on day one. Then watch two things for two weeks: the SSL error notifications in the console (expect a handful early, then silence) and the user feedback (expect "faster than before," because it is).

Teams tell us the consensus arrives fast. The pilot users notice the speed. IT notices the absence of tickets. Security notices that inspection is finally on.

Stop accepting the gap

An SWG with inspection disabled on half the fleet isn't a security control. It's a line item. If your Mac users are running uninspected because the product couldn't handle macOS without breaking the people who build your product, that's not a configuration problem you'll eventually get to. It's an architecture problem, and it's fixable in a week. If a Zscaler renewal is what's forcing the conversation, here's the 90-day switch plan.

Sign in with your corporate account at dope.security and push the agent to five Macs this afternoon. Or book a 20-minute demo and bring your bypass list.