Microsoft Intune Security: Hardening Privileged Access

Updated March 2026: Based on the Stryker incident and Microsoft's official hardening guidance published 13 March 2026.

Attackers do not need malware to wipe your entire device fleet. They need one compromised administrator account and access to your endpoint management console. That is what happened at Stryker, a $25 billion medical device company with 56,000 employees, when an Iran-linked group called Handala executed a mass wipe against its Microsoft environment in March 2026. No malware. No CVE. No zero-day.

The attack erased devices across offices in dozens of countries. Handala claimed more than 200,000 systems wiped, though that figure comes from the attackers themselves and Stryker has not independently confirmed device counts. What Stryker did confirm in its SEC filing: significant disruption to its Microsoft environment and no ransomware or malware detected.

The wipe command came from inside the console.

Stay ahead of attacks like this. Subscribe to CyberDesserts for practical security guidance, no vendor spin.

How Attackers Turn Your MDM Console Into a Weapon

Microsoft Intune is designed to give IT teams a single point of control over every enrolled device: deploy apps, enforce policies, and if a device is lost or stolen, wipe it remotely. That last feature is exactly what Handala triggered at Stryker. Security researcher Kevin Beaumont identified the attack vector, and Rafe Pilling, Director of Threat Intelligence at Sophos, confirmed it: the attackers obtained access to the Intune management console and issued a remote wipe command across enrolled devices.

There was no exotic exploit involved. The attack surface was the admin dashboard, reachable from any browser, with the credentials to open it.

This is what the security community calls living-off-the-land. The attacker uses the tools the organisation already has in place, legitimately, with full permissions, to cause maximum damage. The endpoint operating systems did exactly what they were built to do.

When a trusted MDM server sends a wipe command, the device executes it without question.

Intune worked as designed. The failure was in who had the keys.

This risk is not unique to Intune: any cloud-managed endpoint platform presents the same profile. Centralised management is a force multiplier for IT teams.

It is also a force multiplier for anyone who compromises a privileged account inside it.

Why Standard MFA Is Not Enough for Highly Privileged Accounts

This is the part most organisations get wrong. Many assume that enabling multi-factor authentication on administrator accounts closes the credential-theft problem. It does not. Not if the MFA method can be intercepted in transit.

Adversary-in-the-middle (AiTM) phishing proxies do not steal passwords. They steal authenticated session tokens. The attacker sits between the user and the legitimate login page, passing credentials through in real time and capturing the session token after MFA has already been satisfied.

The MFA prompt fires. The admin approves it on their phone. The attacker has a valid session.

AiTM is one route to a stolen session token. Infostealer malware is another: rather than intercepting the token in transit, infostealers harvest browser session cookies from the device after authentication has already completed.

Different delivery mechanism, same outcome. The attacker holds a valid session and MFA has already fired. For a deeper look at how that credential theft supply chain works, see Infostealers in 2026: How They Work and How to Stop Them.

I have been saying this in customer conversations for years: least privilege and authentication strength are two different problems. Scoping roles correctly does not protect you if the authentication on those accounts is weak. App-based MFA is not sufficient for accounts that carry destructive potential.

A Global Admin can wipe devices, delete tenants, and override every security control in your environment. That level of access demands a higher bar.

FIDO2 security keys and Windows Hello for Business work differently. These methods bind the credential cryptographically to the specific login origin. A credential-relay proxy cannot intercept a FIDO2 response because the response is tied to the legitimate domain.

If an attacker tries to relay it through a phishing site, the authentication simply fails.

That origin-binding is what makes these methods phishing-resistant rather than merely phishing-deterrent. Microsoft's hardening guidance, published in direct response to the Stryker incident on 13 March 2026, is explicit: every privileged Intune action, including device wipe, script deployment, and role management, should require phishing-resistant authentication. Not just any MFA method.

The Controls That Limit the Blast Radius

These controls are not a one-time hardening exercise. From a continuous threat exposure management perspective, over-permissioned accounts and misconfigured admin portals are exposures in the same way unpatched vulnerabilities are. The difference is that most organisations are not treating them that way.

Microsoft's post-incident guidance groups the mitigations into three areas. Here is what each means in practice, with the controls that would have changed the outcome ranked by impact.

