SECURITY BRIEFING
The Stryker Cyberattack:
What It Was, Why It Happened, and Why Your Organization Is Protected
Executive Summary
On March 11, 2026, Stryker Corporation — a Fortune 500 medical device manufacturer with $25 billion in annual revenue and 56,000 employees — experienced one of the most disruptive cyberattacks in recent corporate history. An Iran-linked group called Handala wiped approximately 80,000 corporate and personal devices across 79 countries in a single morning. No ransomware was deployed. No data was held hostage. No ransom was demanded. This was not a criminal financial attack. It was a deliberate act of destruction, carried out for political reasons — a geopolitical weapon aimed at a company whose business history made it a target.
Understanding that distinction matters, because it shapes both risk assessment and the defensive posture. This briefing explains what happened at Stryker, why it happened, what the U.S. government’s cybersecurity agency recommended in response, and how Tech River’s controls address the specific gaps that made this attack possible.
This Was Not a Typical Cyberattack
Most cyberattacks that make headlines are criminal in nature. Ransomware groups encrypt data and demand payment for its return. Data theft operations exfiltrate sensitive records for financial gain. Both have recovery paths: pay the ransom, negotiate, restore from backup, notify affected parties.
The Stryker attack was fundamentally different in its intent and design.
Pure Destruction as the Goal
Wiper attacks are designed with a single objective: to destroy. There is no negotiation. There is no ransom. There is no path to recovery through payment. Iran has a documented history of deploying wiper attacks as a tool of geopolitical conflict — the 2012 Shamoon attack that destroyed 30,000 computers at Saudi Aramco, the 2014 attack on the Sands Casino, and now Stryker. These attacks are acts of sabotage intended to cause maximum operational disruption and signal strength. Stryker confirmed that no malware or ransomware was involved, and that the goal was erasure.
Rooted in World Events, Not Corporate Vulnerability
The group that executed the attack, Handala, is assessed by multiple intelligence and cybersecurity organizations — including Palo Alto Networks Unit 42, IBM X-Force, and Sophos — as a front for Iran’s Ministry of Intelligence and Security. The attack was publicly declared as retaliation for a US military strike on an Iranian school. Stryker was selected specifically because of its business profile:
- Stryker acquired OrthoSpace, an Israeli medical technology company, in 2019. Handala explicitly called Stryker a “Zionist-rooted corporation” in their manifesto.
- Stryker holds a $450 million US Department of Defense contract for medical devices.
- These two factors — Israeli business ties and US military contracts — placed Stryker squarely within Handala’s documented target criteria.
The attack was not triggered by a security failure. It was triggered by business decisions made years before. The security failures at Stryker determined how devastating the attack could be — not whether it would happen.
How the Attack Was Executed
Knowing this attack was politically motivated does not diminish the importance of understanding how it worked. The techniques Handala used are not unique to nation-state actors. The same methods — credential theft, privilege escalation, and abuse of legitimate management tools — are used by cybercriminals every day. The difference with Stryker was the intent: destruction rather than ransom.
Phase 1:
Initial Access and Long Dwell Time
Stryker disclosed a separate breach in December 2024 — more than three months before the March 11 wipe. This suggests the attackers spent an extended period inside the environment, moving quietly, escalating access, and positioning for a destructive strike. Threat intelligence researchers identified 278 sets of compromised Stryker credentials between October 2025 and March 2026, with activity concentrated in the weeks immediately before the attack. The likely initial access method was credential theft, consistent with phishing or infostealer malware harvesting login credentials from regular employee accounts.
Phase 2:
Privilege Escalation to Global Administrator
From an initial foothold, the attackers navigated Stryker’s Microsoft Entra ID environment and compromised or created a Global Administrator account. KrebsOnSecurity reported, based on a source familiar with the incident, that the attackers created a new Global Administrator account after compromising an existing administrator account. A Global Administrator holds unrestricted control over a Microsoft 365 environment — able to manage users, modify policies, and issue commands to every connected device.
Phase 3:
The Wipe
With Global Administrator access, the attackers used Microsoft Intune’s built-in Remote Wipe feature to issue a factory reset command to all enrolled devices simultaneously. Intune is a legitimate endpoint management tool used by IT teams to enforce security policies and manage devices. The attackers used it as a weapon. Every command was authenticated and authorized from the platform’s perspective. No malware was deployed. No endpoint security agent flagged the activity. The platform did exactly what it was designed to do — for the wrong user.
Devices wiped included corporate laptops, corporate phones, and personal devices employees had enrolled in Stryker’s bring-your-own-device program. Employees lost personal photos, eSIM configurations, and banking authenticator apps. Manufacturing halted. Surgical supply shipments stopped. Some hospital procedures were delayed.
What the Experts Are Recommending
Following the Stryker attack, both CISA (the US Cybersecurity and Infrastructure Security Agency) and Microsoft published formal guidance on the controls that would have mitigated this attack. CISA noted it worked directly with both Microsoft and Stryker in developing this guidance. The following table presents the recommended controls drawn from CISA’s March 18, 2026 advisory, Microsoft’s hardening guidance, and broader security industry consensus — not from any single vendor’s marketing.
| Recommended Control | Stryker Gap | Tech River Posture |
|---|---|---|
| IDENTITY & ACCESS MANAGEMENT | ||
| Just-in-time admin access — no standing privileged roles (Microsoft PIM / equivalent) | Not confirmed. Attackers appear to have had persistent Global Admin access once credentials were compromised. | Privileged admin accounts hold no roles and are disabled when not in active use. Elevation requires explicit activation with MFA at each session. |
| Phishing-resistant MFA for all admin accounts (FIDO2 / passkeys — not SMS or push notification) | Standard push-based MFA only. Push-based MFA is bypassable via adversary-in-the-middle phishing. Not sufficient for privileged accounts. | Phishing-resistant MFA deployment underway for privileged accounts. Current architecture requires MFA at multiple points; admin accounts have no email mailboxes (see below). |
| Admin account isolation — no email mailboxes on privileged accounts | Admin accounts had associated mailboxes, making them directly targetable by phishing. | Privileged admin accounts have no associated email mailboxes and are disabled when not in use. Direct phishing of these accounts is not possible. |
| Least-privilege RBAC — admin roles scoped to minimum permissions required; wipe/destroy rights restricted separately | Global Admin accounts held full destructive capabilities with no additional authorization required for bulk actions. | Admin roles are scoped to operational need. Destructive capabilities are not assigned to day-to-day operational roles. |
| DETECTION & MONITORING | ||
| Identity Threat Detection & Response (ITDR) — continuous monitoring of admin behavior, new GA account creation, and anomalous authentication | Not confirmed in place. Attackers had months of undetected dwell time. A December 2024 breach preceded the March 2026 wipe with no apparent detection. | ITDR monitoring is deployed across managed environments. Alerting is configured for new Global Administrator account creation — one of the exact precursor signals in the Stryker attack. |
| Regular auditing of Global Admin and privileged role assignments — catch unauthorized accounts before they are used | Not confirmed. An unauthorized Global Administrator account was reportedly created and used without detection. | Privileged role assignments are audited on a regular cadence. Unrecognized accounts in privileged roles are treated as an incident. |
| Alerting on bulk or anomalous device management actions (e.g., more than a threshold number of wipes in a short window) | Not in place. The wipe proceeded across 80,000 devices with no automated detection or interruption. | Anomalous bulk device actions trigger alerts. Destructive operations at scale are treated as an incident requiring investigation. |
| SIEM / centralized security event monitoring | Not confirmed as a meaningful control in this incident. | Centralized log aggregation and security event monitoring across managed environments. |
| Endpoint Detection & Response (EDR) | Not confirmed. Standard EDR would not have detected this attack — no malware was deployed — but it remains a baseline control for other threat classes. | EDR deployed across managed environments. Acknowledged limitation: EDR cannot detect living-off-the-land attacks via legitimate admin consoles. |
| AUTHORIZATION & APPROVAL CONTROLS | ||
| Multi-Admin Approval (MAA) for destructive Intune actions — CISA-recommended; requires a second admin to approve bulk wipes, script deployments, and RBAC changes | Not enabled. This was the single missing control that would have blocked the bulk wipe even after credentials were compromised. | Not currently enabled. Our position: the identity monitoring and JIT access controls above are designed to detect and prevent a compromised credential from operating undetected. We are evaluating MAA as CISA guidance evolves post-Stryker. |
| Conditional Access policies — enforce MFA, compliant device requirements, and sign-in risk controls for admin sessions | Insufficient. Standard MFA without phishing-resistant enforcement allowed credential bypass. | Conditional Access is configured across managed environments. Admin sessions enforce MFA. Ongoing refinement to align with post-Stryker CISA and Microsoft guidance. |
| EMAIL SECURITY & INITIAL ACCESS PREVENTION | ||
| Advanced email security beyond platform defaults — phishing is the leading credential theft vector | Microsoft-native email security only. Independent analysis found Microsoft's built-in filters allowed significantly more phishing emails into inboxes compared to dedicated third-party solutions. | Dedicated third-party email security deployed as a second layer on top of Microsoft's native filtering. Independent analysis of 300M+ emails found this approach reduces inbox phishing penetration by approximately 99% compared to Microsoft Defender alone. |
| DEVICE MANAGEMENT SCOPE | ||
| Avoid full MDM enrollment of personal BYOD devices — personal devices in full MDM scope are subject to corporate wipe commands | All BYOD devices enrolled in full MDM. Personal phones were factory reset, destroying personal photos, eSIMs, and banking authenticator apps. | No full MDM enrollment of personal devices in managed environments. Personal device scope is not present. |
| RESILIENCE & RECOVERY | ||
| Offline / air-gapped break-glass accounts with protected credentials — ensure recovery path if primary access is compromised | Not confirmed. Recovery was significantly impaired across the organization. | Break-glass accounts are maintained with credentials stored offline. Any use of a break-glass account triggers immediate alerts. |
| Offline or isolated backups not accessible through the same admin plane being targeted | Not an effective control in this incident. | Backup integrity and isolation from the primary admin control plane is part of the recovery architecture. |
Table sources: CISA Advisory AA26-077A (March 18, 2026); Microsoft Best Practices for Securing Microsoft Intune (March 14, 2026); Palo Alto Networks Unit 42; KrebsOnSecurity; Lumos Security;
How Our Security Architecture Addresses These Controls
The table above is based on authoritative post-incident guidance. This section explains how the controls translate to the protection in your environment.
Just-in-Time Access and Admin Account Isolation
The single biggest architectural difference between Stryker’s posture and how Tech River manages privileged access is that our admin accounts are disabled and hold no roles until the moment they are needed. An engineer authenticates through our privileged access management platform — requiring MFA — activates the specific customer account, authenticates to the customer tenant again with MFA, and when the session ends, the account’s roles are removed and the account is disabled.
Privileged admin accounts have no associated email mailboxes. You cannot phish an account that has no inbox. You cannot use a stolen session cookie to re-authenticate into an account that is disabled and has no standing access. This architectural separation between privileged access and regular user accounts is the most direct mitigation against the credential compromise that enabled the Stryker attack.
Phishing and the Executive Account Question
It is worth being direct about phishing: it is possible in any organization. A sophisticated phishing email could reach and successfully deceive anyone, including senior leadership. We want to be honest about that rather than imply otherwise.
However, in a properly segmented environment, a successful phish against an executive or any regular user account does not lead to a Stryker-level outcome. Regular user accounts — including executive accounts — do not have access to Microsoft Entra ID administrative functions or the ability to issue device management commands. Gaining control of a user account, even a CEO-level account, gives an attacker access to email and files. It does not give them the ability to wipe every device in the organization. That capability is restricted to privileged admin accounts, which are governed by a separate access architecture with no mailboxes and no standing access.
We also deploy advanced email security as a second filtering layer on top of Microsoft’s built-in defenses. In independent analysis of more than 300 million emails, this approach reduced phishing emails reaching the inbox by approximately 99% compared to Microsoft’s native filtering alone.
ITDR: Detecting the Precursors
One of the most important lessons from the Stryker attack is dwell time. The attackers were present inside Stryker’s environment for months before the March 11 wipe. In that time, they escalated privileges, created a new Global Administrator account, and positioned for destruction — all without being detected.
Identity Threat Detection and Response (ITDR) monitors the behaviors that indicate this kind of activity is underway. Specifically, our monitoring includes alerting on the creation of new Global Administrator accounts — which is exactly the precursor activity that occurred at Stryker before the wipe. Unauthorized admin account creation is treated as an incident requiring immediate investigation, not a routine event.
We also conduct regular audits of privileged role assignments. If an account holds Global Administrator or equivalent rights and cannot be attributed to a known, authorized assignment, that is an incident. The goal is to eliminate the condition where an attacker-created admin account can sit undetected for weeks or months.
The MAA Acknowledged Gap
Summary
The Stryker attack was a geopolitical act of destruction, not a criminal financial attack. There was no ransom, no negotiation, no recovery path through payment. It was designed to cause maximum operational damage to a company selected based on its business history — Israeli ties and US defense contracts — in the context of a live military conflict. Understanding that is important for calibrating risk.
At the same time, the techniques Handala used — credential theft, long dwell time, privilege escalation, and abuse of legitimate management tools — are the same techniques used by criminal groups every day. The security controls that would have stopped this attack are the same controls that defend against a wide range of threats.
The controls that matter most for this attack class — just-in-time privileged access, disabled admin accounts with no mailboxes, ITDR monitoring with new Global Admin creation alerting, regular privileged role audits, advanced email filtering, and no personal device MDM exposure — are in place across the environments we manage. The one acknowledged gap (MAA) is addressed through compensating controls and is under active evaluation.
Stryker was a Fortune 500 company with significantly greater security spending than most organizations. The gap was not budget — it was architecture.
More to Explore
More insights and resources worth checking out
More insights and resources worth checking out.




















