What MDM can't protect on developer machines (and what to do about it)

Mobile Device Management (MDM) is a type of software used by organizations to secure, manage, and monitor their employees' mobile devices. Tools like Jamf, Kandji, and Microsoft Intune give IT teams visibility and control over every sanctioned application across the fleet. For compliance frameworks like SOC 2 or ISO 27001, MDM is often a core component of how you demonstrate device control and ensure data security. If your MDM is deployed, congratulations, you've solved 2012's BYOD security challenge.

The problem is that the modern developer attack surface has quietly outgrown what MDM was designed to handle. When developer machines get compromised, the entry point is rarely the OS or anything IT deployed. Recently, a malicious VS Code extension installed on a developer's device enabled an attacker to breach GitHub, exposing thousands of internal repositories. Before that, the Mini Shai-Hulud npm worm compromised over 160 packages, including Mistral and TanStack, by stealing credentials from developer machines. Developer devices are the number one target for attackers, and yet MDM is none the wiser. 

This post will cover where MDM's blind spots are, what EDR also misses, and how to make sure your developer devices are actually protected.

How MDM works, and where it stops

MDM operates at the OS and application layer. In practice, that means pushing OS updates, enforcing password policies, managing certificates, enforcing disk encryption, maintaining an inventory of installed applications, and keeping a remote wipe option in your back pocket for lost or stolen devices. For applications deployed through standard OS mechanisms like the App Store, enterprise software deployments, and signed binaries pushed through a management console, MDM works well.

The blind spots below all share the same root cause. Package managers like npm and pip are user-space tools. They pull software from registries that MDM has no relationship with, into project directories that MDM has no visibility into, triggered by commands running in a developer's shell. The same is true for IDE extensions installed through a marketplace, browser plugins, and AI tools. None of these go through the OS-level install mechanisms MDM monitors.

What MDM misses 

Package registries 

MDM knows what applications IT has approved and deployed, but it has no visibility into what a developer pulls from a package registry. That matters because packages run code at install time through lifecycle hooks before your security tooling has any chance to react. By the time a malicious package has executed its payload, it may have already scraped credentials from the developer's machine. The Mini Shai-Hulud worm worked exactly this way, silently lifting npm and GitHub tokens, and then using them to publish malicious versions of the next package in the chain.

AI coding tools have added a new twist to this. AI models hallucinate package names, and attackers register them before anyone notices. A developer asks an AI coding tool to add a dependency, the tool confidently suggests a package that doesn't exist, and an attacker has already claimed that name on npm with a malicious payload inside. MDM misses the install either way. 

Browser extensions

Even though much of a developer's work lives in the browser, most security teams aren't nearly worried enough about it. GitHub, cloud consoles, CI/CD dashboards, and internal tools all sit open and authenticated all day. Browser extensions sit on top of that environment with permissions that most people grant without a second thought. An extension with access to all sites can read everything the browser loads, including authenticated sessions and anything passing through the page in transit. MDM has no visibility into any of this. 

The Vercel breach earlier this year showed how quickly this becomes a problem. A Vercel employee installed a Chrome extension and granted it OAuth access to their Google Workspace. When a Context.ai employee's device was later compromised by an infostealer, the attacker found the stored OAuth token and used it to access Vercel's internal systems. MDM couldn't have flagged this malicious extension because it was installed by the developer, not IT, and what it did with the permissions it was granted was completely invisible to MDM.

What makes browser extensions particularly hard to manage is that they update silently. An extension that was clean at install can receive a malicious update overnight, and every user with auto-update enabled gets it automatically. The Cyberhaven breach in 2024 followed exactly that pattern. A phishing attack on a developer account led to a malicious update being pushed to all users, live for 24 hours before anyone caught it.

IDE extensions

Of all the software a developer installs, a VS Code plugin sits the closest to the crown jewels. It runs directly inside the development environment, with more visibility into what a developer is doing than almost anything else on the machine. Like browser extensions, IDE extensions are installed by developers themselves, update silently, and are nowhere in MDM's field of view. The difference is that IDE extensions can see source code and credentials.

The GitHub breach made this concrete. The entry point was the Nx Console VS Code extension, a verified publisher extension with 2.2 million installs that was compromised for just 18 minutes on the Visual Studio Marketplace. VS Code checks for extension updates every time the editor does a gallery interaction, sidebar open, marketplace search, background metadata fetch, so the malicious version reached developers with the editor open during those 18 minutes automatically, with no prompt and no warning. 3,800 of GitHub's internal repositories were exposed. MDM had no part in detecting any of it.

