No Malware. No Ransomware. No Excuses.

← Back to Writing  ·  Prepared from the InfraGard Wisconsin keynote, May 29, 2026. Every fact below is drawn from public sources, cited at the bottom: Stryker's own SEC 8-K filing, the CISA advisory, the DOJ press release, and public reporting.

Bottom line up front

On March 11, 2026, a Fortune 500 manufacturer had roughly 80,000 of its managed Windows endpoints wiped in a single overnight window. The attacker used no malware, no zero-day, and no software vulnerability. Every preventive control in the standard playbook was working as designed: multifactor authentication, endpoint compliance, audit logging. None of it stopped the wipe.

The attacker operated from inside the trust boundary, with a freshly minted, fully legitimate Global Administrator account, using a button that Microsoft ships in Intune. This is the new normal for cloud-native attacks, and it is the case the rest of this brief is built around.

Three takeaways

• The threat model has shifted. Compliance scorecards and sign-in MFA are no longer sufficient. Attackers are now "living off the cloud control plane," using vendor-supplied administrative tools the way the vendor intended.
• The post-incident guidance is necessary but not sufficient. CISA's March 18 advisory covers three controls. Tracing them against the actual Stryker kill chain reveals two architectural gaps.
• The architecture that closes the gaps is mostly already in your Microsoft license. For a 1,700-person organization, full implementation is a low-five-figure annual program. Dollars per admin per day, rather than a capital project.

What happened at Stryker

Stryker is a Wisconsin-adjacent surgical instrument manufacturer. On the morning of March 11, an Iran-linked group tracked as Handala (also reported as Void Manticore by Check Point) executed the following sequence:

Stage	Action
Initial access	Phished credential on a Windows domain admin account.
Stage 1	Created a new Global Administrator account in Microsoft Entra. Fresh, fully legitimate, freshly minted privilege.
Stage 2	Signed into Microsoft Intune as the new Global Admin and issued the built-in bulk device wipe command.
Impact	80,000 to 200,000 managed devices wiped across 79 countries. 5,000 employees in Cork, Ireland sent home that morning.
Disclosure	Stryker filed an 8-K with the SEC the same day. CEO Kevin Lobo addressed the Q1 financial impact on the earnings call.
Aftermath	DOJ subsequently seized four Handala-affiliated domains and tied the operation to Iran's Ministry of Intelligence and Security.

There was no malware payload, no exploited CVE, and no zero-day. Stryker itself confirmed a malicious file ran commands but was not capable of spreading. The attack was the cloud control plane, used exactly the way the vendor designed it.

Why standard controls failed

Preventive controls in most M365 tenants are calibrated for an older threat model: keep the attacker out of the perimeter. The Stryker attacker did not break the perimeter. The attacker entered as a legitimate user, became a legitimate administrator, and used legitimate administrative verbs.

What was working	Why it didn't matter
Phishing-resistant authentication was deployed for end users.	The attacker held a stolen admin credential, then created a new admin with its own valid MFA. Sign-in succeeded legitimately at every stage.
Intune was deployed and the endpoints were managed.	Intune itself was the weapon. The wipe button is a designed feature.
Audit logging was active. Compliance attestations were passing.	Audit captures the event after the fact. It does not gate the action.

Where the CISA guidance falls short

On March 18, CISA published three recommendations: least privilege, phishing-resistant MFA, and Multi-Admin Approval (MAA) on sensitive Intune actions. The guidance is necessary, and any organization not following it should adopt it immediately. But traced against the actual Stryker kill chain, it has two gaps:

• Role assignment is not a Protected Action. The Stryker attacker's first move was creating a new Global Administrator. Microsoft does not currently let you gate role assignment behind an Authentication Context.
• MAA covers a narrow Intune action set. It does not extend to the broader Entra control plane, where the attacker can simply create or modify the administrator they need before pivoting back to Intune.
• Nothing in the guidance requires hardened admin workstations or step-up authentication at the moment of a high-impact action. Both are necessary to actually close the gap.

The architecture that closes the gap

An operating room is one of the most disciplined environments humans have built. It is secured not by a stronger lock on the front door, but by gating every threshold and every instrument all the way through. Identity architecture works the same way.

OR discipline	Identity architecture analog
Sterile field	Managed, compliant, hardened devices only, enforced through Conditional Access.
Scrubbing in	Phishing-resistant authentication into a Privileged Access Workstation (PAW).
Surgical time-out	Step-up authentication at the moment of a high-impact action, using Authentication Contexts.
Instrument count	Periodic access reviews of who holds what privilege and what has been used.
Crash team	Break-glass and emergency access. Layered, intentional, and rehearsed.

Five pillars

