News
Apr 2, 2026

CISA Says Harden Intune. Here's What That Means for Your Third Party

On March 11, 2026, a group linked to Iran's Ministry of Intelligence and Security accessed Stryker Corporation's Microsoft environment, obtained Intune administrator privileges, and issued a remote wipe command against the company's managed devices. No malware was deployed. No ransomware was dropped. The attackers used a legitimate enterprise management tool to erase data from tens of thousands of endpoints, including servers, workstations, laptops, and employees' personal phones enrolled through the company portal.

Stryker is a Fortune 500 medical technology company. 56,000 employees. Operations in more than 60 countries. Contracts with the US military for medical equipment used in armed forces hospitals. The attack disrupted ordering, manufacturing, and shipping. Surgeries were delayed. Employees in multiple countries lost access to their devices overnight.

The attackers, operating under the Handala persona, compromised an administrator account and created a new Global Administrator account. From that single point of control, they triggered enterprise-wide wipe commands through Intune's native functionality. The investigation, led by Microsoft DART and Palo Alto Unit 42, found no evidence of traditional malware. This was a living-off-the-land attack executed entirely through the management plane.

Seven days later, on March 18, CISA issued an alert urging all US organizations to harden their endpoint management systems.

What CISA and Microsoft recommend

Microsoft published a hardening guide for Intune on March 14. CISA endorsed it four days later, and expanded the scope to cover endpoint management systems broadly. The guidance centers on three areas.

  • First, least privilege through role-based access control. Organizations should limit who holds Global Administrator and Intune Administrator roles. These are privileged roles with broad permissions that should never be used for daily administrative tasks. Intune's RBAC allows scoping permissions by function, region, and business unit. The recommendation includes adopting time-bound privilege elevation through Microsoft Entra Privileged Identity Management, so that admin access is temporary, approved, and auditable.

  • Second, phishing-resistant authentication and privileged access hygiene. Every privileged Intune action should require strong, policy-verified sign-in. CISA recommends dedicated Conditional Access policies for admin roles, phishing-resistant MFA (hardware tokens, no SMS fallback), compliant-device requirements, and restricted access by location or trusted network. Standing access should be eliminated.

  • Third, Multi Admin Approval. High-impact actions like device wipes, script deployments, and RBAC changes should require a second administrator's approval before execution. This control exists specifically to prevent a single compromised account from triggering fleet-wide destruction, which is exactly what happened at Stryker.

The angle most coverage is missing

Every security team reading this coverage is running the same internal exercise right now: do we have the same gaps? That is the right instinct. But it is only half the picture.

Stryker is a vendor. Thousands of health systems, hospitals, surgical centers, and government medical facilities depend on Stryker's products and supply chain. When the wipe command hit, it took down ordering systems. Manufacturing stopped. Shipments halted. Surgeries were postponed, weeks after the attack.

If Stryker is in your vendor portfolio, their Intune misconfiguration becomes your operational disruption. Their gap in admin controls became your delayed surgeries, your unfulfilled orders, your board-level incident. And you had zero visibility into it.

Palo Alto Unit 42 has documented this specific threat actor's strategy of pursuing supply-chain footholds through IT and service providers to reach downstream victims. The pattern is clear: compromise the vendor, and the damage flows downstream. The question for anyone managing third-party risk is specific. Would you have known that your vendor's Intune environment had overprivileged admin accounts, weak MFA, or no approval gates for destructive actions?

This is where the conversation shifts from "what should Stryker have done" to "what should you be verifying about every critical vendor in your portfolio, continuously."

If Stryker is in your vendor portfolio, this is your risk too.

Palo Alto Unit 42 has documented this specific threat actor's strategy of pursuing supply-chain footholds through IT and service providers to reach downstream victims. The attack on Stryker fits that pattern. The question for any first party managing third-party risk is direct: would you have known that your vendor's Intune environment had overprivileged admin accounts, weak MFA, or no approval gates for destructive actions?

An outside-in security rating would not tell you. External scanning sees domains, certificates, open ports, maybe some DNS configuration issues. It cannot see how a vendor configures RBAC inside their Intune tenant. It cannot verify whether their Global Administrator accounts require phishing-resistant MFA. It cannot check whether a single admin can wipe every device in the organization without a second pair of eyes.

This is the visibility gap that turns a vendor's internal misconfiguration into your operational disruption.

What inside-out monitoring catches

When a third party authorizes inside-out scanning of their Microsoft environment, the monitoring platform can evaluate the actual configuration state across multiple layers. This matters because the Stryker attack was a chain, not a single event.

The chain started with credential theft. Researchers have linked the Handala group to phishing campaigns and infostealer malware targeting US organizations in the days before the attack. If the compromised administrator's endpoint had properly configured protection, the credential theft itself becomes harder to execute.

Zanshin monitors Microsoft Defender for Endpoint alongside Microsoft Intune, both as scan targets in the Security Tools category. For Defender, this means validating that endpoint protection configurations are in place: anti-malware policies active, behavioral detection enabled, coverage across the device fleet. If alerts related to compromises or near misses are being acknowledged in a timely manner. An environment where Defender is misconfigured, inconsistently deployed across endpoints or not actively monitored creates the conditions for credential-stealing malware to operate undetected.

