How the "Stryker" Intune Wipe Incident Highlights a Critical Gap in Endpoint Control

Introduction

By now, you all have either read or heard about the recent "Stryker" incident. While all the details are not fully clear, it appears that attackers leveraged Microsoft Intune to issue large-scale device wipes. Not a good day for the IT staff, to say the least. This is a case study in how control-plane weaknesses can cascade into operational catastrophe, not an attack on them or the UEM solution they chose. While attribution discussions point toward Iranian threat actors, the more instructive takeaway is architectural. There appeared to be a lack of layered safeguards against destructive actions.

This incident made me wonder how this would have affected an environment built on Omnissa Workspace ONE. My conclusion is that several native controls would have materially reduced the blast radius or prevented the event entirely.

In the rest of this article, I'll make my case. This is not a vendor marketing argument. It is a control-plane design discussion.

The core failure: Unverified, high-impact actions

At the center of the incident was the ability to issue mass device wipe commands without sufficient friction or validation. In modern UEM architectures, destructive commands must be treated like privileged financial transactions, not routine API calls.

What "I think" was missing

• No Restricted Console Actions without a PIN requirement.
• Insufficient role segmentation (RBAC)
• No rate limiting or bulk-action constraints
• Lack of change detection and alerting on policy modifications
• No structural segmentation of the environment itself

So, with all that in mind, here are seven technologies in Omnissa Workspace One that would have helped avoid this kind of catastrophic hack. 

1. Step-up verification: Adding friction before destructive actions

One of the things Workspace ONE UEM does well is add a moment of friction before an admin can do something truly disruptive.

With Restricted Console Actions, you can require a PIN (or similar verification) before executing high-risk commands like:

• enterprise wipe
• device wipe
• large-scale profile removal

It's a small step, but it changes the dynamic quite a bit.

Why this actually matters

If someone compromises an admin account, they still don't get immediate free rein.

They can't just start wiping devices at scale. They hit a second checkpoint.

That extra step:

• slows them down
• forces interaction instead of automation
• creates a clear signal if something isn't right

In a scenario like Stryker

Even something this simple could have made a difference.

It could have:

• disrupted or completely blocked automated wipe activity
• raised red flags through repeated failed PIN attempts
• bought valuable time for someone to notice and respond

It's not a flashy control, but it's the kind that quietly reduces blast radius when things go wrong.

2. Managed device wipe protection

Workspace ONE includes Managed Device Wipe Protection, which enforces policy-level constraints on wipe operations.

Key protections

• Restrict wipes to specific admin roles
• Require justification or approval workflows
• Prevent wipes on:
  • Recently enrolled devices
  • Devices outside the compliance scope
  • Devices not meeting predefined conditions

Impact

Instead of a single compromised account wiping thousands of devices:

• Wipes would be contextually evaluated
• Non-compliant or suspicious wipe attempts would be blocked outright

Managed Device Wipe Protection in Workspace ONE UEM is basically a guardrail against mass or accidental wipes.

How it works:

• You configure a wipe threshold: a minimum number of devices wiped within a defined time window. Omnissa describes it as protection against excessive device wipes and enterprise wipes by setting a wipe threshold in UEM.
• When that threshold is hit, UEM puts the remaining queued wipes on a temporary hold instead of continuing blindly. The Device List View doc says Wipe Protection places a temporary hold on the remaining devices to be wiped, and an admin must unlock Wipe Protection before those queued devices continue.
• The intent is to slow down a potentially dangerous bulk wipe event so an administrator can verify it before the rest of the fleet is affected.

So in plain English:

1. An admin starts wiping devices.
2. UEM counts how many wipes are happening in the configured period.
3. If the number crosses the threshold, UEM pauses the rest.
4. An admin has to explicitly unlock it for the remaining wipes to proceed.

Okay, so you say, what happens if an admin/hacker overrides it and turns it off:

If Wipe Protection is disabled, that safety brake is gone. Omnissa's device-action documentation states that if wipe protection is turned off on the device, the issued command immediately performs an enterprise wipe and removes the device representation in the console. That means there is no threshold-triggered pause for review. 

Operationally, that means:

• a mistaken bulk wipe can continue immediately,
• a malicious admin can wipe more devices faster,
• you lose the forced interruption point that would otherwise require human review before the remaining devices are wiped.

The real risk of turning it off is not that one device becomes more wipeable than before. The bigger issue is that you remove the rate limiter / circuit breaker behavior designed to prevent large-scale damage. 

