Microsoft Intune Guide: Compliance Policies, Admin Roles and Hardening

Whoever controls Microsoft Intune can wipe, reconfigure or push code to every enrolled device in the organisation, so the Intune admin plane is one of the most valuable targets in a Microsoft tenant. Intune is usually deployed as a device management tool and governed like one, with broad roles, few approval steps and a handful of automation accounts holding Microsoft Graph permissions that nobody reviews. The March 2026 Stryker incident showed what happens when an attacker reaches that plane: devices were erased with the platform's own wipe command, with no malware on the endpoints. This guide covers how identity and access work in Intune, how to design admin roles and scope, how to govern the service principals and API permissions that automate it, what to log, and a hardening baseline for compliance policies, Conditional Access and security baselines. It is written for endpoint, identity and security engineers who run or audit Intune.

Key takeaways

• Treat Intune as Tier 0. Device wipe, script deployment and app assignment give fleet-wide destructive and code execution power, which MITRE ATT&CK lists under T1072 Software Deployment Tools, naming Intune explicitly.
• Turn on Multi Admin Approval for device actions (wipe, retire, delete), scripts, apps, configuration and compliance policies, and RBAC changes, so a single compromised account cannot act alone.
• Stop using Global Administrator and Intune Administrator for daily work. Use built-in or custom Intune roles with scope tags and scope groups, and keep the two Entra roles just in time.
• Automation identities are privileged NHIs. Any app holding DeviceManagementManagedDevices.PrivilegedOperations.All can wipe devices through Graph without an interactive sign-in.
• Close the compliance default gap. Set "Mark devices with no compliance policy assigned as" to Not compliant before relying on "Require device to be marked as compliant" in Conditional Access.

How identity and access work in Microsoft Intune

Intune has no identity store of its own. Every administrator, helpdesk operator and automation client is a Microsoft Entra ID identity, and access is the combination of two separate systems.

• Microsoft Entra roles: directory roles that carry Intune rights across the whole tenant. Global Administrator and Intune Administrator (shown as Intune Service Administrator in Microsoft Graph and PowerShell) have full Intune access, and Intune RBAC does not constrain them: scope tags do not apply. Other Entra roles with Intune visibility include Conditional Access Administrator, Security Administrator, Security Operator, Security Reader, Compliance Administrator, Global Reader, Helpdesk Administrator and Reports Reader.
• Intune RBAC roles: roles assigned inside Intune, either built in or custom, each assignment combining a role (what an admin can do), members, Scope (Groups) (which users and devices they can act on) and scope tags (which objects they can see).
• Applications: service principals calling Microsoft Graph deviceManagement endpoints with application permissions. These run without a user and are outside Intune RBAC, so they are governed through Entra app consent. See the Entra ID Security Guide.
• Devices: enrolled devices are themselves identities in Entra ID, and their compliance state is written back to Entra for Conditional Access to read. See the Device Trust and Posture Guide.

The practical consequence: an attacker does not need an "Intune" account. Any Entra identity with Global Administrator, Intune Administrator or the right Graph permission can drive Intune, which is why the account protections in the Conditional Access Guide matter as much as anything configured in the Intune admin centre.

Admin roles and privileged access

Microsoft recommends against using Global Administrator or Intune Administrator for day to day Intune administration. The built-in Intune roles cover most operational jobs.

Designing scope

• Scope (Groups): limit each assignment to the groups the admin actually supports. Microsoft's guidance is not to select "Add all users" or "Add all devices".
• Scope tags: tag objects by region, business unit or tier. A role assignment with no scope tag has effectively all scope tags, so an untagged assignment is a tenant-wide one. Each assignment and object can hold up to 100 tags, and new objects inherit the creator's tags.
• Permission merging: by default, Intune merges permissions when an admin has several assignments with the same permission category and different tags, which can grant broader access than intended. The Scoped permissions setting (public preview from March 2026) keeps each assignment within its own tag; it is irreversible, so run the Permissions Assessment Report under Tenant administration > Roles > Settings first.
• Not every object supports tags: Windows Autopilot devices, corporate device identifiers, compliance locations and Jamf devices do not, so do not rely on tags to separate those.

Multi Admin Approval

Multi Admin Approval (MAA) holds a change on a protected resource until a second administrator approves it. It is the control the Stryker incident most clearly called for: the Stryker Intune wiper attack page records CISA's recommendation to require a second administrative account's approval for destructive changes.

