Granting an outside vendor write access to your Microsoft Intune or Jamf Pro tenant is a serious decision — and most security reviewers want to see the exact list of permissions before they sign off. This page is that list, with a justification for each item and an explicit “required” vs. “optional” marker so you can run Snap2Deploy with the smallest permission set that satisfies your use case.
For a higher-level view, start with the Security & Trust Center.
Least-privilege mode (no API access)
You can use Snap2Deploy without granting any API access to your MDM tenants. In this mode:
- You upload installers to Snap2Deploy.
- We package them into
.intunewin(Win32 apps for Intune), a raw encrypted.pkg/.dmg(macOS apps for Intune), or a Jamf-ready.pkg(macOS apps for Jamf), and generate the install/uninstall commands plus detection metadata. - You download the finished package from Snap2Deploy and upload it to Intune or Jamf yourself, using your existing tooling.
This is the lowest-trust way to evaluate Snap2Deploy and the configuration most security teams approve fastest. If you only need this mode, skip the rest of this page — we won’t ask for anything from your tenant.
Microsoft Intune (via Microsoft Graph)
Snap2Deploy authenticates to Microsoft Graph using an Entra ID app registration that you create and own in your own tenant. We never see, store, or have access to your administrator credentials — only the client secret of the app registration you grant us. You can revoke our access at any time by deleting the app registration or its secret.
Authentication uses the client credentials flow with Application-type permissions (not Delegated). We do not impersonate any user.
| Graph permission | Why we need it | Status |
|---|---|---|
DeviceManagementApps.ReadWrite.All | Upload .intunewin packages (Win32LobApp for Windows endpoints) or encrypted .pkg /.dmg bytes (macOSPkgApp / macOSDmgApp for Mac endpoints), set the install/uninstall commands and detection metadata, and assign the resulting app to your target groups. The same scope covers both Windows and macOS deployment via Intune. | Required |
DeviceManagementServiceConfig.Read.All | Read your Intune tenant configuration (e.g. tenant URL, regional cloud settings) so we connect to the right endpoint and can verify the tenant during onboarding. | Required |
DeviceManagementManagedDevices.Read.All | Read managed-device counts and Auto-Pilot reporting so we can show you how many devices have a given app version and surface stale installs. Read-only. | Optional |
Group.Read.All | Read Entra ID groups so the deployment dialog can show you a list of assignment targets by name. Read-only; we do not modify group membership. | Optional |
What we do not ask for: we do not request User.Read.All, Directory.Read.All, mail scopes, calendar scopes, file scopes, or any permission outside the Intune service surface.
Jamf Pro
Snap2Deploy authenticates to Jamf Pro using a Jamf Pro API client that you create in your own Jamf instance, with a dedicated API role that you define. We use the OAuth2 client-credentials flow against /api/v1/auth/token — no human credentials. You can rotate or revoke our access at any time from the Jamf Pro admin console.
Each row below corresponds to one privilege in Jamf Pro’s API role privilege list. Names match exactly — copy-paste them into Jamf’s search box.
| Jamf Pro privilege | Why we need it | Status |
|---|---|---|
| Read Computers | Verify the connection during onboarding and read computer counts for reporting. Read-only. | Required |
| Create Packages | Upload generated .pkg files via the Jamf Cloud Distribution Service and register them in Jamf. | Required |
| Read Packages | Look up existing packages so we can show you what’s already in Jamf and avoid creating duplicates. | Required |
| Update Packages | Attach the uploaded .pkg / .dmg bytes to the package record. Snap2Deploy uses Jamf’s Classic file-upload endpoint for portability across Jamf Pro versions, and that endpoint is gated by this privilege. | Required |
| Delete Packages | Clean up orphaned package records when a deploy fails partway through, so your Jamf instance doesn’t accumulate broken artifacts. | Required |
| Create Policies | Create the install policy that actually deploys the package to target computers. | Required |
| Read Policies | Read existing policies so we can show you what Snap2Deploy has deployed. | Required |
| Read Smart Computer Groups | Show you smart groups (dynamic membership) as deployment targets in the assignment dialog. Read-only. | Required |
| Read Static Computer Groups | Show you static groups (fixed membership) as deployment targets in the assignment dialog. Read-only. | Required |
| Read Computer Inventory Collection | Read installed-app inventory so Auto-Pilot can detect outdated versions of monitored apps and offer to patch them. Read-only. | Optional |
| Create Scripts / Read Scripts | Upload pre-install or post-install scripts attached to a policy when an installer needs more than a vanilla installer -pkg command. | Optional |
What we do not ask for: we do not request Update Computer, Send Computer Remote Command, Wipe Computer, Erase Computer, MDM-command privileges, or any privilege that lets us reach inside a managed device. Snap2Deploy operates on packages and policies, not on endpoints directly.
Revoking access
- Intune: from your Entra ID admin center, delete the client secret on the app registration we use, or delete the app registration entirely. Snap2Deploy will fail closed on the next API call.
- Jamf Pro: from your Jamf Pro admin console, delete the API client we use, or revoke its API role. We will fail closed on the next token refresh.
- Or, from inside Snap2Deploy: any admin or owner can disconnect an MDM integration from Settings → Integrations. We immediately delete our copy of the encrypted credentials.
Auditing what Snap2Deploy did
Every action Snap2Deploy takes via Graph or the Jamf Pro API is attributable to the dedicated app registration / API client you created. That means you can use Microsoft Entra ID sign-in logs and Jamf Pro change logs to see exactly which calls Snap2Deploy made, when, and to what resource — the same way you would audit any other service principal.
Inside Snap2Deploy, every administrator-level action also writes to the per-organization audit log so you have a second, independent record.
Questions
If your security team needs a different combination of permissions than what we list here, or wants to scope our access to a specific sub-tree, email security@snap2deploy.com and we’ll figure it out.