If someone attempts to disable this feature, I would have an Intelligence automation that audits events in UEM and notifies IT via ServiceNow, Teams/Slack, Email, etc. Basically, send out the bat signal.

3. Managed device wipe protection: A built-in safety brake

Workspace ONE UEM has something called Managed Device Wipe Protection, and the simplest way to think about it is this:

It's a guardrail against wiping too many devices too quickly.

It doesn't try to decide whether a wipe is valid. Instead, it controls how fast large-scale wipes can happen.

How it actually works

You configure a threshold, for example:

• X number of wipes
• within a defined time window

Once that threshold is hit, UEM steps in.

Instead of continuing to process wipes, it pauses the remaining devices. At that point, an admin has to explicitly unlock Wipe Protection before anything else continues.

In plain terms:

• an admin starts a bulk wipe
• UEM tracks how many devices are being wiped
• once the threshold is exceeded, everything else is put on hold
• someone has to step in and say, "yes, continue"

The goal is simple: slow things down before damage spreads.

Why this matters

Without this control, a bulk wipe just keeps going.

With it, there's a built-in interruption point:

• it breaks automation
• it forces human review
• it gives someone a chance to catch a mistake or something malicious

It's essentially a circuit breaker for destructive actions.

Okay, so what if it's disabled?

If Wipe Protection is turned off, that safety brake disappears.

Now:

• wipes continue without interruption
• there's no threshold-based pause
• large-scale actions can complete as fast as they're issued

That changes the risk profile significantly.

A mistake or compromised admin account can move much faster, and there's no forced checkpoint to stop it.

The real issue isn't a single wipe. It's losing that rate-limiting control that prevents widespread impact.

What I would do operationally

If someone disables Wipe Protection, that should never go unnoticed.

At minimum, I'd set up an alert using Workspace ONE Intelligence:

• monitor UEM audit / settings events
• detect when Wipe Protection is modified or disabled
• notify immediately via Slack, ServiceNow, email, or similar

Basically, this is one of those "drop everything and look" signals.

Because if that control goes away, your last built-in safeguard against mass device wipes just disappeared.

4. Organizational groups: Built-in blast radius control

One of the biggest differences with Workspace ONE UEM isn't a specific feature, it's how the platform is structured.

At its core, UEM is built around Organizational Groups (OGs), which form a hierarchy. Think:

• Global → Customer → Container → Sub-Container

Everything hangs off that structure:

• policies
• profiles
• applications
• and importantly, admin permissions

Access isn't just role-based. It's also scoped to where you are in the hierarchy.

Why this matters

In practice, this gives you a natural way to contain impact.

If an admin is scoped to a specific OG:

• they typically only see devices in that part of the hierarchy
• their actions are limited to that scope
• bulk actions like wipes are constrained to what they can actually access

So even if something goes wrong, whether it's a mistake or a compromised account, the damage is often limited to that slice of the environment.

It's not perfect isolation, but it's a meaningful layer of containment.

Important nuance

This only works if you design it that way.

If you give an admin broad permissions at a high-level OG, they can still impact a large portion, or all, of the environment.

So the model gives you the tools for containment, but you still have to implement least privilege properly.

Comparing that to Intune

Microsoft Intune takes a different approach.

It operates more like a single global tenant, where:

• devices live in one shared namespace
• segmentation is done through groups and administrative scoping
• access control is primarily policy-driven

That doesn't mean it's insecure. It just means the boundaries are logical, not inherently tied to a hierarchical structure like OGs.

Where the risk shows up

In either platform, things can go sideways if:

• RBAC is too broad
• or a privileged account is compromised

But the difference is how impact spreads.

With a well-designed OG structure:

• actions are naturally limited by scope

In a flatter model:

• scope is entirely dependent on how well groups and roles are defined

The real takeaway

This isn't about one platform being "secure" and the other not.

It's about how blast radius is controlled.

Workspace ONE gives you a structural way to segment your environment.
Intune relies more on how you configure identity, groups, and policy.

Under normal conditions, both can be secure.
Under adversarial conditions, how those boundaries are enforced starts to matter a lot more.

5. Bulk management limits: Putting guardrails on scale

One of the quieter but important controls in Workspace ONE UEM is how it handles bulk actions.

You can configure limits on how many devices can be affected by certain high-impact commands, like wipes or resets.

So instead of allowing someone to act on thousands of devices in a single operation, you can cap the size of those actions.

What this actually does

At a practical level, this means:

• large destructive actions can be restricted or blocked if they exceed a defined limit
• admins may need to break actions into smaller batches
• it becomes harder to execute massive changes all at once

