i About this document
SoftwareCentral manages Microsoft Intune and Microsoft Entra ID through the Microsoft Graph API. To do that it needs an app registration in your tenant, with permissions that you grant and can revoke at any time. This page exists so that the person granting them can see exactly what each permission is used for before consenting — rather than approving a list of twenty-odd scopes on trust.
Every entry below states five things:
- Why it is needed — the business function behind the permission.
- Where it is used — the SoftwareCentral screens and background jobs that call it.
- Graph resources called — the actual API surface, so you can verify the claim.
- Without this permission — what fails, and whether it fails loudly or silently.
- Read-only / narrower alternative — the lower-privileged permission Microsoft accepts, and precisely which feature you give up by choosing it.
Nothing here is mandatory in the abstract
Several permissions serve one feature only. If you do not use that feature, do not grant the permission — the feature reports an error and everything else keeps working. Section 2 marks which ones those are.
Scope of this page
This is the permission set for the SoftwareCentral product. The cloud dashboards add a small number of further read-only permissions (Conditional Access, security incidents, Entra Identity Protection and Microsoft Defender for Endpoint); those are documented separately and are not required to run SoftwareCentral.
1 How SoftwareCentral connects
| Where the code runs | On your SoftwareCentral server (IIS). Every Graph call is made server-side from that server. Browsers never call Graph, and no token is issued to a browser. |
|---|---|
| Identity | An app registration in your own tenant, using the OAuth 2.0 client credentials flow — a certificate (recommended) or a client secret. SoftwareCentral is multi-tenant capable: each managed tenant has its own registration and its own consent. |
| Where credentials live | Tenant details in the IntuneTenants table of the SoftwareCentral database, in your environment. The signing certificate is installed in LocalMachine\My on the SoftwareCentral server and referenced by thumbprint — the private key never leaves that machine. |
| Consent | All application permissions below require admin consent. Until consent is granted the app can do nothing at all. |
| Second, optional identity | An on-behalf-of service account (see section 9). It is only needed for BitLocker recovery keys, password reset and, in some setups, mail. Most installations do not need it. |
| Who inside SoftwareCentral may use it | A Graph permission is tenant-wide by nature, but who can trigger it is controlled by SoftwareCentral's own security roles. A help-desk operator only sees the tools, devices and users their role allows. The Graph grant sets the ceiling; the security role sets the actual reach of each operator. See Security Roles. |
Read/write is not the same as "used for writing"
Two permissions in this list are read-write only because Microsoft publishes no read-only equivalent for that API. SoftwareCentral issues
GET against them and nothing else. They are called out where they occur.
2 The permission set at a glance
All permissions are on the Microsoft Graph resource. “Core” means SoftwareCentral cannot do its main job without it; “Feature” means one named feature depends on it; “Optional” means it can be declined with a small, well-defined loss.
| Permission | Access | What it powers | Needed? |
|---|---|---|---|
email · openid · profile · offline_access | Delegated | Entra ID sign-in to the SoftwareCentral portal | Feature |
DeviceManagementManagedDevices.ReadWrite.All | Read & write | The Intune device inventory — the backbone of every device screen | Core |
DeviceManagementManagedDevices.PrivilegedOperations.All | Write | Every remote device action, including the everyday Sync | Core |
DeviceManagementConfiguration.ReadWrite.All | Read & write | Configuration and compliance policies, and their per-device state | Core |
DeviceManagementApps.ReadWrite.All | Read & write | Intune application management and software delivery | Core |
DeviceManagementServiceConfig.ReadWrite.All | Read & write | Windows Autopilot registrations and the Enrollment Status Page | Feature |
Device.ReadWrite.All | Read & write | Adding devices to deployment groups; Entra device clean-up | Core |
WindowsUpdates.ReadWrite.All | Read only in use | Translating a Windows build number into a release and end-of-service date | Optional |
BitlockerKey.Read.All | Read | Showing a BitLocker recovery key to the help desk | Optional |
CloudPC.ReadWrite.All | Read & write | Windows 365 Cloud PCs and their actions | Optional |
DeviceLocalCredential.Read.All | Read | Showing the Windows LAPS local administrator password | Optional |
DeviceManagementRBAC.Read.All | Read | Offering the tenant's Intune scope tags on new applications | Feature |
DeviceManagementScripts.ReadWrite.All | Read & write | Intune platform scripts and proactive remediations | Optional |
Application.ReadWrite.All | Read & write | Letting SoftwareCentral write its own permission list into its own app registration | Optional |
Group.ReadWrite.All | Read & write | Creating and maintaining the Entra groups used as deployment targets | Core |
GroupMember.ReadWrite.All | Read & write | Adding and removing group members — how software actually reaches a device or user | Core |
Directory.Read.All | Read | Verified domains, subscribed SKUs, directory lookups, permission self-check | Core |
RoleManagement.ReadWrite.Directory | Write | Only adding members to role-assignable groups | Optional |
User.ReadWrite.All | Read & write | Entra user administration and help-desk password reset | Feature |
AuditLog.Read.All | Read | Sign-in history and directory audit shown on the user pages | Optional |
UserAuthenticationMethod.ReadWrite.All | Read & write | MFA method reset and Temporary Access Pass | Optional |
Mail.Send | Write | Notification mail sent through Graph instead of SMTP | Optional |
The three most common reductions
In practice, security teams most often decline
Application.ReadWrite.All (apply the manifest in section 12 by hand instead), RoleManagement.ReadWrite.Directory (only needed for role-assignable groups) and Mail.Send (use SMTP instead). None of the three affects device or application management.
3 Sign in (Delegated permissions)
openid · profile · email · offline_access Sign-in only
| Why it is needed | The standard OpenID Connect scopes that let a user sign in to the SoftwareCentral portal with their Entra ID account. They return the identity token only — who signed in, their name and e-mail address. offline_access allows the session to be refreshed without asking the user to sign in again. |
|---|---|
| Where it is used | Entra ID / OpenID Connect authentication to the portal (see OpenID authentication), and the on-behalf-of service-account token described in section 9. |
| Graph resources called | None. These scopes carry no directory read of their own; they only shape the sign-in token. |
| Without this permission | Users cannot sign in to SoftwareCentral with Entra ID. Windows / Active Directory authentication is unaffected. |
| Narrower alternative | None — these are already the minimum OpenID Connect set, and they are the four scopes Microsoft itself classifies as requiring no admin consent. Omit them entirely if you authenticate portal users against Active Directory. |
4 Device Management (Application permissions)
DeviceManagementManagedDevices.ReadWrite.All Read & write
| Why it is needed | This is the Intune managed-device object itself. It is what makes a device visible in SoftwareCentral at all: name, platform, OS build, ownership, compliance and enrollment state, hardware and storage. The background service keeps a local copy in step using Graph delta queries so that pages open instantly and the tenant is not polled repeatedly. |
|---|---|
| Where it is used | Intune Device Management, Device Manager, Manage Software, Delete Computer, the device pickers used throughout the product, the Shop (an order has to resolve to a real device), and the background synchronisation service. |
| Graph resources called | GET /deviceManagement/managedDevices (and /delta, /{id}, /{id}/users, /{id}/detectedApps), DELETE /deviceManagement/managedDevices/{id}, POST/DELETE /deviceManagement/managedDevices/{id}/users/$ref, /deviceManagement/managedDeviceOverview, /deviceManagement/reports/exportJobs. |
| Without this permission | SoftwareCentral has no Intune devices. Every device screen is empty, software cannot be targeted at a machine, and the Shop cannot complete an order. This is the one permission with no workaround. |
| Read-only alternative | DeviceManagementManagedDevices.Read.All. All inventory, reporting and troubleshooting continues to work. You lose two things: deleting the Intune device record (during Delete Computer) and setting or clearing a device's primary user. Note that Microsoft documents both the read and read-write reporting scopes as acceptable for creating a report export job; if an export returns 403, the read-write form is required. |
DeviceManagementManagedDevices.PrivilegedOperations.All Write
| Why it is needed | Microsoft places every remote action on a managed device behind this single scope — not only the destructive ones. The routine Sync that tells a device to check in immediately after software has been assigned to it requires exactly the same permission as Wipe. |
|---|---|
| Where it is used | The Intune action panel on Device Manager and Manage Software: Sync, Restart, Quick scan, Full scan, Update Defender signatures, Rename, Send custom notification, Remote lock, Reset passcode, Lost mode on/off, Fresh start, Autopilot reset, Retire, Wipe, Bypass activation lock and Run remediation script on demand. The Shop and the deployment engine also issue a Sync after an install so the user does not wait for the next scheduled check-in. |
| Graph resources called | POST /deviceManagement/managedDevices/{id}/{action} where {action} is syncDevice, rebootNow, windowsDefenderScan, windowsDefenderUpdateSignatures, setDeviceName, sendCustomNotificationToCompanyPortal, remoteLock, resetPasscode, enableLostMode, disableLostMode, cleanWindowsDevice, wipe, retire, windowsAutopilotReset, bypassActivationLock or initiateOnDemandProactiveRemediation. |
| Without this permission | Every device action fails with 403 and is logged. Software assignments still reach devices, but only at the device's own next check-in rather than immediately. Nothing is silently skipped — the operator sees the failure. |
| Read-only alternative | None. Microsoft publishes no read-only or partial form of this scope, and no way to allow Sync while forbidding Wipe — it is all-or-nothing at the API. The control that does exist is on the SoftwareCentral side: each action is a tool that you assign to security roles, so a first-line operator can be given Sync and Restart while Wipe and Retire are reserved for a named administrator role. If remote actions are not wanted at all, leave the permission ungranted. |
DeviceManagementConfiguration.ReadWrite.All Read & write
| Why it is needed | Configuration profiles, settings-catalog policies and compliance policies, together with the per-device and per-setting state that explains why a device is non-compliant. Without the setting-level detail, “non-compliant” is a dead end for the help desk. |
|---|---|
| Where it is used | Troubleshoot configuration policy and Troubleshoot compliance policy, the policy list on a device, assigning a configuration policy to a device or group from Manage Software, and the policy figures on the Intune dashboard. |
| Graph resources called | /deviceManagement/deviceConfigurations, /deviceManagement/configurationPolicies, /deviceManagement/deviceCompliancePolicies, /deviceManagement/managedDevices/{id}/deviceConfigurationStates and /deviceCompliancePolicyStates/.../settingStates, /deviceManagement/deviceCompliancePolicySettingStateSummaries, plus the assignment collections on those objects. |
| Without this permission | Policy troubleshooting shows nothing, the compliance reason cannot be displayed, and assigning a configuration policy from SoftwareCentral fails. |
| Read-only alternative | DeviceManagementConfiguration.Read.All. All policy reporting and troubleshooting is retained. You lose only the ability to assign a configuration policy to a device or group from inside SoftwareCentral; policies must then be assigned in Intune. |
DeviceManagementApps.ReadWrite.All Read & write
| Why it is needed | The Intune application catalogue. This is SoftwareCentral's principal function: packaging, publishing, versioning, assigning and retiring applications, and reporting on their installation. It is also how a Shop order becomes an actual installation. |
|---|---|
| Where it is used | Intune Applications, Create / Edit Intune Application, Intune Application Templates, Assign application to group, Replace application, Migrate a ConfigMgr application to Intune, the upload of a Win32 .intunewin package, application install status, discovered apps, and the whole Shop and approval flow. |
| Graph resources called | /deviceAppManagement/mobileApps and its children (/assignments, /contentVersions and /contentVersions/{id}/files for the content upload, /relationships, /deviceStatuses, /userStatuses), /deviceAppManagement/vppTokens, /deviceManagement/detectedApps, /deviceManagement/assignmentFilters. |
| Without this permission | No application can be created, uploaded, edited, assigned or retired from SoftwareCentral, and the Shop cannot deliver software. The product is reduced to reporting. |
| Read-only alternative | DeviceManagementApps.Read.All — a genuinely useful reporting-only mode: the application catalogue, assignments, install status and discovered software are all readable. Everything that changes an application or an assignment stops, which includes the Shop. |
DeviceManagementServiceConfig.ReadWrite.All Read & write
| Why it is needed | Windows Autopilot device registrations and the Enrollment Status Page. SoftwareCentral registers new hardware for Autopilot (single device or a CSV import), maintains the group tag that decides which deployment profile a machine receives, and removes the registration when a machine is decommissioned. |
|---|---|
| Where it is used | Autopilot Devices — list, import one device, import multiple from CSV, edit group tag and display name, delete; the prestage and import-computer flows; and the Enrollment Status Page, whose application references are updated when an application is replaced. |
| Graph resources called | /deviceManagement/windowsAutopilotDeviceIdentities, /deviceManagement/importedWindowsAutopilotDeviceIdentities, /deviceManagement/deviceEnrollmentConfigurations. |
| Without this permission | Autopilot devices cannot be registered, retagged or deleted from SoftwareCentral, and replacing an application leaves a stale reference in the Enrollment Status Page profile. Autopilot deployment itself continues to work — only SoftwareCentral's management of it stops. |
| Read-only alternative | DeviceManagementServiceConfig.Read.All. The Autopilot list still displays with full detail; import, delete, group-tag editing and the Enrollment Status Page update stop. Choose this if Autopilot registration is handled by your OEM or by another process. |
Device.ReadWrite.All Read & write
| Why it is needed | Two distinct reasons. First, and most importantly: Microsoft requires Device.ReadWrite.All alongside GroupMember.ReadWrite.All to add a device to a group using application permissions. Device-targeted software deployment is done by group membership, so this permission is on the critical path for every machine-targeted installation. Second, it allows the Entra device object to be removed when a computer is decommissioned, so that the directory does not accumulate stale records. |
|---|---|
| Where it is used | Manage Software and the Shop whenever software is targeted at a device; Delete Computer (the option “also delete the device in Entra ID”); device group-membership views; and the Entra device cache used to reconcile ConfigMgr, Intune and Entra records. |
| Graph resources called | GET /devices, /devices/delta, /devices/{id}/memberOf and /transitiveMemberOf, DELETE /devices/{id}, and the device leg of POST /groups/{id}/members/$ref. |
| Without this permission | Adding a device to a group returns 403, so device-targeted deployment stops — including Shop orders for a machine. Entra device objects are also left behind when a computer is deleted. |
| Read-only alternative | Device.Read.All covers all reading and reconciliation. It is viable only if you deploy exclusively to users, because Microsoft's documented requirement for adding a device to a group is the read-write form. If you use device-targeted deployment at all, this permission is not reducible. |
WindowsUpdates.ReadWrite.All Read & write read-only in use
| Why it is needed | To read Microsoft's Windows feature-update catalogue, so that a raw build number such as 10.0.19045.4291 can be shown as Windows 10 22H2 and flagged when that release has reached end of service. It is reference data about Windows itself, not about your tenant. |
|---|---|
| Where it is used | The operating-system column on device lists and the device view; Windows servicing and patch reporting. |
| Graph resources called | GET /admin/windows/updates/catalog/entries — and nothing else. SoftwareCentral never creates a deployment, an audience or an update policy through this API. |
| Without this permission | Operating systems are displayed as build numbers and there is no end-of-service flag. Nothing else changes; this is a display-quality permission. |
| Read-only alternative | None exists. Microsoft's Windows Update deployment service publishes only the read-write scope for this surface, so a read-only grant is not possible. Because the only call SoftwareCentral makes is a GET, this is a reasonable one to decline if the write scope is unacceptable — the cost is limited to the two display features above. |
BitlockerKey.Read.All Read
| Why it is needed | So that an authorised help-desk operator can read out a BitLocker recovery key to a user who is locked out, without being given access to the Intune or Entra admin centre. |
|---|---|
| Where it is used | Device Manager → BitLocker tab, and the BitLocker recovery keys window opened from a device. |
| Graph resources called | GET /informationProtection/bitlocker/recoveryKeys?$filter=deviceId eq '…' followed by GET /informationProtection/bitlocker/recoveryKeys/{id}?$select=key for the device the operator opened. Keys are never listed or cached in bulk. |
| Without this permission | The BitLocker tab cannot show a key and operators must fall back to the Entra admin centre. |
| Read-only alternative | BitlockerKey.ReadBasic.All, in Microsoft's words: “Does not allow read of the recovery key.” SoftwareCentral can then confirm that a key is escrowed — volume, device and backup date — which is enough for compliance reporting, but cannot display the key itself. Choose this if recovery keys must not be readable through SoftwareCentral. |
| Audit note | Retrieving a recovery key is recorded by Microsoft in the Entra audit log (KeyManagement), so key reads through SoftwareCentral are visible to your own auditing regardless of which product performed them. |
CloudPC.ReadWrite.All Read & write
| Why it is needed | Windows 365 Cloud PCs are managed devices too, and SoftwareCentral lists them alongside physical machines so that the help desk works in one place. The write half is for the Cloud PC lifecycle actions. |
|---|---|
| Where it is used | Cloud PCs in the device lists (only when Windows 365 support is switched on in SoftwareCentral), and the Cloud PC actions: restart, rename, reprovision, resize, restore from snapshot, create snapshot, end grace period, troubleshoot, start, stop, power on, power off and delete; plus connection history, provisioning policies, gallery images and service plans. |
| Graph resources called | /deviceManagement/virtualEndpoint/cloudPCs and its actions, /virtualEndpoint/provisioningPolicies, /virtualEndpoint/galleryImages, /virtualEndpoint/servicePlans. |
| Without this permission | Cloud PCs do not appear in SoftwareCentral and no Cloud PC action works. Physical devices are unaffected. If you do not use Windows 365, switch the feature off in SoftwareCentral and do not grant the permission. |
| Read-only alternative | CloudPC.Read.All. Cloud PCs are listed and reported on exactly as before; every Cloud PC action stops. |
DeviceLocalCredential.Read.All Read
| Why it is needed | Windows LAPS. When a machine's local administrator password is rotated and escrowed to Entra, this permission lets an authorised operator read the current password to perform local repair work — and, on macOS, the FileVault recovery key. |
|---|---|
| Where it is used | Device Manager → Local administrator password tab, and the local administrator password window opened from a device. |
| Graph resources called | GET /directory/deviceLocalCredentials/{deviceId}?$select=credentials, for one device at a time. |
| Without this permission | The tab cannot show a password; operators must use the Entra admin centre. |
| Read-only alternative | DeviceLocalCredential.ReadBasic.All. Microsoft is explicit here: the credentials property — the password itself — requires DeviceLocalCredential.Read.All, and ReadBasic is insufficient. With ReadBasic SoftwareCentral can show that LAPS is backing the device up and when it last did so, but never the password. Choose this if LAPS passwords must not be readable through SoftwareCentral. |
DeviceManagementRBAC.Read.All Read
| Why it is needed | To read the tenant's Intune scope tags. When SoftwareCentral creates or edits an Intune application it must offer the same scope tags Intune would, so that the object lands inside the correct Intune RBAC scope and remains visible to the right Intune administrators. |
|---|---|
| Where it is used | Create Intune Application, Edit Intune Application and Intune Application Template — the scope-tag picker. |
| Graph resources called | GET /deviceManagement/roleScopeTags. |
| Without this permission | The scope-tag picker is empty and applications are created with the default scope tag only. If your tenant uses Intune scope tags for delegation, objects created by SoftwareCentral may end up outside the intended scope. |
| Read-only alternative | This is the least-privileged option: Microsoft's higher-privileged alternative is DeviceManagementRBAC.ReadWrite.All, which SoftwareCentral deliberately does not request. It reads Intune role scope tags only; it does not read or change Intune role assignments. |
DeviceManagementScripts.ReadWrite.All Read & write
| Why it is needed | Intune platform scripts and proactive-remediation (device health) scripts, so that the help desk can see which scripts exist, whether they succeeded on a device, and run a remediation against a single machine when troubleshooting. |
|---|---|
| Where it is used | The script overview on the Intune dashboard, the remediation history on a device, and “run remediation script” in the Intune action panel. |
| Graph resources called | /deviceManagement/deviceManagementScripts, /deviceManagement/deviceHealthScripts with /runSummary and /deviceRunStates. |
| Without this permission | The script overview and remediation history are empty. Scripts continue to run on devices as Intune schedules them — only SoftwareCentral's visibility is lost. |
| Read-only alternative | DeviceManagementScripts.Read.All keeps the full script inventory and all run results. SoftwareCentral never creates or edits a script, so the read form is sufficient for everything except the on-demand run — and that action is in any case governed by DeviceManagementManagedDevices.PrivilegedOperations.All, not by this permission. The read form is the recommended grant. (Microsoft moved these endpoints from the DeviceManagementConfiguration.* scopes onto the dedicated DeviceManagementScripts.* scopes in July 2025.) |
5 Application Deployment (Application permissions)
DeviceManagementApps.ReadWrite.All is documented in section 4 with the other device-management scopes. The four permissions below complete the deployment chain: the group that receives the software, the members added to it, the directory lookups behind both, and SoftwareCentral's maintenance of its own app registration.
Group.ReadWrite.All Read & write
| Why it is needed | SoftwareCentral delivers software through Entra groups. An application template creates the groups a new application needs — typically an install and an uninstall group — and removes them again when the application is retired, so the directory does not fill up with orphaned groups nobody dares delete. |
|---|---|
| Where it is used | Intune Application Templates (automatic group creation), Entra ID Groups (create, rename, delete), Delete application including its groups, and the group cache the background service maintains. |
| Graph resources called | POST /groups, PATCH /groups/{id}, DELETE /groups/{id}, GET /groups, /groups/delta, /groups/{id}/members and /transitiveMembers. |
| Without this permission | No group can be created, renamed or deleted from SoftwareCentral. Application templates fail at the group-creation step, and every new application has to be pointed at a group somebody created by hand first. |
| Read-only alternative | Group.Read.All combined with GroupMember.ReadWrite.All is a workable middle ground: SoftwareCentral can still use and populate existing groups, it just cannot create or delete them. A narrower write option is Group.Create, which permits creating a group but not modifying or deleting one — note Microsoft's caveat that a group created with Group.Create and no owner is created anonymously and cannot afterwards be modified, so it only suits a tightly-controlled flow. |
GroupMember.ReadWrite.All Read & write
| Why it is needed | This is the permission that actually delivers software. Installing an application means adding the user or the device to the application's group; uninstalling means removing them. Every Shop order, every approval, every phased deployment and every licence reclaim ends in one of these two calls. |
|---|---|
| Where it is used | Manage Software (add or remove a device or user for an application), the Shop and its approval flow, phased deployments, licence harvesting (removing a user when an unused licence is reclaimed), and group membership editing on the Entra ID Groups page. |
| Graph resources called | POST /groups/{id}/members/$ref, DELETE /groups/{id}/members/{id}/$ref, and the membership reads that check whether an object is already a member before writing. |
| Without this permission | Nothing can be deployed or removed. The Shop, approvals, phased deployments and licence harvesting all stop. |
| Read-only alternative | GroupMember.Read.All gives membership visibility only; Microsoft offers no partial write, so there is no way to allow adding members while forbidding removal. Two pairings are worth knowing: adding a device also requires Device.ReadWrite.All, and adding a member to a role-assignable group also requires RoleManagement.ReadWrite.Directory (section 6). |
Directory.Read.All Read
| Why it is needed | The general directory reads that do not belong to one specific resource scope: which verified domains the tenant owns, which subscriptions and service plans it holds, and how directory objects relate to each other when a group's membership is resolved across nested groups. |
|---|---|
| Where it is used | The domain picker when creating an Entra user; licence and Windows 365 service-plan lists; nested group membership resolution; and the connection test in Settings, which reads the app registration's own service principal to report which permissions have actually been consented. |
| Graph resources called | GET /domains, GET /subscribedSkus, GET /servicePrincipals and its appRoleAssignments, and directory-object reads used by the membership resolution. |
| Without this permission | Creating an Entra user cannot offer the verified domains, licence and service-plan lists are empty, and the connection test cannot tell you which permissions are missing — which makes every other problem on this page harder to diagnose. |
| Narrower alternative | It is already a read-only permission. If your policy is to avoid the broad directory read, the three uses can be covered individually by Domain.Read.All, Organization.Read.All and Application.Read.All — SoftwareCentral works with those three granted instead. Directory.Read.All is requested because it is the single permission Microsoft documents for all of them. |
Application.ReadWrite.All Read & write easiest to decline
| Why it is needed | Convenience during setup, and nothing else. SoftwareCentral's First Time Setup offers a button that writes the required permission list into its own app registration, so an administrator does not have to add more than twenty permissions by hand. That single button is the only reason this permission is on the list. |
|---|---|
| Where it is used | Settings → First Time Setup and Settings → Manage Intune Tenants: apply the required permissions. Nothing in day-to-day device, user or application management uses it. |
| Graph resources called | GET /applications?$filter=appId eq '…' and PATCH /applications/{id} — against SoftwareCentral's own registration only. |
| Without this permission | The “apply required permissions” button fails. Permissions are then assigned by hand, or by pasting the manifest in section 12 — which produces exactly the same result. Every other feature is unaffected. |
| Narrower alternative | Two good options. (a) Application.ReadWrite.OwnedBy — Microsoft: the same operations, but “it cannot update any apps that it is not an owner of”. Add the SoftwareCentral service principal as an owner of its own registration and self-maintenance still works, with no ability to touch any other application. (b) Grant nothing, or only Application.Read.All, and apply the manifest by hand. This is the permission most security teams object to, and the one we most readily recommend dropping — a tenant-wide Application.ReadWrite.All is a legitimate concern, because an application that can rewrite app registrations can in principle widen its own access. |
6 Group Management (Application permissions)
RoleManagement.ReadWrite.Directory Write grant only if required
| Why it is needed | One reason only: Microsoft requires it to add a member to a role-assignable group. In Microsoft's words, “to add members to a role-assignable group, the app must also be assigned the RoleManagement.ReadWrite.Directory permission”. If any of the groups SoftwareCentral maintains is role-assignable, membership writes to that group fail without it. |
|---|---|
| Where it is used | The same Manage Software and Shop membership operations as GroupMember.ReadWrite.All — but only when the target group happens to be role-assignable. It is never used on its own. |
| Graph resources called | None directly. It acts as an additional authorisation check on POST /groups/{id}/members/$ref. |
| Without this permission | Adding a member to a role-assignable group fails with 403. Ordinary security groups — which is what deployment groups normally are — are completely unaffected. For most customers nothing at all breaks. |
| Narrower alternative | Decline it unless you know you deploy to role-assignable groups. The read-only form, RoleManagement.Read.Directory, does not authorise the membership write, so it buys nothing here. Be aware of what the write form implies: it allows an application to read and modify directory role assignments in general, not merely group membership, which makes it one of the most consequential permissions on this page. SoftwareCentral only ever uses it as the side-effect authorisation described above. |
7 User Management (Application permissions)
User.ReadWrite.All Read & write
| Why it is needed | Two things. Reading users is unavoidable — a device has an owner and a primary user, an order has a requester, an approval has an approver, and all of them are Entra users. Writing users is the delegated user-administration feature: creating, editing, cloning, disabling and deleting accounts, and resetting a password, all inside SoftwareCentral's own security-role model rather than by handing out Entra admin roles. |
|---|---|
| Where it is used | Entra ID Users (create, edit, clone, delete), Manage Entra user and Manage Intune user, Reset Password and Password Manager, User Device Affinity, revoke sign-in sessions, user photos and manager lookups, and the background user cache. |
| Graph resources called | GET/POST/PATCH/DELETE /users, /users/delta, PATCH /users/{id} carrying passwordProfile for a reset, POST /users/{id}/revokeSignInSessions, /users/{id}/memberOf, /manager, /photo, /ownedDevices. |
| Without this permission | Without any user permission SoftwareCentral cannot resolve device owners, order requesters or approvers — the effect is felt everywhere, not just on the user pages. Without the write half, the user pages become read-only and password reset fails. |
| Read-only alternative | User.Read.All for a read-only user directory — everything except user administration continues to work. If you want password reset but not full user administration, Microsoft now publishes granular write permissions that can replace User.ReadWrite.All: User-PasswordProfile.ReadWrite.All is the least-privileged permission for a password reset, and User.EnableDisableAccount.All covers enabling and disabling an account. |
| Important limits | Microsoft imposes two restrictions that are not obvious. In application-only scenarios the calling app must, in addition to the permission, hold a supported Entra role — at least User Administrator — before it may update passwordProfile. And resetting the password of a user who is an administrator requires Privileged Authentication Administrator. A permission grant alone will therefore not let SoftwareCentral reset an administrator's password, which is usually exactly what a security team wants. |
AuditLog.Read.All Read
| Why it is needed | So that an operator investigating “the user cannot sign in” can see the sign-in attempts and the recent directory changes for that account on the same screen as the device, instead of switching to the Entra admin centre. |
|---|---|
| Where it is used | The user sign-in log window, the audit history on a user, and the last-sign-in date shown on user views. |
| Graph resources called | GET /auditLogs/signIns, GET /auditLogs/directoryAudits, and the signInActivity property on /users. |
| Without this permission | Those panels are empty and say so. Nothing else is affected. Note that this data also requires a Microsoft Entra ID P1 or P2 licence — without one the API returns nothing even when the permission is granted. |
| Read-only alternative | It is already read-only, and it is the permission Microsoft requires for the sign-in and directory-audit logs. Reports.Read.All covers some reporting surfaces but not these two. Decline it if sign-in history should not be surfaced in SoftwareCentral. |
UserAuthenticationMethod.ReadWrite.All Read & write privileged
| Why it is needed | Help-desk account recovery. When a user loses the phone carrying their authenticator, someone has to see which methods are registered, clear them so the user can register again, and hand out a Temporary Access Pass so the user can get back in and re-enrol. Without this, that workflow needs an Entra administrator. |
|---|---|
| Where it is used | Manage Entra user and Manage Intune user → authentication methods; Reset MFA; Temporary Access Pass issue and revoke. |
| Graph resources called | GET /users/{id}/authentication/methods and /signInPreferences; DELETE on /authentication/microsoftAuthenticatorMethods|softwareOathMethods|phoneMethods/{id}; GET/POST/DELETE /users/{id}/authentication/temporaryAccessPassMethods. |
| Without this permission | Registered MFA methods cannot be shown or cleared and a Temporary Access Pass cannot be issued. Users needing account recovery must be handled in the Entra admin centre. |
| Read-only alternative | UserAuthenticationMethod.Read.All. SoftwareCentral can then show which methods a user has registered — useful on its own for triage — but cannot remove a method or issue a pass. This is the right choice for customers who want visibility without giving the help desk account-recovery powers. |
| Security note | Treat the read-write form as privileged: it changes how a user authenticates, and a Temporary Access Pass is a working credential. If you grant it, restrict the corresponding tools to a named SoftwareCentral security role rather than to first-line support, and review the SoftwareCentral log — every reset and every pass issued is written to it with the operator's name. |
8 Mail (Application permission)
Mail.Send Write optional
| Why it is needed | SoftwareCentral sends notification mail — an order needs approval, an approval was granted, a deployment finished, a patch window is opening, a licence is about to be reclaimed. Mail.Send lets it send through Microsoft Graph, which avoids maintaining an SMTP relay and its credentials. |
|---|---|
| Where it is used | Shop orders and the approval flow, approver management, patch management notifications, phased deployments, licence harvesting and licence-owner mails, the ServiceNow bridge, mail templates and the send test mail button in Settings. |
| Graph resources called | POST /users/{sender}/sendMail, where {sender} is the single sender address configured in SoftwareCentral's mail settings. |
| Without this permission | Graph mail fails. Whether that matters depends on the mail mode you choose — see the alternative. |
| Alternative — and the recommended hardening | (a) Do not grant it at all. SoftwareCentral can send through SMTP or Office 365 SMTP instead; this is a setting, not a code change, and mail then never touches Graph. (b) Grant it, but scope it. Exchange Online can restrict which mailboxes an application may send as, using RBAC for Applications (or the older New-ApplicationAccessPolicy). Because SoftwareCentral only ever sends from its one configured sender address, scoping the app to that single mailbox costs nothing and removes the tenant-wide reach that makes Mail.Send uncomfortable. If you grant Mail.Send, we recommend you scope it. |
9 Service account
A service account is only required for features Microsoft does not expose to an application-only token in the way SoftwareCentral needs: reading BitLocker recovery keys, resetting user passwords, and in some setups sending mail. If you do not use those features, you do not need a service account at all — and most installations do not.
How the service-account token is obtained — read this before approving
SoftwareCentral acquires the on-behalf-of token with the OAuth 2.0 resource owner password credentials grant, sending the account's user name and password to Microsoft Entra ID. That flow cannot satisfy an interactive multi-factor prompt, which is why the account must have MFA disabled and must be a cloud-only account rather than a synchronised on-premises one. Because a non-MFA account is a standing exception to most MFA policies, treat it accordingly: give it the minimum roles listed below, exclude it from nothing else, and prefer to omit it entirely if the three features above are not needed.
Delegated permissions used by the service account
| Permission | Used for |
|---|---|
openid · profile · email | Obtaining the token and identifying the account. |
BitlockerKey.Read.All | Reading a BitLocker recovery key on behalf of the account. Downgrade to BitlockerKey.ReadBasic.All to expose escrow status without key material. |
UserAuthenticationMethod.ReadWrite.All | MFA method reset and Temporary Access Pass. Downgrade to UserAuthenticationMethod.Read.All for visibility only. |
Mail.Send | Sending mail as the service account rather than as the application. Not needed if you use SMTP. |
Requirements on the account
The account
It must be created in Microsoft Entra ID — it cannot be a synchronised on-premises account — and it must have multi-factor authentication disabled.
To read BitLocker recovery keys, the service account defined under Settings must hold one of the following Entra roles. They are listed from least to most privileged; choose the first one that works for you — Security Reader or Global Reader are read-only and are sufficient for key retrieval in most tenants.
- Security reader
- Global reader
- Helpdesk administrator
- Security administrator
- Cloud device administrator
- Intune service administrator
- Global administrator
Password reset needs a role as well as a permission
As noted in section 7, Microsoft requires the calling identity to hold at least User Administrator before it may reset a password, and Privileged Authentication Administrator before it may reset an administrator's password. Granting the permission without the role produces a clean failure, not a silent one.
10 Azure database
If the SoftwareCentral database is hosted in Azure SQL rather than on your own SQL Server, the application authenticates to its own database with the same app registration instead of a SQL login. That requires one further permission, on the Azure SQL Database resource rather than on Microsoft Graph:
Azure SQL Database→app_impersonation(Application permission)
It grants access to the database the application is pointed at — SoftwareCentral's own — and nothing in Microsoft Graph. On an on-premises SQL Server installation it is not needed.
If you cannot find this permission in the Azure portal, try the following:
- Create an Azure SQL database and add yourself as either an admin or a user.
- Log in to that database with Microsoft SQL Management Studio using your Entra ID credentials.
- You can now search for the permission “Azure SQL Database”.
11 Verify the grant, and who can use it
Check what was actually consented
SoftwareCentral tests its own access rather than assuming it. In Settings → Manage Intune Tenants (and during First Time Setup) the test connection function signs in with the app registration, reads back the app roles that have genuinely been consented, and lists any that are missing by name for both the application and the service-account identity. Run it after granting consent — it takes a few minutes for a new grant to take effect, and this is how you confirm it has.
Reducing the grant safely
If you intend to withhold a permission, withhold it and run the connection test: SoftwareCentral will name it as missing, and the affected feature will report an error to the operator rather than failing quietly. Nothing in the product degrades silently on a missing permission — that is a deliberate design decision, because an empty screen is indistinguishable from a tenant with nothing to show.
Who inside SoftwareCentral can use these permissions
The Graph grant defines the ceiling; it does not define who reaches it. Inside SoftwareCentral, access is governed by security roles: each role is given a specific set of tools and a specific scope of devices, users and applications. A first-line operator can be granted Sync and Restart while Wipe, Retire, Reset MFA and BitLocker key are reserved to a named administrator role. Every action is written to the SoftwareCentral log with the operator's name, the object and the outcome.
Consent is yours to withdraw
Every permission on this page is granted on an app registration in your own tenant. It can be reduced or revoked at any time from the Azure portal, with immediate effect on the next token — no involvement from SoftwareCentral is required.
12 Required permissions manifest
Add the snippet below to your app registration manifest to apply the full permission set in one step, then grant admin consent. If you are reducing the set after reviewing this page, add the permissions individually instead — this snippet is the complete list.
Show app registration manifest snippet
"requiredResourceAccess": [
{
"resourceAppId": "022907d3-0f1b-48f7-badc-1ba6abab6d66",
"resourceAccess": [
{ "id": "c39ef2d1-04ce-46dc-8b5f-e9a5c60f0fc9", "type": "Role" }
]
},
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{ "id": "14dad69e-099b-42c9-810b-d002981feec1", "type": "Scope" },
{ "id": "7427e0e9-2fba-42fe-b0c0-848c9e6a8182", "type": "Scope" },
{ "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" },
{ "id": "1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9", "type": "Role" },
{ "id": "e383f46e-2787-4529-855e-0e479a3ffac0", "type": "Scope" },
{ "id": "37f7f235-527c-4136-accd-4a02d197296e", "type": "Scope" },
{ "id": "64a6cdd6-aab1-4aaf-94b8-3cc8405e90d0", "type": "Scope" },
{ "id": "b27a61ec-b99c-4d6a-b126-c4375d08ae30", "type": "Scope" },
{ "id": "62a82d76-70ea-41e2-9197-370581804d09", "type": "Role" },
{ "id": "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8", "type": "Role" },
{ "id": "2f51be20-0bb4-4fed-bf7b-db946066c75e", "type": "Role" },
{ "id": "741f803b-c850-494e-b5df-cde7c675a1ca", "type": "Role" },
{ "id": "b0afded3-3588-46d8-8b3d-9842eff778da", "type": "Role" },
{ "id": "7ab1d382-f21e-4acd-a863-ba3e13f7da61", "type": "Role" },
{ "id": "1138cb37-bd11-4084-a2b7-9f71582aeddb", "type": "Role" },
{ "id": "78145de6-330d-4800-a6ce-494ff2d33d07", "type": "Role" },
{ "id": "9241abd9-d0e6-425a-bd4f-47ba86e767a4", "type": "Role" },
{ "id": "5b07b0dd-2377-4e44-a38d-703f09a0dc3c", "type": "Role" },
{ "id": "243333ab-4d21-40cb-a475-36241daa0842", "type": "Role" },
{ "id": "5ac13192-7ace-4fcf-b828-1a26f28068ee", "type": "Role" },
{ "id": "dbaae8cf-10b5-4b86-a4a1-f871c94c6695", "type": "Role" },
{ "id": "b7887744-6746-4312-813d-72daeaee7e2d", "type": "Scope" },
{ "id": "7dd1be58-6e76-4401-bf8d-31d1e8180d5b", "type": "Role" },
{ "id": "50483e42-d915-4231-9639-7fdb7fd190e5", "type": "Role" },
{ "id": "57f1cf28-c0c4-4ec3-9a30-19a2eaaf2f6e", "type": "Role" },
{ "id": "884b599e-4d48-43a5-ba94-15c414d00588", "type": "Role" },
{ "id": "58ca0d9a-1575-47e1-a3cb-007ef2e4583b", "type": "Role" },
{ "id": "3b4349e1-8cf5-45a3-95b7-69d1751d3e6a", "type": "Role" },
{ "id": "9255e99d-faf5-445e-bbf7-cb71482737c4", "type": "Role" },
{ "id": "b633e1c5-b582-4048-a93e-9f11b44c7e96", "type": "Role" }
]
}
],
The last six entries are, in order, BitlockerKey.Read.All, DeviceLocalCredential.Read.All, DeviceManagementRBAC.Read.All, CloudPC.ReadWrite.All, DeviceManagementScripts.ReadWrite.All and Mail.Send — the ones marked Optional or Feature in section 2. Remove any you have decided not to grant before applying the manifest.
Grant admin consent
After assigning permissions — by manifest or by hand — always grant admin consent on behalf of the organization. Newly assigned permissions can take a few minutes to take effect; use the connection test in section 11 to confirm.
Related: Intune Configuration · Application Manager Only permissions · Security Roles