For Intune, the platform checks whether Global Administrator roles are assigned to an excessive number of accounts, or concentrated in a single account with no separation of duties. It verifies whether privileged accounts have MFA enabled, and whether those accounts rely on weaker methods like SMS, which are vulnerable to SIM swapping and interception.

These two layers of verification map directly to the Stryker attack chain. The endpoint protection layer addresses how the initial credentials were likely stolen. The Intune configuration layer addresses how those credentials were escalated into a Global Administrator account capable of wiping every device in the organization.

These checks run daily. Configurations drift. Security policies get relaxed during migrations and never restored. A questionnaire filled out six months ago cannot reflect what the environment looks like today.

Attack chain controls vs. monitoring visibility From credential theft to mass wipe: what each approach can verify Control area Outside-in rating Inside-out scan Endpoint protectionDefender config, anti-malwarePrevents credential theft No visibilityCannot see EDR config Validates Defenderpolicies and coverage Least privilegeRBAC, admin account countLimits blast radius No visibilityCannot see admin roles Validates Global + IntuneAdmin count and scope Phishing-resistant MFAMethod strength, coverageBlocks stolen credentials No visibilityCannot see MFA config Checks MFA on Intune +Global Admin accounts Multi Admin ApprovalDual approval for wipesPrevents single-actor destruction No visibilityCannot see approval gates Rule in developmentComing soon Inside-out covers 3 of 4 control layers today. Outside-in covers zero.From endpoint protection against credential theft to Intune admin hardening.

How Zanshin applies this

Zanshin includes Microsoft Intune in its set of supported scan targets, alongside other security tools like CrowdStrike Falcon Endpoint Security, Microsoft Defender for Endpoint, SentinelOne Singularity Endpoint Security, Bitdefender GravityZone Business Security Enterprise, TrendAI Vision One Endpoint Security, and Sophos Endpoint. The platform's engine runs daily checks against authorized scan targets, evaluating configurations against a ruleset that identifies insecure conditions and generating alerts with severity classification and full lifecycle tracking.

The vendor receives the detailed alert with remediation context. The first party sees the risk signal, the severity, and whether the vendor has acted on it. This is the cooperative model: visibility drives a conversation, and the conversation drives remediation, before an attacker finds the same weakness.

Stryker attack chain vs. inside-out detection layers Configuration gaps at every stage could have been flagged before the wipe DEFENDER / ENDPOINT LAYER Weeks to months before Credential theft via phishingInfostealer or AiTM captures admin creds Defender config validation:anti-malware, behavioral detection INTUNE ADMIN LAYER Months before March 11 Initial access establishedDwell time with admin-level privileges Global + Intune Admin count,MFA presence, RBAC scope Days before March 11 Intune Admin compromisedWeak MFA bypassed or absent Weak MFA on Intune + GlobalAdmin accounts already flagged Hours before wipe New Global Admin createdEscalation from Intune Admin to full control Next scan detects new GlobalAdmin account in environment March 11, 05:00-08:00 UTC Mass device wipe executed~80,000 devices erased in 3 hours Detection at this pointis incident response MFA checks cover both Intune Admin and Global Admin roles.The initial compromise point is already within detection scope. Attack phase Inside-out detection Too late

What this means for your vendor risk program

The Stryker incident will be studied for years as a case where the management plane became the weapon. No malware, no exploit, no zero-day. Just an admin account with too much access, in an environment where a single person could wipe every device in the organization.

If you manage third-party risk for a health system, a bank, an insurer, or any organization in a regulated sector, the lesson is specific. Your vendors use Intune, or tools like it, to manage their endpoints. The security of those configurations directly affects your continuity. A questionnaire asking "do you use MFA?" once a year does not give you the answer you need. Automated, recurring, inside-out validation does.

The CISA advisory is addressed to every US organization. The third-party risk implication is that every vendor in your portfolio should be held to the same standard.

How many of your critical vendors could you verify right now, today, are following these three CISA recommendations?

Most importantly, it's worth keeping in mind this is not just true for Intune. Many other endpoint, network devices, software and configuration management and security solutions could be abused to obtain similarly devastating results. So make sure you identify them all and apply similar limits to dangerous actions on them.

If the answer takes more than a few seconds, that is the gap Zanshin closes. Request a demo to see exactly what inside-out visibility looks like for your vendor portfolio.

FAQ

Intune Risk & Vendor Exposure

What happened in the Stryker incident?
Attackers gained admin access and used Microsoft Intune to remotely wipe thousands of devices without deploying malware.
Why is this a supply chain risk?
When a vendor is compromised, the operational impact flows downstream—affecting your systems, services, and customers.
What does CISA recommend?
Enforce least privilege (RBAC), require phishing-resistant MFA, and implement multi-admin approval for critical actions.
Why can’t external scanning detect this?
Because misconfigurations like admin privileges and MFA policies exist inside the environment, not visible from outside.
How do you reduce this risk?
By continuously validating vendor configurations from the inside out, ensuring controls are enforced in real time.