Stryker: mass device wipe — why immutable, isolated backups are vital

On 11 March 2026, Stryker (US medtech) suffered a destructive attack: Iran‑linked hackers triggered the remote wipe of tens of thousands of devices. Here is the backup architecture that prevents prolonged downtime — and meets DORA.

Key facts

On 11 March 2026, Stryker, one of the world’s largest medical device manufacturers, was hit by a cyberattack attributed to pro‑Iranian hacktivists (“Handala”) who compromised the company’s Microsoft environment and triggered large‑scale remote wipes of employee endpoints and mobiles. Multiple reports indicate extended unavailability of workstations and internal services, with emergency restoration spanning several days. Stryker confirmed it is restoring systems and said connected medical devices were unaffected, with the impact mainly on internal IT and endpoint administration.

• TechCrunch reports that Stryker is “restoring its computers and internal network” after the wipe of “tens of thousands” of devices following the March 11 attack. (TechCrunch, 17 Mar 2026)
• Security press analyses suggest the attackers abused Microsoft Intune/MDM to push mass wipe commands, without sophisticated malware: the organization’s own tooling turned against it. (TechRadar Pro, 17 Mar 2026)
• Shortly after, CISA publicly urged organizations to harden Intune/MDM consoles, signaling repeat risk. (TechCrunch, 19 Mar 2026)

Message to European leadership: a wiper or modern ransomware can destroy hundreds or thousands of endpoints/servers within hours. Without immutable backups and an isolated backup network, recovery becomes slow, uncertain, or impossible.

The applicable legal framework

For EU and Luxembourg financial entities, DORA (Regulation (EU) 2022/2554) sets specific ICT continuity and recovery requirements:

• Article 11 — ICT continuity policy, response and recovery plans: governance, regular testing, continuous improvement. (EUR‑Lex — DORA)
• Article 12 — Backup policies and procedures as well as restoration and recovery procedures, with standby systems to be activated. (EUR‑Lex — DORA, Art. 12)

In Luxembourg, the CSSF operationalized incident classification and reporting via Circular 25/893, with notification obligations and concrete evidence requirements for major incidents. (CSSF — Circular 25/893) While Stryker is outside the financial sector, the principle of verifiable resilience and restoration applies to any NIS 2 entity and is contractually required in many supply chains. For a local sector view, see our DORA Luxembourg page.

The technical solution to deploy

Immutable backups + isolated backup network (often called a “data vault”) form the recovery foundation against wipers and ransomware:

• Immutability: backups are written in append‑only (WORM) mode via locked S3‑compatible objects, appliances or WORM tapes. No deletion/modification is possible during a controlled retention period. This thwarts wiping or encryption of backup copies.
• Network isolation (logical/physical air‑gap): the backup domain (storage + orchestrator) is not reachable from production and requires unidirectional links, dedicated jump accounts, and strong auth outside the prod directory. A compromised Intune/AD must not operate the backup vault.
• Validated restores: periodic tests rebuild a “bubble” environment to verify boot, integrity, and absence of IOCs, then controlled reinjection. Automate these DR drills with versioned runbooks.
• Role segregation and tamper‑proof logs: distinct backup accounts, mandatory MFA, quorum for sensitive ops, and evidence‑grade logging.

This approach fits into a business continuity and disaster recovery plan (BCP/DRP) covering processes, responsibilities, and testing for controlled service restoration.

References:

• ISO/IEC 27001:2022 — Annex A.8.13 (information backup) and A.8.20 (network segregation security).
• NIST CSF 2.0 — PR.DS (Data Security), RC.RP (Recovery Planning), RC.IM (Improvements).
• CIS Controls v8 — Control 11 (Data Recovery) and 12 (Network Infrastructure Management, segmentation).

Key lesson from Stryker: when your admin tooling is turned against you, only copies that are unreachable from production and materializable on demand enable fast recovery, DORA Art. 11–12 evidence, and useful notification (CSSF 25/893).

How Luxgap deploys this

• ISO 27001 governance: our Lead Implementers frame a DORA Art. 12 backup policy, map scopes (data/VM/SaaS), define realistic RTO/RPO, write clean‑room restore procedures and the test plan.
• 24/7 managed SOC: we feed vault logs (immutability, access, locks) into a SIEM to detect deviations (retention tampering, admin addition, out‑of‑window access).
• Fractional CISO/DPO consultants: we orchestrate regulatory alignment (DORA, NIS 2, GDPR Art. 32), the evidence matrix (policies, test reports, SIEM captures) and notification scenarios (CSSF eDesk, ILR for NIS 2 where applicable).

Practically, our method runs through “day 0” workshops (target architecture and policy), “day 30” (immutable MVP + active isolation), and “day 60–90” (documented restore exercise), with audit‑ready checklists and evidence.

Concrete case in Luxembourg or the EU

An investment firm under DORA, operating from Luxembourg and Paris, migrated from a scheduled NAS backup to a dual immutable target (on‑prem S3 WORM object + isolated regional cloud vault), with a dedicated bastion and break‑glass accounts outside AD. Result: during a quarterly exercise, the team rebuilt a “clean” Active Directory in a bubble, re‑injected application backups, and presented to internal audit and the risk committee the restore report (SIEM log, timestamps, integrity hashes) supporting DORA Art. 11–12 compliance and a potential CSSF 25/893 notification.

First concrete steps

1. Map what must be restored: identify 10 critical systems (AD, ERP, email, SaaS backups) and verify they have immutable and unreachable copies from production.
2. Shut the MDM/Intune backdoor: admin access audit (phishing‑resistant MFA, dedicated accounts, SIEM alerts) and rapid decoupling scenarios between prod and vault connectivity.
3. Enable immutability: configure WORM locks with retention and legal hold for “gold” backups, plus a logical air‑gap (pull‑side replication at the vault).
4. Test a clean restore: run a documented clean‑room recovery exercise (screenshots, logs, hashes) and file the report for DORA/NIS 2 audit.
5. Wire to the SOC: send vault and orchestrator logs to the SIEM; create alerts (version deletion, retention reduction, privilege escalation).

Official sources

• Stryker incident — TechCrunch, 17 Mar 2026 ; TechRadar Pro, 17 Mar 2026 ; TechCrunch, 19 Mar 2026
• Regulatory framework — Regulation (EU) 2022/2554 — DORA (Arts. 11–12) ; CSSF — Circular 25/893 (ICT incident notification)

Get in touch to prepare a provable, DORA‑aligned restore exercise.