AI tools, MCP servers, and coding agents

AI coding tools are now a standard part of how developers work. Cursor, GitHub Copilot, Claude Code, and Windsurf take actions, often without a human reviewing what gets installed or where data goes. Security teams relying on MDM are largely flying blind on all of it.

MCP servers extend this further by giving AI assistants the ability to interact with external services. And like any dependency, they can be compromised. In September 2025, the postmark-mcp npm package became the first confirmed malicious MCP server in the wild. It silently blind-copied every outgoing email to an attacker-controlled address. The MCP server had fifteen clean versions before the backdoor appeared on the sixteenth.

This is a brand new attack surface, and most security teams aren't tracking it yet.

What about EDR? 

When security teams realize MDM isn't enough, Endpoint Detection and Response (EDR) is usually the next thing they reach for. Tools like CrowdStrike and SentinelOne watch for anomalous process behavior, suspicious file system changes, and command and control callbacks. If malware is actively running on a machine, EDR has a reasonable chance of catching it.

The problem is that EDR operates after execution. By the time it has something to detect, a malicious postinstall hook has already run, credentials have already been scraped, and in the case of Mini Shai-Hulud, stolen tokens were already being used to publish the next wave of compromised packages. EDR doesn't see npm install. It sees a process that looks like normal development activity. By then, it's too late.

How to fill the gaps

MDM and traditional EDR aren't going away, and they shouldn't. The goal is to layer controls on top of them that cover the developer-specific attack surface they were never built for.

Enforce a minimum package age

New packages are high risk. A 48-hour minimum age policy blocks same-day typosquatting and fast-moving malware campaigns before they reach your developers. The Mini Shai-Hulud campaign and the Axios attack both delivered their payloads through packages published within hours of the compromise. A 48-hour minimum age policy would have blocked both before they reached a single developer machine. It's worth noting this applies to npm and general software dependency packages. It doesn't help with auto-updating extensions, which is a different problem.

Block postinstall scripts by default

Most teams configure --ignore-scripts in their pipeline to block postinstall hooks from running automatically. Fewer apply the same default to developer machines. The Mini Shai-Hulud worm delivered its payload through a postinstall hook. If a developer's local environment runs install scripts by default, that's where the exposure is. You can set ignore-scripts=true in a global .npmrc file, but enforcing it consistently across a whole team without tooling is difficult.

Audit browser and IDE extensions

Most security teams have no idea what VS Code extensions or browser plugins are installed across their developer fleet. You need visibility into what's installed, by whom, and whether it's been updated recently. The GitHub and Vercel breaches both started with extensions that no one was monitoring. Maintaining an approved list and enforcing it centrally is the goal, but it's not something you can do manually at scale.

Monitor what AI coding tools install

Developers are using Cursor, Claude Code, Copilot, and a growing list of MCP servers, often without security teams knowing. Shadow AI is real. You can't govern what you can't see, and AI tools that install packages autonomously without human review are a live part of your attack surface.

Use dedicated developer endpoint tooling

The controls above are either hard to enforce consistently at scale or they don't cover the full attack surface. Dedicated developer endpoint tooling is built specifically for monitoring package installs, extension activity, and AI tool behavior at the device level across every machine in the fleet.

Aikido Device Protection deploys through your existing MDM and covers package registries, IDE extensions, browser plugins, and AI tool marketplaces. When a developer runs npm i axios and the latest version was published an hour ago, Device Protection falls back to the most recent version that satisfies a 48-hour minimum age policy. Safe installs go through without interruption. Malicious ones get blocked before they touch the machine.

It's built on Aikido Intel, which analyzes over 100,000 suspicious projects per day. If you want to start without a full deployment, Safe Chain is the open source starting point. If you were running it during the Shai-Hulud, TeamPCP, and Axios attacks, you were protected.

MDM is necessary, not sufficient

This isn't an argument for replacing MDM. It does what it was built to do, and for device compliance, certificate management, and demonstrating control to your auditors, it's still the right tool. But developer machines have quietly become a different category of endpoint, with a threat surface that didn't exist when MDM was designed.

The question most security teams should be asking is what happens between the MDM policy and the package install.

‍