Least-privilege RBAC with scope tags. Global Administrator is a blanket entitlement and most IT environments run with too many accounts holding it permanently. The fix is to inventory who holds Global Admin and Intune Administrator roles, remove assignments that do not map to a named job function, and replace them with scoped roles such as Help Desk Operator or Endpoint Security Manager. Scope tags constrain which devices an admin can touch. A regional admin should not be able to wipe devices in a country they have nothing to do with.

Stale assignments compound this problem. Leavers, contractors, and accounts created for a one-off migration project that nobody removed are a persistent reality in most environments. A departing employee's Global Admin account sitting active for 30 days after their last day is an exposure, not an edge case. Entra Access Reviews exist precisely to catch these.

Service principals and managed identities are the accounts most organisations forget to include in this review. They can hold equally destructive permissions and are rarely subject to the same scrutiny as human admin accounts. Any privileged access review that covers only human accounts is incomplete.

Privileged Identity Management (PIM). PIM eliminates standing privilege. Instead of an account permanently holding Global Admin, it holds an eligible assignment and must request elevation with justification and approval before the role activates. Activation windows of one to four hours are standard. Even if an attacker steals a session token from a PIM-enabled account, that token does not carry standing admin rights. PIM requires Entra ID P2, included in M365 E5.

Multi-Admin Approval for device wipe. This is the control that most directly would have changed the Stryker outcome. Multi-Admin Approval (MAA) requires a second authorised admin to approve high-impact Intune actions before they execute, including remote wipe. It applies to both the admin centre and the Intune API. MAA is available on any Microsoft Intune Plan 1 licence at no additional cost. There is no budget reason not to enable it.

Conditional Access for admin portals. The Intune admin console should not be reachable from an unmanaged laptop at an arbitrary location. Conditional Access policies can require that admin portal access comes from a compliant, Entra-joined device, from a trusted network or named location, and with phishing-resistant authentication. If your admin console is reachable from an unknown device in an unexpected region, that is either a deliberate choice or something that was never configured. Neither is acceptable, and neither is inevitable.

Privileged Access Workstations (PAWs). High-privilege actions should happen from dedicated, hardened devices not used for general browsing or email. The separation limits the blast radius if an admin's daily-use machine is compromised. This control was largely absent from community discussion after the incident. It belongs in every hardening conversation.

Detection rules for mass wipe attempts. Controls can fail. Detection is the backstop. Microsoft Sentinel KQL rules can alert on five or more device wipes within a 15-minute window, flag first-time wipe operators, and correlate unusual admin activity with destructive actions. If a compromised account does initiate a wipe, an alert fast enough to intervene is the difference between losing a handful of devices and losing the fleet.

That detection capability is also what CTEM's validation phase is designed to produce: evidence that your controls hold, not an assumption that they do. For a full breakdown of how continuous exposure management works in practice, see NIST-Aligned CTEM: Moving Beyond Point-in-Time Scanning.

The target state is straightforward: zero standing Global Admin assignments, all elevation through PIM with time-bound activation and justification, and MAA enabled on every destructive Intune action. If your environment matches that description, you are well positioned.

Writing detection rules for admin portal activity is also exactly the kind of hands-on skill that separates candidates in SOC interviews. If you are building towards a blue team role, see What SOC Hiring Managers Test For In Interviews and what you can bring to the table.

What Your BYOD Policy Should Tell Employees

The Stryker incident had an operational impact that most coverage underplays. Employees had enrolled their personal iPhones under the company's bring-your-own-device policy. When the wipe command fired, it did not just remove the work profile.

It factory-reset the entire device.

Personal photos gone. eSIMs deleted. Employees locked out of personal banking because they used their phone for two-factor authentication, and that happened to Stryker employees in Australia, Ireland, and elsewhere.

The distinction matters technically, and it should be in every BYOD policy. On iOS, a full Intune remote wipe resets the entire device including personal data. On Android, wiping the work profile typically leaves personal data intact.

Both facts should appear in your enrolment documentation, in plain language, before employees grant management access to their personal device. If that conversation is not happening at enrolment in your organisation, it needs to be.

