First separate the resource families
Microsoft Graph places related-looking device data behind different resource and permission families. The distinction is security-relevant: an application that reads Entra device registration properties does not automatically need access to every Intune managed-device property, policy, application, or Autopilot service setting.
| Administrative task | Typical resource family | Permission family to investigate |
|---|---|---|
| Read Entra directory device objects | /devices | Device.Read.All or the narrower method-supported alternative |
| Read Intune managed-device inventory | /deviceManagement/managedDevices | DeviceManagementManagedDevices.Read.All |
| Read Autopilot registration or import state | Autopilot objects under /deviceManagement | DeviceManagementServiceConfig.Read.All where the method documents it |
| Read compliance and configuration policies | Intune configuration resources | DeviceManagementConfiguration.Read.All |
| Read managed applications and assignments | Intune application resources | DeviceManagementApps.Read.All |
| Read Intune scripts | Device-management script resources | DeviceManagementScripts.Read.All |
This table is a routing aid, not a grant list. The authoritative permissions for a call are on that API method’s current Microsoft Learn page. Different operations against the same general workload can require different permissions.
Choose delegated or application access
Delegated access means the app calls Graph on behalf of a signed-in user. Application access means the app uses its own identity without a signed-in user. These are different security designs, not interchangeable token formats.
- Use delegated access when the feature is intentionally performed by an interactive administrator and the method supports it.
- Use application access for unattended work only when that operating model is required and supported.
- Confirm both the Graph permission and any user or Intune role requirement documented for the operation.
- Expect tenant administrator consent for sensitive organization-wide device permissions.
- Do not request both delegated and application variants “just in case.” Document the path the product actually uses.
A valid token can still be wrong for the request. Inspect its audience, tenant, delegated scopes (scp), or application roles (roles) without sharing the raw bearer token. A token is a credential and should not be pasted into a ticket, chat, or public decoder.
Read and write are not a matched pair by default
Microsoft often provides Read and ReadWrite variants, but the write permission can expose far more than the single field your workflow changes. For example, the managed-device ReadWrite permission covers managed-device properties and explicitly has limits around certain high-impact operations. Those limits do not make it a low-risk permission; they define the boundary Microsoft documents.
If a workflow only inventories devices, keep it read-only. If one step writes while all other steps read, consider separating components, identities, or feature gates so a reporting process does not inherit a write-capable token. Review permission use over time and remove grants that no longer support an active feature.
Autopilot permissions illustrate the endpoint rule
Autopilot objects live under the Intune device-management area, but the permission is not inferred from the word “device.” Microsoft’s v1.0 method for listing imported Windows Autopilot device identities documents DeviceManagementServiceConfig.Read.All as the least privileged supported read permission. A write or beta operation can document a different combination.
Also verify API version. Microsoft recommends v1.0 when available; beta APIs can change more frequently. A permission that works against a beta method does not turn the beta contract into a stable production dependency.
A repeatable review worksheet
- Write the user-visible feature in one sentence.
- List every HTTP method and full Graph resource path it calls.
- Mark each call read, create, update, delete, action, or report.
- Choose delegated or application access and explain why a signed-in user is or is not present.
- Open the current method page and record its least-privileged supported permission.
- Record additional licensing, Intune RBAC, directory role, ownership, or scope prerequisites.
- Test with only the proposed permission in a nonproduction tenant or limited scope.
- Document the exact administrator consent text and a removal procedure.
- Log denied calls by status code, request ID, client request ID, and UTC timestamp—not by token.
Diagnose a 403 without widening first
A 403 does not automatically mean “add a broader permission.” Check the token type and tenant, whether consent reached the service principal, whether the token predates the grant, whether the method supports that permission type, whether the signed-in user has the required administrative role, and whether Intune licensing or service configuration is required. Capture Graph’s request and correlation identifiers before retrying.
Only widen a grant when the current method documentation and reproduced evidence show that the narrower permission cannot authorize the intended operation.
