On March 11, 2026, a major U.S. medtech corporation was hit by a cyberattack that wiped nearly 80,000 devices. No malware. No ransomware. The attackers compromised a single administrator account, created a new Global Administrator, and used Intune’s built-in remote wipe command to erase devices across the entire organization — in the middle of the night.
CISA responded within a week with an urgent advisory. Microsoft published hardening guidance three days after the breach. The message from both is identical: if you manage devices through Intune and have not hardened your administrative controls, you are operating with a safety net that does not exist.
This post walks through what happened, what Microsoft recommends in their newly published best practices, and how to implement these controls in your own environment.
🧨 What Happened
The attack was carried out by a state-linked hacktivist group. Their approach was remarkably straightforward:
- Compromise an existing administrator account
- Create a new Global Administrator account through that access
- Use Intune’s built-in remote wipe to delete data from approximately 80,000 devices
No custom payloads. No persistence mechanisms. Just legitimate admin tooling, used exactly as designed, by someone who should never have had access.
The impact went far beyond IT disruption. Medical systems used by emergency services in an entire U.S. state went offline. Hospitals and EMS were forced to fall back to communication methods. An endpoint management breach became a patient safety incident.
This is the textbook definition of a living-off-the-land attack — and it succeeded because a single account could trigger a destructive action across the entire device estate without any second check.
🔍 The Architecture Problem
Intune did nothing wrong. It processed a valid command from an account with sufficient privileges. The problem is that most Intune environments still operate on a trust model where individual admin accounts hold broad, standing permissions — and no verification step exists before destructive actions execute.
Microsoft’s post-incident guidance, published on the Community Hub under “Best practices for securing Microsoft Intune,” frames this as three interconnected gaps:
- Too much standing privilege — Admins with broad roles that exceed their actual job needs
- Insufficient authentication controls — Privileged access not gated by strong, phishing-resistant policies
- No operational governance — High-impact actions executable by a single account without review
Addressing all three is what moves an Intune environment from “trusted administrators” toward protected administration by design.
🛡️ Best Practice 1: Least-Privilege — Design Roles Around Real Admin Jobs
Least-privilege is not just about removing Global Administrator assignments. It is about limiting both the actions an admin can take and the users and devices those actions can be applied to.
Inventory and reduce broad role assignments
Start by auditing who currently holds Intune Administrator, Global Administrator, or other high-impact Entra ID roles. Remove assignments that do not map to a named job function. These privileged roles should not be used for daily administrative tasks within Intune.
Use built-in and custom RBAC roles
Intune ships with built-in roles for common personas — Help Desk Operator, Application Manager, Endpoint Security Manager, Read Only Operator. Use these as your baseline. Where they do not fit, create custom roles with the minimum permissions required for the specific task.
Implement Scope Tags
Scope tags are the second dimension of least-privilege that is easy to overlook. They constrain an admin’s visibility and actions to a defined set of users and devices — for example, only devices assigned to a specific region, business unit, or platform team. Without scope tags, even a narrowly defined role still has tenant-wide reach.
Eliminate standing access with PIM
No one should be a permanent Intune Administrator. Use Microsoft Entra Privileged Identity Management (PIM) to assign time-bound roles that require approval and reauthentication on elevation. Standing access is standing risk.
🔐 Best Practice 2: Phishing-Resistant Authentication and Privileged Access Hygiene
The security objective is straightforward: privileged access should be hard to obtain and hard to reuse.
Conditional Access for Admin Portals
Create dedicated Conditional Access policies specifically for privileged roles and admin portals — Intune, Microsoft Entra, and related admin endpoints. These policies should:
- Require phishing-resistant MFA only (not push notifications, not SMS)
- Require a compliant or Entra (Hybrid) Joined device
- Challenge high-risk users or sign-ins via Identity Protection signals
- Restrict access by location or trusted network where feasible
- Reduce or eliminate policy exclusions
Standard MFA is not enough. If an attacker can intercept or social-engineer a push notification, MFA becomes a checkbox rather than a control.
Privileged Admin Workstations (PAWs)
For high-privilege admin accounts, establish dedicated privileged admin workstations with higher security baselines. Admin actions should originate from hardened, controlled devices — not from the same laptop used for email and web browsing.
Token Theft Protection
Operationalize your token theft response plan. Even phishing-resistant MFA cannot help if session tokens are stolen post-authentication.
- Investigate risky sign-ins and unusual admin activity through Microsoft Defender XDR
- Leverage signals from Microsoft Entra, Microsoft Defender for Cloud Apps, and Microsoft Defender for Endpoint
- Adopt a defense-in-depth strategy to reduce the risk and impact of token theft — Microsoft’s “Protecting tokens in Microsoft Entra” documentation is the reference here
Disable weaker authentication methods
For privileged accounts, disable weaker methods entirely — through policy and through per-account enforcement. If FIDO2 or Windows Hello for Business is the standard, remove the fallback to SMS or app-based OTP for those accounts.
⚙️ Best Practice 3: Multi Admin Approval for Sensitive Changes
Multi Admin Approval (MAA) introduces a four-eyes principle for Intune administration. When enabled, changes to protected resources require a second administrator to review and approve before Intune applies them. This is enforced for both admin center actions and actions performed through the Intune APIs.
What MAA can protect today
- Device actions — Wipe, Retire, Delete
- Apps — App deployments (not app protection policies)
- Compliance Policies — Creating, modifying, assigning, and deleting compliance policies
- Configuration Policies — Creating, modifying, assigning, and deleting policies via the Settings Catalog
- Scripts — PowerShell script deployments to Windows devices
- Access Policies — Creating or modifying other MAA policies
- RBAC — Changes to roles, permissions, admin groups, or member assignments
- Tenant Configuration — Managing device categories
Support for compliance and configuration policies was added with the February 2026 update. If you already have MAA in place, verify that access policies for these new profile types have been created — they are not added automatically.
Setting it up
Prerequisites:
- At least two administrator accounts
- A Microsoft Entra ID security group for approvers
- Approver accounts need either an Intune license or membership in an Intune role assignment
- For creating access policies: Intune Administrator role or a custom role with MAA permissions
Step 1 — Create the Approver Group
In Entra ID → Groups → New group, create a security group (e.g., SG-Intune-MAA-Approvers). Add dedicated admin accounts that should serve as approvers. Keep this group small.
Step 2 — Create a Custom Intune Role for Approvers
In Intune admin center → Tenant administration → Roles → Create → Intune role, create a role with only the permissions needed:
- Organization → Read
- Multi Admin Approval → Approval for Multi Admin Approval
Assign this role and set the Admin Groups to your approver security group.
Step 3 — Create Access Policies
Navigate to Intune admin center → Tenant administration → Multi Admin Approval → Access policies → Create.
Each policy covers a single profile type. Start with the most critical ones:
- Device Wipe — the exact action exploited in the March 2026 breach
- Device Retire
- Device Delete
- Scripts — prevents unauthorized script deployment across the device estate
- RBAC — prevents an attacker from escalating their own permissions
- Compliance Policies — prevents unauthorized changes to compliance requirements
- Configuration Policies — protects Settings Catalog-based configurations from unreviewed changes
Microsoft’s guidance is explicit here: start with high-impact changes such as RBAC role management and device wipe, then expand to cover compliance, configuration policies, and broad assignment scopes.
Step 4 — Complete the Approval Flow
After creation, each access policy is itself subject to MAA — a second admin must approve the policy. Sign in with an approver account, navigate to Received requests, and approve. Then finalize with the original account under My requests → Complete.
Operational considerations
No built-in notifications. Intune does not send alerts when new approval requests are created. Build your own notification workflow — a Teams channel, a shared mailbox, or an automated Logic App via Graph API.
Define approver SLAs. Who can approve, within what timeframe, and what happens during off-hours or incidents?
Document a break-glass path. Emergency access procedures must exist for situations where approval cannot wait. These should include explicit post-change review — speed should not erase governance.
Licensing nuance. Both the requesting admin and the approving admin need appropriate licensing. If your admin accounts are unlicensed, ensure the approver group is added to at least one Intune role assignment. Without this, approver group members may be periodically removed.
Request expiration. Requests not acted upon within 30 days expire and must be resubmitted.
🧩 How These Measures Add Up
Each of these controls addresses a different phase of an attack:
Least-privilege RBAC + Scope Tags → limits what a compromised account can reach. Even if an attacker gains access, the blast radius is contained to a specific scope rather than the entire tenant.
Phishing-resistant MFA + Conditional Access + PAWs + Token Protection → makes it significantly harder to compromise a privileged account in the first place, and limits the reuse of stolen credentials or tokens.
Multi Admin Approval → the last gate. Even if an attacker bypasses every preceding control and reaches the Intune console with full privileges, MAA prevents a unilateral destructive action. A second human must approve.
The combination shifts your security model from relying on trusted administrators toward protected administration by design: least-privilege to contain impact, Entra-based controls to verify identity and context, and MAA to govern the changes that matter most.
🎯 Final Thoughts
The March 2026 breach is not an abstract case study. It is a concrete demonstration of what happens when a legitimate management tool operates without layered administrative safeguards.
Intune can push software, enforce policies, and wipe devices across an entire organization. That power exists by design. The controls described in this post — least-privilege RBAC, phishing-resistant authentication, privileged access hygiene, and Multi Admin Approval — ensure that this power cannot be exercised unilaterally.
Microsoft’s own quick-start recommendation is clear: inventory broad role assignments and replace them with least-privilege RBAC roles, enforce Conditional Access with phishing-resistant MFA for all admin scenarios, and place RBAC role management, device wipe, and script deployment behind Multi Admin Approval.
If your Intune environment does not have these controls in place today, the gap between reading about a breach and experiencing one is exactly one compromised account wide.
Start today. Not tomorrow.
Leave a Reply