It's not a workflow or approval system. It's more of a hard limit on scale.

Why this matters

In incidents like Stryker, speed and scale are what make the damage so severe.

The combination of:

• fast execution
• simultaneous actions
• large scope

is what turns a mistake or compromise into a major outage.

Bulk limits directly target that.

They don't prevent a wipe entirely, but they:

• slow it down
• reduce how much can happen at once
• make large-scale activity more visible and easier to catch

What changes in practice

Instead of a single command impacting thousands of devices:

• the action may be blocked outright if it exceeds limits
• or it has to be done in smaller chunks over time

That shift matters.

You move from:

• "everything happens at once"

to:

• "this is taking longer than expected, something's off"

And that gap is where detection and response can happen.

The real takeaway

This isn't about stopping every bad action.

It's about making sure nothing destructive can happen instantly and at full scale.

That alone can turn a catastrophic event into something much more manageable..

6. Additional controls that strengthen the model

Beyond the core platform controls, there are a few additional layers that make a big difference in real-world scenarios.

These aren't all "single features" inside Workspace ONE. Some come from how you integrate identity, logging, and operations around it.

Protecting access to the admin console

The first layer is simply controlling who can get into the admin console in the first place.

In practice, that means putting the UEM console behind an identity provider and enforcing things like:

• MFA
• trusted network locations (VPN or corporate IP ranges)
• managed or compliant devices
• location-based restrictions

This isn't configured directly inside UEM. It's typically handled through your IdP (like Workspace ONE Access or another provider).

But it's critical. If you can reduce the chance of an admin account being used in the wrong context, you reduce everything that comes after.

Limiting standing privilege

Another important control is reducing the amount of access people have all the time.

Instead of permanent high-level admin roles, a stronger model is:

• grant elevated access only when needed
• limit how long it lasts
• require some form of approval or justification

Workspace ONE UEM itself doesn't natively enforce full just-in-time admin elevation, but this can be layered in through your broader identity or PAM strategy.

The goal is simple: fewer always-on privileged accounts.

Making audit data useful in real time

Logging exists in UEM, but the real value comes when you treat it as a live signal, not just a record.

That means:

• forwarding audit and event data to a SIEM
• monitoring for unusual admin behavior
• correlating things like role changes, policy edits, and wipe activity

UEM gives you visibility into who did what and when. Streaming that into a detection system turns it into something actionable.

Managing API access carefully

APIs are powerful, and they're often overlooked.

A few practical guardrails here:

• keep API permissions scoped as tightly as possible
• avoid long-lived or overly broad credentials
• monitor API usage alongside admin activity

Workspace ONE supports API access, but how tightly you control it is up to you.

The bigger picture

None of these controls is particularly flashy on its own.

But together, they close gaps that attackers tend to rely on:

• weak or overly broad admin access
• lack of context around logins
• no real-time visibility into changes
• unattended or over-permissioned API access

This is where the difference shows up between "we have controls" and "those controls actually hold up under pressure."

7. The missing layer: Change detection and alerting

Now, let's say the hacker got access to the console, knows the console settings inside and out and knows how to override all of the roadblocks listed above, is there a way to notify of major changes and force a second person to approve them? In other words, can Workspace ONE UEM or Intelligence detect and alert if someone modifies settings that would enable device wipe abuse?

Short Answer: Yes.

This one will take some real knowledge of UEM, Intelligence and Freestyle Orchestration, but you can set up workflows that would monitor audit logs. Intelligence can then be used for workflow orchestration and notifications. UEM can integrate with Intelligence through its API key/connector path and use Email/Slack/Teams/Hub Services/ServiceNow tickets as supported notification channels. UEM console events include admin actions and system settings changes, and those logs can be exported or integrated with a SIEM through Syslog.

Final takeaway

The Stryker incident was not just an attack. It was a control failure compounded by architectural exposure.

In the world as it exists today, a resilient UEM architecture must assume:

• Admin credentials can be compromised
• APIs can be abused
• Automation can be weaponized

The difference between disruption and disaster for Workspace One UEM comes down to:

• Verification (PIN / step-up auth)
• Segmentation (RBAC + Organizational Groups)
• Constraint (bulk limits)
• Detection (real-time change monitoring)

Platforms like Omnissa Workspace ONE UEM embed these controls natively, but they must be intentionally configured.

If there's one principle to carry forward:

Never allow a single action, from a single identity, to irreversibly impact your entire device fleet, and never rely solely on policy when architecture can enforce boundaries.