For many organizations, Intune started as a practical way to manage laptops, phones, and tablets across a hybrid workforce. It pushes configuration profiles, deploys apps, enforces compliance, and helps support teams keep devices under control at scale. In Microsoft 365 environments, it often becomes part of the everyday background infrastructure - so familiar that people stop thinking about how much authority it really has.
That familiarity is exactly what makes it risky.
Intune is not just a convenience tool for endpoint admins. It is a high-trust control plane. Whoever controls it can influence what runs on managed devices, which devices are considered healthy, which users can reach corporate resources, and in some cases whether devices keep working at all. That makes Intune a security platform, whether an organization treats it like one or not.
Recent reporting around the March 2026 cyberattack on Stryker made that painfully clear. Multiple reports said attackers abused Microsoft Intune and Entra privileges to remotely wipe a very large number of devices, causing broad operational disruption without relying on traditional malware. CISA later warned organizations to secure endpoint management systems in response to the incident.
That case is a useful reminder of something many IT teams already know in theory but do not always design around in practice: modern management platforms can become attack platforms if privileged access is lost.
Intune Is Part of a Larger Security Stack
To secure Intune properly, it helps to understand where it sits in Microsoft's broader architecture. Three components work together:
Microsoft Intune manages the device. It handles configuration, application deployment, compliance policies, and many administrative actions on managed endpoints.
Microsoft Entra ID manages identity and access. It determines who the user is, what roles they hold, and which cloud resources they are allowed to reach.
Conditional Access uses signals - including device compliance - to make access decisions. It is the policy engine that connects identity, device state, and application access.
That interaction matters because Intune does not just configure devices. It can also influence whether those devices are trusted enough to access sensitive resources.
How Device Compliance Becomes an Access Decision
Inside Intune, administrators can define what a compliant device looks like. That might include requirements such as:
- A minimum operating system version
- BitLocker or full-disk encryption enabled
- A password or screen lock configured
- Anti-malware enabled and healthy
- No jailbreak or root detection findings
Intune evaluates devices against those conditions and marks them compliant or noncompliant. Entra ID can then use that compliance state inside Conditional Access policies to allow or block access to Microsoft 365 and other integrated resources.
In other words, access can depend not just on the user's identity, but also on whether the device they are using currently meets your security standards.
That is the moment Intune stops being "just MDM." It becomes part of the security boundary. If an attacker can change compliance policies, alter device posture, or abuse administrative rights inside Intune, they are not only tampering with endpoint management - they may also be influencing access control.
Why Intune Deserves the Same Security Attention as Identity
Most security teams already watch sign-ins, email activity, privilege escalation, and risky application behavior. Fewer monitor what is happening inside their endpoint management platform with the same seriousness. That is a blind spot.
An Intune administrator may be able to:
- Deploy PowerShell scripts to Windows devices
- Deliver or remove applications across the fleet
- Modify compliance and configuration policies
- Wipe, retire, or delete managed devices
- Change role assignments or administrative scope
That is a remarkable amount of power concentrated in one place. In a well-run environment, those capabilities are how IT keeps endpoints secure and supportable. In the hands of an attacker, the same capabilities can be used for disruption, persistence, privilege expansion, or widespread destructive action.
The Stryker case is important precisely because it illustrated that destructive impact does not always require ransomware or custom malware. Reporting on the incident said attackers allegedly used legitimate administrative pathways - including Intune-linked control - to wipe devices at scale after compromising privileged access.
That is the lesson many organizations need to absorb: if someone gets deep enough into your management plane, they do not necessarily need to "hack" every endpoint one by one. They can use your own centralized tooling to do it for them.
The Intune Management Extension Matters More Than Many Teams Realize
One technical detail worth understanding is the Intune Management Extension (IME). Microsoft describes IME as a Windows agent that extends what standard MDM can do. It is commonly used for things like PowerShell scripts, Win32 app deployment, custom compliance settings, and other advanced management tasks on Windows endpoints.
That distinction matters. When people talk about cloud-based management, it can sound abstract - as if everything happens inside a portal. But the administrative action in the cloud often results in something very concrete happening on the endpoint. A script runs. An app installs. A setting changes. A process executes locally.
That creates two places security teams need visibility:
Cloud-side visibility: Who signed into the portal, what role they had, what policy or object they touched, and what actions they initiated.
Endpoint-side visibility: What actually ran on the device, what process spawned it, what files changed, what command lines were used, and what the local impact was.
If you only watch the cloud side, you can miss the execution details. If you only watch the endpoint side, you can miss the privileged administrative trail that explains why something happened in the first place. Both matter. Together, they tell the real story.
The Stryker Case: A Real Example of the Risk
Security articles sometimes lean too hard on hypothetical "could happen" scenarios. That is why the Stryker incident is so useful as a teaching example.
According to recent reporting, attackers were able to abuse privileged Microsoft control-plane access and allegedly used Intune-related functionality to wipe a massive number of devices in a short period of time. Reports described disruption across many countries, affecting not only corporate systems but, in some accounts, also employee-enrolled devices. CISA responded by urging organizations to harden Microsoft endpoint management and administrative controls.
The important takeaway is not just that Stryker was hit. It is how the attack reportedly worked.
This was not a story about malware silently spreading from machine to machine. It was a story about administrative trust being weaponized. Once attackers reached the control plane, they could allegedly trigger destructive action from the top down.
That is exactly why Intune security cannot be treated as a side concern owned only by desktop engineering. It belongs in the same conversation as privileged identity, cloud administration, and incident response.
The Four Intune Risk Areas Most Teams Underestimate
Not every Intune capability carries the same level of risk. Four areas deserve special scrutiny.
1. Remote Wipe
Remote wipe exists for a good reason - lost or decommissioned devices need to be cleared. But it is also one of the most destructive actions available to administrators. In the wrong hands, it can remove data and rapidly disrupt operations at scale.
The Stryker incident showed how device-management features designed for legitimate administration can become destructive at enterprise scale if privileged access is compromised.
What to do: Use Multi Admin Approval for high-impact actions wherever supported, especially destructive device actions. Restrict the number of admins who can initiate wipes. Review wipe permissions explicitly rather than assuming they are rare enough to be safe by default.
2. PowerShell Script Deployment
Scripts are one of the most useful parts of Intune - they automate fixes, remediate drift, and solve problems that standard policy settings cannot address. They are also a built-in code execution channel to managed Windows devices.
If an account with script deployment authority is compromised, an attacker may be able to run arbitrary code broadly across the fleet.
What to do: Limit script deployment rights through custom RBAC. Require peer review before sensitive scripts are approved. Monitor for new or modified scripts and correlate those changes with device-side telemetry.
3. App Deployment
Software deployment is operationally normal, but from a security standpoint it is also a trusted software delivery mechanism. A compromised admin account does not need to trick users into downloading something if it can push an application directly through a platform the organization already trusts.
What to do: Treat app deployment permissions like privileged software distribution rights. Keep them narrow, review them often, and monitor for unusual app additions, removals, or reassignment at scale.
4. Role and Permission Changes
This may be the most underestimated risk in Intune. An attacker who can change role assignments, expand scope, or create backdoor administrative paths may be able to quietly deepen their foothold before using more visible actions like scripts or wipes.
That kind of change is especially dangerous because it can look administrative rather than overtly malicious - at least at first glance.
What to do: Treat RBAC changes as security events. Alert on them. Review them regularly. Use approval workflows for sensitive role changes where supported. Keep a close eye on who can modify the approval model itself.
Least Privilege Is the Control That Changes Everything
The fastest way to make Intune riskier is to give too many people broad rights because it feels convenient. In the short term, that may reduce friction. In the long term, it increases blast radius.
Build roles around real job functions
Microsoft Intune supports role-based access control, including custom roles. A more mature design breaks responsibilities apart:
- One group handles retirements and wipe operations
- One group owns script deployment
- One group manages application packaging and rollout
- One group owns compliance and configuration baselines
- One group handles reporting and read-only review
If one account is compromised, the attacker inherits a smaller set of options.
Use scope tags to reduce visibility and blast radius
Roles determine what an administrator can do. Scope tags determine which objects they can see and manage. That makes them especially useful for separating teams by geography, business unit, or function.
- An EU support team only sees EU devices
- A finance admin only sees finance-managed endpoints and policies
- A kiosk support team only sees kiosk-related objects
- Helpdesk staff see a smaller resource set than senior engineering
That is not just tidy administration. It is blast-radius reduction.
Protect the admin accounts themselves
Even the best RBAC model will fail if privileged accounts are easy to compromise. Any account with meaningful Intune power should be treated like a privileged identity:
- Phishing-resistant MFA, preferably hardware-backed where possible
- Conditional Access for administrative sign-ins
- Anomaly detection for sign-in behavior and privilege changes
- Minimal standing access, ideally with just-in-time elevation where possible
Intune security and identity security are not separate projects. They are tightly linked parts of the same problem.
Five Habits of a Mature Intune Security Program
Organizations that handle Intune well tend to develop a few consistent habits.
- They treat Intune admins as privileged identities. Endpoint admins control a platform that can change device state, user access, and enterprise-wide software behavior. Their accounts need the same seriousness applied to identity admins and security admins.
- They require approval for high-impact actions. When an action is rare, destructive, or capable of broad business disruption, one person should not be able to trigger it alone. Device wipe is the obvious example.
- They keep roles narrow. Broad built-in roles may be fast to assign, but they are expensive when something goes wrong. Mature teams build around real responsibilities instead of convenience.
- They scope administrative reach deliberately. An admin should only see and touch what they are responsible for. Scope tags help enforce that principle operationally.
- They monitor both the portal and the endpoint. They look at sign-ins and admin logs, and also at what actually executed on the device. You need both to tell the full story.
A Practical Intune Security Checklist
### Identity and privileged access - [ ] All Intune and Entra privileged accounts use phishing-resistant MFA - [ ] Conditional Access policies cover privileged sign-ins - [ ] High-privilege accounts are separate from day-to-day user accounts - [ ] Standing privilege is minimized and reviewed regularly - [ ] Sign-in anomalies and role changes generate security alerts
### Compliance and access control - [ ] Compliance policies are clearly defined and aligned to risk - [ ] Sensitive cloud resources require compliant devices where appropriate - [ ] Exception paths are documented, limited, and reviewed - [ ] Device compliance reporting is regularly validated against reality
### RBAC and scope tags - [ ] Broad built-in roles are replaced with focused custom roles where practical - [ ] Wipe, script, app deployment, and policy management permissions are separated - [ ] Role assignments are reviewed on a fixed schedule - [ ] Scope tags are used to segment by region, business unit, or device class - [ ] Helpdesk teams only see what they are meant to support
### High-impact action controls - [ ] Multi Admin Approval is enabled for supported destructive or sensitive changes - [ ] The number of people who can change approval settings is very small - [ ] Wipe, retire, and delete authority is intentionally limited - [ ] Sensitive app and script deployment paths have review controls
### Logging and detection - [ ] Intune admin activity is monitored and retained long enough for investigations - [ ] Entra sign-in logs, audit logs, and Intune logs can be correlated - [ ] Endpoint telemetry captures script execution and software installation activity - [ ] Alerts exist for unusual policy changes, mass device actions, and admin scope changes - [ ] Investigators can reconstruct both the cloud action and the endpoint impact
### Change management and resilience - [ ] Sensitive script and deployment changes require peer review - [ ] Emergency wipe processes are documented and tested - [ ] Rollback procedures are real, not just written down - [ ] Actual permissions are validated periodically against expected design - [ ] Recovery planning assumes the management plane itself may be abused
That last point matters more than many teams realize. The Stryker case is a reminder that business continuity planning cannot assume the device management platform will always be there to help. In some incidents, it may be part of the problem.
The Bigger Lesson
One reason Intune security is easy to neglect is that the platform is so useful. It solves real operational problems. It reduces manual work. It helps standardize device posture. It gives IT teams leverage.
That is exactly why it deserves respect. Powerful management platforms always sit close to the line between administration and security. In healthy hands, they improve control. In compromised hands, they compress the time between access and impact.
The Stryker incident brought that into focus in a very public way. Attackers did not need to rely on custom malware or noisy lateral movement across endpoints. They allegedly used administrative trust, centralized control, and built-in management pathways to create disruption at scale.
Intune is not just a deployment tool. It is part of your control plane. It is part of your security posture. It is part of your attack surface.
Final Thoughts
The good news is that the controls needed to make Intune safer are not exotic. Microsoft already provides the building blocks: RBAC, scope tags, compliance integration, Conditional Access, audit trails, and Multi Admin Approval for selected sensitive changes.
The challenge is usually not product capability. It is implementation discipline.
If you want Intune to be defensible, start with the basics that matter most:
- Treat Intune admins as privileged identities
- Reduce broad standing access
- Separate duties with custom roles
- Limit visibility with scope tags
- Require approval for destructive or high-impact actions
- Monitor both administrative activity and endpoint execution
Do those things well, and Intune becomes much harder to abuse. Skip them, and one compromised admin account may be enough to turn your management platform into your biggest operational liability.