In March 2026, an Iran-linked group called Handala pulled off one of the more instructive attacks in recent memory against Stryker, a Fortune 500 medical device manufacturer. They did not deploy ransomware. They did not slip a malicious executable past the endpoint tools. There was nothing for the antivirus to catch, because there was no malware.

They logged into the company’s Microsoft Intune console, the same mobile device management platform Stryker’s own IT team used every day, with a stolen admin session, and they started wiping. Laptops. Servers. Phones. The group claimed more than 200,000 devices across dozens of countries, and while that number is almost certainly inflated for effect, the disruption was real and confirmed: employees across the US, Ireland, Australia, and India watched their corporate laptops and their personal phones factory-reset in real time. People lost their photos. They lost their eSIMs, which meant they lost phone service. They lost the authenticator apps holding their banking two-factor codes. All of it executed cleanly, through the legitimate management channel, by someone who was never supposed to be holding it.

That is the story the whole security industry needs to sit with, because it is not really a story about one stolen password. It is a story about what MDM fundamentally is.

The management tool is a loaded gun pointed at your whole fleet

Mobile device management earns its keep by giving you deep, privileged, centralized control over every device you enroll. From one console, you can push apps, enforce policies, lock, and wipe, across the entire fleet, instantly. That reach is the entire value proposition. It is also, precisely, the problem.

Because that reach does not care who is holding the console. The same channel that lets your admin push a policy lets an attacker who steals that admin’s session push a wipe. The MDM does not distinguish between legitimate control and hijacked control. It just executes. You have built a single, always-connected, maximally-privileged pathway into every device your organization owns, and you have pointed it at your own fleet. When it works, it is management. When it is compromised, it is a weapon that is already aimed and already loaded, and the trigger is one credential.

Stryker is not an outlier. Two years earlier, attackers breached the MDM firm Mobile Guardian and remotely wiped thousands of student devices. Threat intelligence firms now flag compromised MDM credentials as a standing, high-value target precisely because the blast radius is the whole estate. This is a category of risk, not an accident. And the “no malware” part is what makes it so ugly: your defensive tools see a normal, authenticated admin doing normal admin things, right up until every screen in the company goes dark.

Three reasons the MDM paradigm is the wrong hill

Step back from the breach and look at the model itself, because the architecture has three problems, and if you have ever actually administered one of these platforms you have felt all three.

It is bewilderingly complex, and complexity is where security goes to die. Enterprise device management is a maze. Take Samsung Knox as the example everyone knows: it is not one thing, it is a stack of overlapping products and licensing tiers and policy layers, each with its own console, its own concepts, and its own hundred settings. Getting a fleet “right” means correctly reasoning about the interaction of more knobs than any one person holds in their head. And the security literature is brutally clear that the overwhelming majority of breaches trace back to misconfiguration, to a human getting one of those knobs wrong. A system you cannot fully understand is a system you cannot fully secure. Every layer you add to make the fleet “more managed” is another layer where a quiet mistake becomes an open door.

To manage a device, MDM has to pry it open. Here is the part that should bother you more than it does. For a management platform to reach into a device and control it, the device has to expose deep, privileged hooks for it to grab. Some of these platforms grant frankly invasive access to do their job, remote control, debugging-grade command channels, the ability to issue low-level instructions to the device as if you were plugged into it at a workbench. That access is sold to you as a feature. But a channel that can issue low-level commands to your device is a channel that can issue low-level commands to your device, and it does not stop being an attack surface just because your IT team is the intended user. You have deliberately built a backdoor and called it administration. When the console is compromised, the attacker inherits every one of those invasive capabilities.

The permanent reachback is a permanent liability. The MDM maintains a standing, privileged connection from a central cloud service into every device, forever. That is the single point whose compromise wiped Stryker. It is a concentration of risk with no equal in most organizations: one console, one credential, total reach. You spend enormous effort hardening individual endpoints, and then you connect all of them to one place that can override all of them at once. Security architecture 101 says minimize your high-value single points of failure. MDM is the practice of building one on purpose and plugging your entire fleet into it.

The next progression: a device that never needs managing

So here is the shift, and it is a genuine change in paradigm rather than a better version of the same one. MDM exists to drag a generic device into the state you want and then keep dragging it back there forever, because it will keep drifting, and to reach in and fix it when it does. That entire exhausting, invasive, centralized effort exists to solve one problem: the device did not start out the way you needed it.

So solve that problem instead. Build the device, completely, before it ever ships.

That is what zero baseline configuration means, and it is the thing we actually do. The phone arrives fully built out. Exactly the apps you need, already installed. Exactly the settings you want, already set. The hardening, already applied. The behaviors you require, already true. You take it out of the box, you turn it on, and it works precisely the way you intended, from the very first second, with nothing to configure and nothing to enforce.

Now walk that back through the three problems, because it dismantles all of them:

There is no complexity to misconfigure, because the correct state is not assembled in the field out of a hundred interacting policies you had to understand. It was built, once, deliberately, by people doing it on purpose and verifying it, and then reproduced identically. You are not reasoning about Knox layers at 4pm on a Friday. The device is simply already right.

There is no invasive access door, because a device that does not need to be managed does not need to expose the deep control hooks that management demands. Nothing has to be able to reach in and reconfigure it remotely, because there is nothing to reconfigure. You have not built a backdoor, because you did not need one.

There is no centralized reachback to hijack, because the device’s correct, secure state does not depend on a permanent privileged link to a cloud console. It stands on its own. There is no single console that, once phished, factory-resets your entire fleet in real time. The thing that wiped Stryker simply is not present, because you never built it.

The honest version of this

We are not going to pretend you never want any oversight. Some teams genuinely need remote wipe for a lost device, or basic visibility across a fleet, and that is legitimate. The point is not that management capability is evil. The point is that it should be a thin, optional layer sitting on top of a device that is already secure by construction, not the heavy, invasive, load-bearing thing that your security depends on. Build the device right, and any management you add is a light touch you could lose without becoming insecure. Build the device generic and lean on MDM to make it safe, and you have made your security depend on the one system whose compromise is catastrophic.

MDM was a reasonable answer to the problem of generic devices you had to wrangle into shape. But the better answer, the next step, is to stop shipping generic devices. If the phone is already exactly what it needs to be the moment it powers on, most of the reason MDM exists evaporates, and so does most of the risk it carries.

If you are currently fighting a management platform, or two, and quietly uneasy about how much reach and access you have had to grant just to keep a fleet in line, that unease is correct. There is a cleaner way. Email hello@spicycorp.com, or book a call, and we will build you phones that are right on arrival and do not need a loaded gun pointed at them to stay that way.