Published on:
May 28, 2026
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Last updated on:
May 28, 2026
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "TechArticle",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#article",
"headline": "What MDM Can't Protect on Developer Machines (And What To Do About It)",
"description": "MDM tools like Jamf and Kandji are essential but they don't see npm installs, IDE extensions, or AI coding tools. Here's what's actually unprotected on your developer machines and how to close the gap.",
"url": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"datePublished": "2026-05-28T00:00:00Z",
"dateModified": "2026-05-28T00:00:00Z",
"inLanguage": "en-US",
"timeRequired": "PT10M",
"keywords": [
"MDM",
"Mobile Device Management",
"developer endpoint security",
"npm security",
"VS Code extension security",
"IDE extension security",
"browser extension security",
"MCP server security",
"EDR limitations",
"supply chain attacks",
"slopsquatting",
"Aikido Device Protection",
"developer device security",
"endpoint protection",
"Jamf",
"Kandji",
"Microsoft Intune",
"CrowdStrike",
"SentinelOne",
"postinstall hooks",
"ignore-scripts",
"Safe Chain",
"Aikido Intel"
],
"articleSection": "Security Guides",
"author": {
"@type": "Person",
"@id": "https://www.aikido.dev/authors/nicholas-thomson",
"name": "Nicholas Thomson",
"jobTitle": "Senior SEO & Growth Lead",
"url": "https://www.aikido.dev/authors/nicholas-thomson",
"worksFor": {
"@type": "Organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev"
},
"sameAs": [
"https://www.linkedin.com/",
"https://x.com/"
]
},
"publisher": {
"@type": "Organization",
"@id": "https://www.aikido.dev#organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines"
},
"about": [
{
"@type": "DefinedTerm",
"name": "Mobile Device Management",
"description": "A type of software used by organizations to secure, manage, and monitor employee devices, operating at the OS and application layer."
},
{
"@type": "DefinedTerm",
"name": "Endpoint Detection and Response",
"description": "Security tooling that detects and responds to threats after they are executing on a device, watching for anomalous process behavior and file system changes."
},
{
"@type": "DefinedTerm",
"name": "Slopsquatting",
"description": "An attack where threat actors register package names that AI models tend to hallucinate, waiting for developers to install them on an AI coding tool's recommendation."
}
],
"mentions": [
{
"@type": "SoftwareApplication",
"name": "Jamf",
"url": "https://www.jamf.com"
},
{
"@type": "SoftwareApplication",
"name": "Kandji",
"url": "https://www.kandji.io"
},
{
"@type": "SoftwareApplication",
"name": "Microsoft Intune",
"url": "https://learn.microsoft.com/en-us/mem/intune/"
},
{
"@type": "SoftwareApplication",
"name": "CrowdStrike",
"url": "https://www.crowdstrike.com"
},
{
"@type": "SoftwareApplication",
"name": "SentinelOne",
"url": "https://www.sentinelone.com"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Device Protection",
"url": "https://www.aikido.dev/protect/device-protection"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Safe Chain",
"url": "https://github.com/AikidoSec/safe-chain"
},
{
"@type": "SoftwareApplication",
"name": "Aikido Intel",
"url": "https://intel.aikido.dev"
}
],
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["h1", "h2", "p"]
}
},
{
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"url": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines",
"name": "What MDM Can't Protect on Developer Machines",
"description": "MDM tools like Jamf and Kandji are essential but they don't see npm installs, IDE extensions, or AI coding tools. Here's what's actually unprotected on your developer machines and how to close the gap.",
"inLanguage": "en-US",
"isPartOf": {
"@type": "WebSite",
"url": "https://www.aikido.dev",
"name": "Aikido Security"
},
"breadcrumb": {
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#breadcrumb"
},
"primaryImageOfPage": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/images/what-mdm-cant-protect-on-developer-machines.png"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.aikido.dev"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.aikido.dev/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "What MDM Can't Protect on Developer Machines",
"item": "https://www.aikido.dev/blog/what-mdm-cant-protect-on-developer-machines"
}
]
},
{
"@type": "Organization",
"@id": "https://www.aikido.dev#organization",
"name": "Aikido Security",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
},
"sameAs": [
"https://www.linkedin.com/company/aikido-security",
"https://x.com/AikidoSecurity",
"https://github.com/AikidoSec"
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What does MDM not protect against?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM operates at the OS and application layer and cannot see package manager installs (npm, pip), IDE extensions, browser plugins, or AI coding tool activity. These happen in user space through channels MDM has no hooks into."
}
},
{
"@type": "Question",
"name": "Can MDM protect developer machines?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM can enforce OS-level policies, manage certificates, and track IT-deployed applications on developer machines. However, it cannot monitor package installs, IDE extensions, browser plugins, or AI tools, which represent the primary modern attack surface for developer devices."
}
},
{
"@type": "Question",
"name": "What is the difference between MDM and EDR for developer security?",
"acceptedAnswer": {
"@type": "Answer",
"text": "MDM manages devices at the OS and application layer, while EDR detects threats after they are already executing. Neither tool was built to understand developer-specific behavior like package installs, IDE extensions, or MCP servers. Dedicated developer endpoint tooling is needed to cover this gap."
}
},
{
"@type": "Question",
"name": "What is slopsquatting?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Slopsquatting is an attack where threat actors register package names that AI coding tools tend to hallucinate. When a developer asks an AI tool to add a dependency and the tool suggests a non-existent package, an attacker may have already claimed that name with a malicious payload."
}
},
{
"@type": "Question",
"name": "How does Aikido Device Protection work with MDM?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Aikido Device Protection deploys through your existing MDM, meaning tools like Jamf or Kandji push the Device Protection agent to every machine in your fleet. Device Protection then handles the developer-specific attack surface that MDM cannot see, covering package registries, IDE extensions, browser plugins, and AI tool marketplaces."
}
}
]
}
]
}
</script>
Tired of false positives?
Try Aikido like 100k others.
Start Now
Get a personalized walkthrough
Trusted by 100k+ teams
Book Now
Scan your app for IDORs and real attack paths
Trusted by 100k+ teams
Start Scanning
See how AI pentests your app
Trusted by 100k+ teams
Start Testing
Not sure whether you need a pentest or a red team engagement? This guide breaks down the key differences, when to use each, and how AI is changing both.
GitHub Actions misconfigurations have been behind some of the biggest supply chain attacks of 2025 and 2026. Here's what went wrong and how to prevent them from happening to your org.
Most developer security rollouts fail because they're designed like software deployments, not cultural changes. A practitioner's guide for enterprise CISOs.
Secure your code, cloud, and runtime in one central system.
Find and fix vulnerabilities fast automatically.
No credit card required | Scan results in 32secs.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。