Deploying a Cloud SWG via Intune and Jamf: A Practical MDM Playbook for Mid-Market IT

The thing nobody tells you about a secure web gateway rollout is that it lives or dies on the MDM rollout, not the security policy. The console looks pretty in the demo. The agent installs are what determine whether you ship in a week or a quarter. This is the playbook we wish IT teams had the first time they did this.

Why MDM rollout is the part that breaks

Legacy SSE deployments live in a data center somewhere. You point traffic at a PAC file, you write a few proxy rules, and then you spend three months chasing exceptions and end-user complaints. The agent-based model is different. The proxy moves to the device. Which means MDM is the deployment plane.

If your Intune and Jamf workflows are healthy, an agent-based SWG deploys in days. If they're not, you'll fix MDM before you fix security, and that's actually fine. You'd have had to fix MDM eventually anyway.

A Fortune 100 customer deployed dope.security on 18,000+ devices in record time using existing MDM tooling. A separate Cisco Umbrella customer migrated to 2,000 machines in two days. Greylock Partners went from first proposal to signed contract in 27 days, with the actual agent rollout taking a fraction of that. These weren't lucky deployments. They were boring MDM rollouts.

Before you touch MDM, get the prerequisites right

Three checks save you weeks of pain later.

Inventory your devices accurately. You need to know how many laptops you have, what operating systems, who owns them, and whether they're all enrolled. If your Intune compliance dashboard says 1,200 devices and your HR system says 1,400 people, you have 200 unmanaged machines that will turn into Slack messages once policy goes live.

Confirm your IdP integration works. Single sign-on into the dope.console should be set up before agent rollout, not after. OIDC against Okta, Azure AD, Google, or whichever IdP you use. Test with a service account first.

Decide your TLS inspection posture. On-device TLS inspection needs a root certificate trusted on each device. With MDM, you push it as a trusted profile. Without MDM, your users will see certificate prompts and call IT. Get the cert pushed before you push the agent.

The Intune playbook for Windows

Intune handles two things for the rollout: pushing the agent installer and pushing the trust profile.

Step 1: Package the installer. Wrap the dope.endpoint MSI in a Win32 app package with Microsoft Win32 Content Prep Tool. Set the install command, the uninstall command, and a detection rule based on the agent service or registry key.

Step 2: Create the device group scope. Don't start company-wide. Create an Intune dynamic device group for your pilot ring (say, 25 IT engineers and security team members). Assign the app to that group. Verify install completes. Verify the device shows up in the dope.console.

Step 3: Push the trust profile. Add the SSL inspection root certificate as a Trusted Root Certificate Authority profile. Scope to the same pilot group. Confirm Edge and Chrome stop showing certificate errors. Confirm Firefox if you use it (Firefox uses its own cert store, so this gets a separate configuration).

Step 4: Expand by ring. Pilot ring (25 devices) for 48 hours. Early adopter ring (10% of fleet) for a week. General availability ring (100%) after that. Watch the helpdesk queue at each phase. If tickets spike, slow down.

Step 5: Cover edge cases. Contractor laptops not on Intune. Personal devices on BYOD. Conference room machines. Mobile devices, depending on policy. Each gets a path or an exception.

The Jamf playbook for Mac

Jamf Pro is the most common MDM for Mac in the mid-market. The rollout has the same shape with platform-specific steps.

Step 1: Package the agent. Upload the dope.endpoint PKG to Jamf as a package. Use Jamf Composer if you need to bundle additional config. Set up a policy that installs the package and triggers on enrollment plus on a schedule for catch-ups.

Step 2: Push the configuration profile. Configuration Profile in Jamf with two payloads: the certificate trust payload and the system extension allowlist. The system extension piece matters: on modern macOS, the network filter needs to be explicitly approved or users see a prompt. Pre-approving via MDM removes the friction.

Step 3: PPPC (Privacy Preferences Policy Control). Grant the agent the macOS permissions it needs (Full Disk Access, Network filter). Without PPPC, every user gets a popup on first launch. With PPPC, they get nothing.

Step 4: Smart Group your pilot. Create a Smart Group of pilot devices. Scope the policy and profile to that group. Test the rollout. Confirm the dope.console sees the devices. Confirm browsing works.

Step 5: Roll forward. Expand the Smart Group through pilot, early adopter, and general availability rings. Same approach as Intune.

Linux and Mobile (the asterisks)

A few realities worth flagging.

Mobile devices typically use a different model. Most SWG vendors handle mobile through a per-app VPN or through MDM-managed browser profiles. If mobile is in scope, plan that separately, not as part of the laptop rollout.

Linux endpoints are a smaller share of mid-market fleets but they exist (engineering, DevOps). Confirm coverage with your SWG vendor and treat them like a separate ring.

Validate before you scale

The single most common rollout mistake is going to general availability without a validation checklist. Five things to verify in the pilot ring:

1. Agent installs cleanly on every device in the group. No leftover installer prompts. No reboot prompts where you didn't expect them.
2. dope.console sees every pilot device, with current OS and version, in under five minutes of install.
3. Policy push from console to device takes seconds, not minutes. Edit a URL category, save, watch the device behavior change. This is one of the dope.security speed promises and it's where legacy proxy SWGs visibly lag.
4. TLS inspection works on the top 20 sites your users actually visit. No cert errors. No broken apps. If something breaks (banking apps are common offenders), add a bypass in policy.
5. Helpdesk tickets stay quiet. If they don't, fix the cause before you scale.

A real benchmark from a customer rollout: Outreach Health secured 99% of devices within one week and saw a 70% reduction in web access-related IT tickets in 90 days. That's the curve to expect when the agent is right and the MDM lift is light.

Common failure modes (and how to avoid them)

Certificate prompts. Almost always a trust profile that didn't push, or a Firefox/Chromium-with-custom-trust-store situation. Confirm the cert is in the Trusted Root store on the device before debugging the agent itself.

System extension blocked on Mac. Missing PPPC or missing system extension allowlist payload in Jamf. Push both, re-enroll the device if needed.

Agent stops phoning home. Almost never a network issue. Usually a competing product (legacy SWG client, VPN, another endpoint security tool) still running and intercepting traffic. Decommission the old client cleanly. Running alongside GlobalProtect, FortiClient, or AnyConnect is fine; running alongside another agent-based SWG is not.

Helpdesk overload at the GA ring. You went too fast. Pull back to the early adopter ring, fix the top 3 ticket causes, then resume.

What this looks like end to end

A clean rollout for a 1,000-device mid-market shop on Intune and Jamf usually runs like this:

• Day 1: Prerequisites, IdP integration, certificate ready.
• Day 2: Pilot ring (25 devices). Validate.
• Day 3 to Day 5: Early adopter ring (10%). Watch tickets.
• Day 6 to Day 10: General availability ring (remaining 90%). Tune policy as you go.
• Week 3: Add DLP, CASB Neural scans, Cloud Application Control for personal account blocking. Policies you add, not migrations.

Two weeks, one engineer, one MDM. That's the speed an agent-based SWG enables when the rollout plane is healthy.

Want to actually try this?

You can stand up dope.security in your console in minutes, push the agent to a pilot ring via Intune or Jamf, and have policy enforcing within the hour. No appliances. No data center config. No quarter-long PoC. Start a free trial or book a 20-minute demo and bring your MDM admin.