Hardening Intune for Admin Compromise Scenarios

Hardening Intune for Admin Compromise Scenarios

The recent incident where an Intune administrator account was compromised and used to wipe around 200,000 managed devices is a stark reminder: if someone gains access to an MDM admin, they don’t need malware—they can use the platform’s built-in capabilities.

In this post, we’ll walk through three practical layers you can implement in Intune and Entra ID to reduce the impact of such a compromise:

• Multi-Admin Approval for sensitive actions in Intune
• Intune RBAC with proper scoping instead of broad “Intune Administrator” access
• Entra ID controls such as passkeys, managed-device access, token protection, and CAE strict enforcement

The goal is not to cover every possible setting, but to show how these three areas connect directly to the “compromised Intune admin performs Remote Wipe” scenario.

---

1. Multi-Admin Approval in Intune

Multi-Admin Approval (MAA) adds an approval workflow on top of certain sensitive actions in Intune. Instead of an admin clicking Wipe and the command going out immediately to devices, the action is placed in a pending state and must be approved by another admin.

This is exactly the kind of control that helps when you already assume that one admin account might be compromised at some point.

How it works

Conceptually, the flow is:

1. Admin A initiates an action on a device or a set of devices (e.g., Wipe or Retire)
2. The action is not executed immediately—it moves into a pending queue
3. Admin B, who is part of an approvers group, reviews the request and either approves or rejects it
4. Only after explicit approval does Intune send the command to devices

Configuration

When you enable MAA, you define:

• Which actions require approval (e.g., device wipe, retire, delete, or sensitivity around certain configuration changes)
• Which Entra ID security group is allowed to approve those actions

Security benefits

From a security perspective, the important points are:

• A single compromised admin account is no longer enough to perform destructive actions at scale
• You can separate the people who initiate operational actions (helpdesk, regional IT, etc.) from the smaller group who can approve high-impact operations
• You gain an audit trail around who requested what and who approved it

Implementation approach

In practice, you’ll usually:

1. Start by enabling MAA for the most destructive actions (Remote Wipe, Retire, Delete device)
2. Put a small number of experienced admins in the approver group
3. Test the approval flow on a small subset of devices before relying on it in production

---

2. Using Intune RBAC and Scoping Instead of a Single Large Admin Role

The second layer is Intune’s role-based access control combined with scoping (e.g., via scope tags).

Historically it was common to hand out the Intune Administrator role to anyone who needed to “manage devices” or “check policies.” Today, Intune has a mature RBAC model and the ability to limit what each role can see and manage.

Core principles

The idea here is simple:

• You define roles with the minimum set of permissions needed for a specific job
• You use scoping (e.g., scope tags) to define which devices, policies, or apps that role can manage
• You assign people to those roles based on what they actually do, instead of giving them tenant-wide permissions

Example roles

Some examples that work well in practice:

Role	Permissions	Scope
Helpdesk	Restart devices, sync policies, lock device	Cannot wipe or retire
Device Enrollment	Enroll and remove devices	Cannot change compliance policies or security baselines
Security Engineers	View compliance and configuration	Cannot push destructive actions to devices
Regional IT	Full management within region	Only their own segment of devices and policies

Benefits of scoping

When you combine this with scoping:

• A helpdesk team in one region cannot see or affect devices in another region
• A team responsible only for test environments does not have access to production devices
• A compromise of a low-privilege, limited-scope account has much less impact

Best practice

The key point is not to rely on one large “Intune Administrator” role for day-to-day work. Instead, you design roles around tasks and assign them to specific scopes.

For rare cases where broad permissions are required, you can still use privileged roles through Entra ID PIM with just-in-time (JIT) elevation and time-limited approval.

---

3. Entra ID Controls: Passkeys, Managed Devices, Token Protection, CAE Strict

The third layer is the identity side in Entra ID. Even with MAA and RBAC in place, protecting the sign-in and token layer is critical, especially for admin accounts.

There are a few controls that fit this Intune admin compromise scenario particularly well:

Passkeys / Passwordless for admins

Instead of passwords and traditional MFA, move your admin accounts to phishing-resistant methods such as:

• Windows Hello for Business
• FIDO2 security keys (passkeys)

This reduces the chances that a phishing campaign will capture reusable credentials for an Intune admin in the first place.

Requiring managed or compliant devices for admin access

With Conditional Access, you can require that admins only access Intune (and other admin portals) from devices that are:

• Managed by the organization, and
• Compliant according to your policies

That means an attacker who somehow gains credentials but tries to access from an unmanaged or personal machine will be blocked at the Conditional Access layer.

Common pattern:

1. Scope the policy to users in admin roles
2. Target the Microsoft Intune admin center and related admin portals
3. Require a compliant device as part of the grant controls

Token Protection and CAE Strict Enforcement

Modern attacks often don’t involve logging in with a username and password. Instead, they re-use captured tokens. Two Entra ID features are relevant here:

• Token Protection for sign-in sessions, which binds tokens to specific devices so they can’t easily be replayed from another machine
• Continuous Access Evaluation (CAE) strict enforcement, especially for location

With CAE strict enforcement, tokens are evaluated continuously against your policies. If something changes—for example, the IP or location—the existing token can be invalidated immediately instead of staying valid until its normal expiry.

In the context of a compromised admin:

• If an attacker tries to re-use a token from a different country or network than allowed, access can be cut off in real time
• You don’t rely on static token lifetimes to limit how long the attacker can use that token

Combined with location-based Conditional Access for admins, this gives you tighter control over where admin tokens can be used and for how long.

---

Bringing it all together

The controls above are complementary:

Layer	Purpose	Impact
Multi-Admin Approval	Safety net around destructive actions	Prevents single admin from executing mass wipe
Intune RBAC + Scoping	Reduces blast radius	Limits what any one admin can see and do
Entra ID Protections	Prevents credential/token theft	Reduces likelihood of successful compromise

Some of these settings are relatively simple to implement. Others require design, testing, and a rollout plan that fits your environment.

Full technical details for each of the above areas, including step-by-step configuration guidance and limitations, can be found in the official Microsoft documentation.