CISA Got It Partially Right. Here's What They Missed.

CISA published an advisory yesterday on endpoint management hardening tied directly to the March 11 Stryker attack. Read it here: CISA Alert: Endpoint Management System Hardening. The advisory points in the right direction. But if you follow it and stop there, you are still wide open to the exact attack that took down 200,000 Stryker devices. Here is what they got right, what they missed, and what actually stops this.

Multi Admin Approval Is a Speed Bump, Not a Wall

CISA's centerpiece recommendation is Multi Admin Approval for Intune. Require a second admin to approve wipe commands before they execute. Sounds solid. It is not. Not against this threat.

An attacker with Global Admin credentials can create a second account, assign it the approver role, and satisfy their own approval gate in minutes. The control assumes the attacker is constrained to a lower-privilege scope. Against Global Admin, they own the entire tenant. They can modify the Conditional Access policies that govern the approval workflow itself.

That is not a defense. That is a delay of maybe five minutes before the wipe starts anyway. CISA is recommending a lock for a door the attacker already has a key to.

The Architecture That Actually Stops This

The attacker held a credential that looked legitimate to every control plane in the environment. Whether they got there through AiTM phishing to steal a session token with a valid MFA claim, or through VPN compromise and lateral movement to Domain Admin, the outcome was the same. The defenses never fired because nothing looked wrong.

Three things break that chain. All three need to be in place. One or two is not enough.

1. No Standing Global Admin

Zero permanently assigned GA roles. Every activation is Just-in-Time through PIM, time-bound, and requires explicit justification. A stolen credential with no active role assignment cannot execute a destructive action. The attacker has to activate the role first. That is your detection window. If you are not using PIM this way right now, stop reading and go fix it.

2. PIM Activation Requiring Fresh Phishing-Resistant MFA via Authentication Context

Not MFA from eight hours ago. A new challenge at the moment of role activation. An AiTM stolen session token cannot satisfy a fresh FIDO2 challenge because the private key is hardware-bound to the legitimate user's physical device. The attacker gets denied at PIM activation even with a valid session. This is the gap CISA almost identified but never said clearly.

3. FIDO2 Hardware Keys Specifically

Not just "phishing-resistant MFA." FIDO2 is the only method where there is no credential to steal and no token to proxy. The AiTM campaigns that bypassed every other MFA type in 2024 and 2025 do not work against FIDO2. The authenticator is cryptographically bound to the specific domain and the specific physical device. Full stop.

The SOC Failure Nobody Is Talking About

This is the most damning part of the whole story and nobody is talking about it.

Handala's pre-attack playbook is documented. LSASS dumps via comsvcs.dll, registry hive exports through Volume Shadow Copy, ADRecon running against domain controllers. Check Point Research confirmed this is their established MO across multiple prior intrusions. That is not quiet tradecraft. Every one of those actions generates detectable events in any environment where someone is actually watching.

Then the wipe started. Two hundred thousand devices. And no automated response fired.

That means one of two things. Either Stryker had no alerting on bulk Intune wipe commands, which is a fundamental gap in any MDM security baseline. Or the alerts fired and nobody acted. Pick either one. Neither reflects well on whoever was running the watch.

The pre-attack signals and the mass deletion event together paint the same picture. This was not a silent, surgical operation that slipped past a solid defense. The door was open at the identity layer, the pre-attack activity was noisy, and the mass wipe executed without triggering a single automated response. That is a monitoring failure from start to finish. And that is what concerns me most about this entire incident.

You Also Need a Circuit Breaker

CISA's entire advisory is preventive. Nothing in it fires once an attack is already in progress. That is a critical gap.

Five or more device wipes in a fifteen minute window should automatically revoke all active sessions for the triggering account and any accounts that recently activated privileged roles. That kicks the attacker out of the management plane mid-execution. They cannot continue the wipe because every subsequent Intune command requires a re-authenticated session they no longer hold.

If an attacker pre-staged a second approval account, Multi Admin Approval gets bypassed before anyone knows the attack started. A session revocation circuit breaker fires the moment devices start wiping regardless of how clean the approval chain looked. Those are completely different points in the kill chain. Multi Admin Approval is a gate before the attack. The circuit breaker stops active damage in progress. You need both. But only one of them would have mattered on March 11.

Bottom Line

Read the CISA advisory. The RBAC guidance is legitimate. The PIM reference buried at the bottom is the most important line in the whole document, even if they did not lead with it.

But stop there and you are still exposed. The actual answer is no standing privileged roles, PIM with Authentication Context requiring fresh FIDO2 at activation, hardware-bound MFA across every privileged account, behavioral monitoring on Entra sign-in logs watching for anomalous role activation followed by MDM bulk actions, and an automated session revocation capability that fires the moment destructive patterns appear.

What happened at Stryker is not a mystery. The identity layer was compromised, the pre-attack activity was detectable, and the mass wipe executed without a single automated response. That sequence should not be possible in 2026.

That is the architecture that changes the outcome on March 11. Anything less is partial credit.

ThreatHunter.ai published a TLP:AMBER intelligence report on March 6, 2026 documenting an exposed Iranian operational server showing pre-positioning and scanning activity five days before the Stryker wipe. Full IOCs and technical details are available to subscribers. Contact us for access.