• Protected resource types: apps (not app protection policies), compliance policies, settings catalog configuration policies, device actions (wipe, retire, delete), role-based access control, Windows scripts, and tenant configuration (device categories). Role and Tenant Configuration policies are enforced automatically.
• Workflow: the requester enters a business justification; a different admin in the approver group approves or rejects; the requester then selects Complete. Requests expire after 3 days. Admins cannot approve their own requests, and this applies to Global Administrator and Intune Administrator too.
• Approvers: must be direct members of a security group (not a Microsoft 365 or mail-enabled group, which fail silently), hold the resource's Read permission, and the group must be a member group in an Intune role assignment.
• Automation: MAA also applies to app-only Graph calls against protected resources. Up to 50 enterprise apps per policy can be excluded, and each exclusion is a bypass if that app is compromised.
• Known pitfall: a Role access policy protects all RBAC changes, including the assignment the approver group needs. Configure approver RBAC before creating the Role policy, or you will have to delete and recreate it.

Pair MAA with just in time activation of the Entra roles, phishing-resistant MFA and dedicated admin accounts. See the Tiered Administration and Enterprise Access Model Guide and the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Most Intune estates accumulate automation: provisioning scripts, reporting tools, ticketing integrations, third-party patching and compliance partners. Each is a non-human identity with standing access to the device fleet, and none of them is stopped by an MFA prompt.

• Inventory first: list every service principal holding any DeviceManagement Graph permission, with owner, purpose and credential type. Remove what has no owner. See the Azure RBAC and Service Principals Guide and the Entra ID Applications and Consent Guide.
• Prefer credentials that cannot be copied: client secrets are copyable strings that end up in scripts and repositories. Use certificates held in a vault or managed identities where the workload runs in Azure. See the Secrets Management Guide.
• Watch the Intune licence requirement: Microsoft notes that the Intune Graph API needs an active tenant Intune licence; this is not a security control and should not be treated as one.

Logging and detection

Intune writes an audit event for every create, update, delete, assign and remote action. Auditing cannot be disabled. Reviewers need the Intune Administrator role or an Intune role with Audit data - Read. The portal view is Tenant administration > Audit logs, filterable by category (for example Device, Compliance, Role) and activity. Microsoft Graph exposes two years of events at GET /deviceManagement/auditEvents, and the Export option routes audit and operational logs to Azure Monitor destinations (Log Analytics, storage, event hubs) for SIEM use. See the SIEM Guide.

Metrics that show the controls work:

• Number of standing (permanent) Global Administrator and Intune Administrator assignments, target zero apart from break-glass accounts.
• Percentage of Intune role assignments with a scope tag and a scope group narrower than All users or All devices.
• Count of service principals with DeviceManagement write or privileged permissions, and the share with a named owner and a non-secret credential.
• Percentage of protected resource types covered by an MAA access policy, and number of MAA exclusions.
• Percentage of devices compliant, and number of devices with no compliance policy assigned.
• Mean time from a mass-wipe alert to account containment, measured in exercises.

Hardening baseline

Compliance and Conditional Access

• Compliance policy settings: under Endpoint security > Device compliance > Compliance policy settings, change "Mark devices with no compliance policy assigned as" from the default Compliant to Not compliant. Microsoft recommends this when Conditional Access is used.
• Validity period: the compliance status validity period defaults to 30 days (1 to 120). Shorten it if devices check in reliably, so stale devices fall out of compliance faster.
• Actions for noncompliance: mark noncompliant immediately, send email, then remote lock or retire after a grace period. Retire only marks the device for an admin to act on.
• Conditional Access: use the grant control "Require device to be marked as compliant" for corporate resources, and app-based Conditional Access with app protection policies for unenrolled mobile devices. See the Mobile Device Security Guide.
• Protect the admin portal itself: target Conditional Access at the Intune admin roles with phishing-resistant MFA and compliant admin workstations. See the Windows Hello for Business Guide.

Security baselines and endpoint settings