What to Check This Week

These are audits and configuration changes that take hours, not months.

1. Audit standing admin role assignments. Pull a report of every account holding Global Administrator, Intune Administrator, Cloud Device Administrator, and Help Desk Operator. Ask whether each one needs that role permanently. Most will not.

2. Enable Multi-Admin Approval for device wipe. Navigate to Tenant Administration in the Intune admin centre and enable MAA for remote wipe and script deployment. This is available on your existing licence. It is the highest-value free control available right now.

3. Check your MFA methods for admin accounts. If privileged accounts are authenticating with Microsoft Authenticator TOTP codes or SMS, that is insufficient for accounts with high permissions. Begin the migration to FIDO2 keys or Windows Hello for Business.

4. Review your BYOD enrolment policy. Confirm that employees understand what a remote wipe means for their personal device on iOS versus Android. Update enrolment documentation if it does not address this clearly.

5. Verify Conditional Access scope on admin portals. Confirm that intune.microsoft.com is not accessible from unmanaged devices or unexpected geographic locations. If you do not have a named location or device compliance policy on admin portals, create one this week.

Summary

The Stryker attack did not exploit a flaw in Microsoft's code. It exploited a gap in how organisations configure and govern administrative access to tools that can touch every device in the fleet.

A legitimate remote wipe command issued from a compromised admin account is the technique. It works against any MDM platform. The risk is not Intune-specific, but the hardening controls are Microsoft-specific and most organisations running M365 already own them.

Phishing-resistant MFA, just-in-time privilege, and Multi-Admin Approval for destructive actions are all in Microsoft's existing stack. For most enterprise organisations, the controls exist. The question is whether they are switched on.

Reviewing privileged access before an incident is the cheapest security investment you will ever make. Go check yours.

Microsoft gives you two ways to do it. Microsoft Secure Score is free for every M365 tenant and surfaces over-permissioned accounts and role hygiene recommendations immediately at security.microsoft.com. Microsoft Entra Access Reviews, available with Entra ID P2 (M365 E5), lets you schedule recurring attestation of privileged role assignments through PIM so that access is justified on a cadence, not just reviewed once and forgotten.

Last updated: March 2026

Practical security guidance lands in your inbox weekly. No vendor pitches, no press releases. Just analysis from someone who has spent 20+ years on the vendor side watching how these decisions get made.

References and Sources

1. Cybersecurity Dive. (2026, March). Stryker attack raises concerns about role of device management tool. Cybersecurity Dive. Reports Intune weaponisation and scope of enrolled device impact.
2. SecurityWeek. (2026, March). Iran-Linked Hacker Attack on Stryker Disrupted Manufacturing and Shipping. SecurityWeek. Confirms living-off-the-land technique; Stryker SEC filing details; 200,000 device claim from Handala.
3. Krebs on Security. (2026, March). Iran-Backed Hackers Claim Wiper Attack on Medtech Firm Stryker. Krebs on Security. Primary source for Intune remote wipe mechanism; no malware confirmed.
4. NBC News. (2026, March). Iran appears to have conducted a significant cyberattack against a U.S. company. NBC News. Rafe Pilling (Sophos) statement on MDM console access and remote wipe trigger.
5. HIPAA Journal. (2026, March). Iran Linked Hacking Group Wipes Data of U.S. Medical Device Manufacturer. HIPAA Journal. Kevin Beaumont attribution for Intune vector identification; iOS BYOD full wipe impact documented.
6. Kim Zetter / Zetter Zero Day. (2026, March). Iranian Hacktivists Strike Medical Device Maker Stryker in "Severe" Attack that Wiped Systems. Employee accounts of BYOD impact including eSIM deletion and loss of personal 2FA access.
7. Microsoft Intune Customer Success. (2026, 13 March). Best practices for securing Microsoft Intune. Microsoft Tech Community. Official hardening guidance covering RBAC, phishing-resistant MFA, PIM, and Multi-Admin Approval.
8. Industrial Cyber. (2026, March). Suspected Iran-linked cyberattack hits medical technology giant Stryker. Industrial Cyber. Optiv gTIC analyst statement on admin-level credential acquisition and Handala TTPs.