• Tiered administrative accounts. Green for routine reads and helpdesk. Yellow for non-interactive service accounts. Red for the control plane. Inside Green, default every role that can write security posture to PIM-eligible, and make always-on earn its place.
• Phishing-resistant authentication and Authentication Contexts. FIDO2 keys, passkeys, and Windows Hello for Business. SMS, push, and OTP codes are still phishable through attacker-in-the-middle frameworks. Authentication Contexts let you require fresh phishing-resistant MFA at the moment of risk, rather than globally at every sign-in.
• Privileged Access Workstations as a spectrum. From separate admin accounts on a standard endpoint at one end, to dedicated air-gapped hardware at the other. Most organizations should land on a virtualized PAW: Windows 365 Cloud PCs deployed in an isolated network. The right point on the spectrum depends on your threat model, not someone else's reference architecture.
• Protected Actions. Microsoft's mechanism for binding specific high-impact verbs to an Authentication Context, covering Conditional Access policy changes, cross-tenant access changes, named locations, and hard deletes. The Stryker attacker's next move after creating the admin would have been weakening Conditional Access. Protected Actions stops them at that step.
• Continuous Access Evaluation and risk-based access. CAE re-evaluates access in near real time when trust changes: password resets, risk score jumps, policy changes. Risk-based access feeds Risky User and Risky Sign-in signals into Conditional Access. Combined with the compliant device requirement, this is the highest-leverage combination of controls available in the platform today.

What this architecture does not solve

Identity controls limit blast radius. They do not eliminate it. Three honest caveats:

• Detection is not prevention. Even strong preventive architecture assumes some breaches succeed. A SOC layer is required to catch the slow, patient attacker: Sentinel, Defender for Identity, and audit alerting on every Protected Action and PIM activation.
• Workload identities are the parallel attack surface. The same Stryker kill chain runs through a registered application granted RoleManagement.ReadWrite.Directory in Microsoft Graph. App consent governance and application permission reviews are the second program to stand up alongside the user identity program. Most organizations are not running it.
• Post-authentication token theft remains a residual risk. Compliant device enforcement and CAE help. Token Protection, currently in preview, will help more by binding session tokens to the issuing device. Track it, but do not assume it solves the problem yet.

Where the leverage actually is

Across eight years of consulting on Microsoft identity architecture, four controls consistently sit on the table unused. They are the highest-leverage things most organizations can deploy this quarter:

Control	Why it matters
Compliant device requirement	Criminally underused. One of the strongest defenses against session token theft after sign-in. Available in Entra ID P1, which most organizations already have.
Risk-based access + compliant device	Massive force multiplier. Rarely fully implemented. Locked behind Entra ID P2 / E5. This should be foundational and usually isn't. If you are paying for E5 and not using this, you are leaving the most expensive part of the license on the table.
Passwordless and phishing-resistant by default	Microsoft's own admin tier is fully passwordless. For legacy form-auth apps without OAuth or SAML, route through a password vault with SSO to Entra. Stop typing passwords into browsers.
Token Protection (preview)	Next step against session token theft. Limited M365 ecosystem support today; application developers must implement it. Track it. Do not deploy it as a load-bearing control yet.

Recommended action plan

Next 90 days: foundation

• Inventory every administrative account in the tenant and tier them Green, Yellow, or Red.
• Block legacy authentication tenant-wide if it is not already blocked.
• Require phishing-resistant MFA for every account in the Red tier.
• Stand up a Conditional Access policy targeting a new Authentication Context for Protected Actions.
• Map at least one Protected Action to the new Authentication Context. Conditional Access policy update is the recommended starting point.

Next 12 months: full architecture

• Roll out PAW for the Red tier. Select the point on the spectrum that fits the organization's threat model.
• Move every administrative role that is not read-mostly to PIM-eligible. Default to eligible; make always-on earn its place.
• Add the compliant device requirement and risk-based access to every Conditional Access policy that touches sensitive data.
• Stand up a workload identity governance program covering application registrations, service principals, and consent.
• Add detection coverage on every Protected Action and every PIM activation. Route to the SIEM.

The cost story is friendlier than the security press makes it sound. Windows 365 Cloud PCs for a typical administrative team run on the order of dollars per administrator per day. Privileged Identity Management is included in Entra ID P2, which most organizations on Microsoft 365 E5 already own. FIDO2 security keys are around twenty-five dollars each. For a 1,700-person organization, the full program lands in low five figures annually. Most of the components are already paid for. The work is configuration, governance, and discipline, not capital procurement.

The vote you have

Five thousand people in Cork did not get a vote on the morning of March 11. Neither did the 79 countries that went dark. The vote available to executives reading this brief is happening in the next budget cycle, the next architecture review, and the next conversation with the CEO.

Don't wait for your version of March 11 to cast it.

Sources

• Stryker SEC 8-K filing
• CISA Advisory, March 18, 2026
• DOJ press release / FBI seizure, March 19, 2026
• KrebsOnSecurity, March 11, 2026
• BleepingComputer coverage, March 11–19, 2026
• Ars Technica (Dan Goodin)

Hardening baselines referenced in the talk

• OpenIntuneBaseline, community-driven, CIS-aligned Intune hardening. If you do one thing, start here.
• Microsoft, Best practices for securing Microsoft Intune (Microsoft Tech Community, March 14, 2026)
• Microsoft Learn: Authentication Contexts, Protected Actions, Token Protection

---

This is a framework, not a prescription. Adapt it to your risk profile, regulatory obligations, organizational maturity, and existing investments. The shape of the architecture is what matters. The specifics will look different in your tenant. The full, adapted-for-any-organization version of this framework is available as a free template: Zero Trust Identity, Device, and Privileged Access Framework →