• Use the current baseline versions: Security Baseline for Windows 10 and later (current versions include 24H2, 25H2 and 26H2), Microsoft Defender for Endpoint, Microsoft 365 Apps for Enterprise and Microsoft Edge. Older-version profiles become read-only, so plan version upgrades.
• Do not run preview baselines in production: their settings can change during the preview.
• Resolve conflicts: baselines can overlap with configuration profiles and endpoint security policies, and defaults are generally the most restrictive. Check per-setting status in baseline monitoring before rollout.
• Disk encryption: enforce BitLocker and FileVault through endpoint security policies and require encryption in compliance. See the Disk Encryption Guide: BitLocker and FileVault.
• Remove local admin: use Windows LAPS for the built-in account and Endpoint Privilege Management (EPM) for user elevation. EPM elevates through an isolated virtual account (except "Elevate as current user"), supports automatic, user confirmed and support approved elevation for .exe, .msi and .ps1 files, and reports unmanaged elevations. Prefer user confirmed or support approved over broad automatic rules. See the Local Administrator Password Solution (LAPS) Guide.

Rollout order

1. Inventory: export all role assignments, Entra role holders with Intune power, and service principals with DeviceManagement permissions.
2. Build custom roles and scope tags; move daily admins off Global Administrator and Intune Administrator; make those Entra roles just in time.
3. Create the MAA approver security group and its RBAC assignment, then enable access policies for device actions and scripts first, then apps, configuration and compliance, and finally the Role policy.
4. Pilot the compliance default change and new baselines on a pilot ring with report-only Conditional Access, review sign-in impact, then widen.
5. Rollback: baseline and configuration changes are reverted by reassigning the previous profile version; MAA access policies can be removed (which itself needs approval), so keep two approvers available at all times.
6. Connect audit export to the SIEM and implement the detections above before declaring the work complete.

Small vs large organisations: a small team with three Intune admins can still enable MAA, but needs at least two approvers so one absence does not block change; scope tags add little value with one region. Large or federated organisations should invest in scope tags per region or subsidiary, a dedicated Intune Role Administrator function, and the Scoped permissions setting once tested.

Common misconfigurations

• One account can wipe the fleet: standing Global Administrator plus no MAA means a single compromised session can erase every device, as in the Stryker Intune wiper attack, where tens of thousands of devices were erased with the platform's own wipe command.
• Untagged, all-devices assignments: role assignments with no scope tag and "All devices" scope turn every regional helpdesk role into a global one.
• Compliant by default: leaving "Mark devices with no compliance policy assigned as" set to Compliant lets unassessed devices pass "Require device to be marked as compliant".
• Forgotten automation apps: an old reporting or migration app keeps a client secret and PrivilegedOperations permission years after the project ended, and an MAA exclusion added for convenience lets it bypass approval.
• MAA approver groups that do not work: using a Microsoft 365 group or nested groups as the approver group, which fails silently, or creating the Role policy before approver RBAC and locking the tenant out of RBAC changes.
• Baseline drift and conflicts: old baseline versions left in place alongside new ones, producing conflicting values that nobody investigates.

Framework mapping

Practitioner checklist

• List every holder of Global Administrator and Intune Administrator; make them just in time and remove standing assignments apart from break-glass accounts.
• Replace tenant-wide daily admin with built-in or custom Intune roles, each with a scope tag and a scope group narrower than All users or All devices.
• Enable Multi Admin Approval for device actions and scripts, then apps, configuration, compliance and RBAC, with a working direct-member security approver group.
• Inventory service principals with DeviceManagement Graph permissions; assign owners, remove unused ones, replace client secrets and avoid MAA exclusions.
• Set "Mark devices with no compliance policy assigned as" to Not compliant and review the validity period.
• Require phishing-resistant MFA and compliant admin devices for every Intune-capable role through Conditional Access.
• Deploy current security baselines on a pilot ring, resolve conflicts, then widen; retire old baseline versions.
• Export Intune audit logs to the SIEM and alert on bulk wipe, retire or delete actions, new privileged role assignments and new app consents.
• Remove standing local admin with Windows LAPS and Endpoint Privilege Management.
• Run a tabletop exercise of a hijacked Intune admin account and measure time to containment.

Standards and references

• Microsoft Learn: Use Multi Admin Approval in Intune
• Microsoft Learn: Role-based access control with Microsoft Intune
• Microsoft Learn: Use role-based access control and scope tags for distributed IT
• Microsoft Learn: Device compliance policies in Microsoft Intune
• Microsoft Learn: Security baselines in Intune
• Microsoft Learn: Use audit logs to track and monitor events in Intune
• Microsoft Learn: managedDevice wipe (Microsoft Graph)
• MITRE ATT&CK: Software Deployment Tools

Related NHI Mgmt Group resources: Entra ID Security Guide · Conditional Access Guide · Jamf Guide · UEM Buyer's Guide · Stryker Intune wiper attack