Ask a security team to name the systems that can run arbitrary code on every laptop in the organisation and they will name the deployment tooling, the endpoint agent, and possibly the domain. They will not name Intune, because Intune presents itself as a place where you tick boxes about password length. It is a place where you tick boxes about password length and a remote code execution service, and only one of those two things is in anybody’s threat model.
What the product actually does
Strip the interface away and Intune offers three ways to put instructions on a managed Windows device and have them executed with full local privilege.
The first is a PowerShell script. You upload a file, you assign it to a group, and the agent on the device runs it. By default it runs in the system context, which is the highest privilege the operating system has, higher than the person using the machine.
The second is a Win32 application. An application in Intune is an archive plus an install command line. The service does not inspect what is inside it and cannot. Anything an installer can do, an application assignment can do, at whatever privilege the assignment grants.
The third is a remediation, which is a pair of scripts that run on a schedule: one to detect a condition, one to correct it. Its distinguishing property for this argument is that it is recurring. A script runs when you assign it. A remediation keeps running.
An Intune assignment is a mechanism for executing code you choose, as SYSTEM, on every device in a group you choose, without touching any of them. That is the capability. Everything else in the product is a user interface over it.
None of this is a vulnerability and none of it is hidden. It is the product working exactly as specified, and it is why the product is worth having. The problem is not the capability. The problem is that the capability is governed as though it were a settings console.
The mismatch between how the permission feels and what it grants
Consider how somebody comes to hold it. A new person joins the endpoint team. They need to be able to fix things, so they are given an Intune administrator role, or added to a group that has one, or made a Global Administrator because that was faster and it was going to be reviewed later.
Now compare that to how the same organisation would treat a request for the ability to run a script as root on every server. That request goes to a change board. It gets a named approver, a window, a rollback plan and an audit trail. The two requests grant the same class of power over a larger number of machines, and only one of them is treated as a decision.
The asymmetry has an obvious cause. Server administration looks dangerous because you type commands into a terminal. Endpoint management looks safe because you fill in a form in a browser. The blast radius runs the other way: the terminal touches one host, and the form touches the fleet.
There is a second-order version of the same mistake that is worth naming, because it survives even in organisations that have thought about the first. The endpoint team is often scoped tightly on devices, using scope tags so that a regional administrator sees only regional machines, and then scoped not at all on the content of what they can deploy. Restricting whose laptops somebody can reach is a real control. It does nothing about what runs on the laptops they can reach.
Why this is a different conversation from device security
Most of what an organisation calls endpoint security is about the device defending itself: antivirus, attack surface reduction, disk encryption, controls on what a local administrator can do. All of it assumes the management plane is trusted, because all of it is delivered by the management plane.
That assumption is load bearing and it is rarely examined. An attacker who reaches the management plane is not fighting those controls, they are holding the thing that configures them. They can turn off what is inconvenient, deploy what they need, and do it through the same mechanism the organisation uses for legitimate work, which means it generates exactly the telemetry that legitimate work generates.
This is the property that makes it worth a threat model rather than a hardening checklist. There is no signature for a malicious app assignment, because a malicious app assignment is indistinguishable in form from a legitimate one. The only thing that separates them is whether somebody was supposed to make it.
Detection cannot answer this, because the malicious action and the legitimate action are the same action. The only control that discriminates is one that asks whether the change was intended, and asks it before the change applies.
The control that answers it, and what it actually covers
Intune has a native answer, and it is better than most people assume because most people have not read its scope. It is called Multi Admin Approval, configured as access policies, and the idea is a second pair of hands: when any account makes a change to a protected resource, the change is not applied until a different account approves it.
The protected resource types are the interesting part, because they map onto the argument above almost exactly. Applications, meaning app deployments. Scripts, meaning PowerShell deployed to Windows. Configuration policies via the settings catalog. Compliance policies. Device actions, specifically wipe, retire and delete. Role based access control itself, including changes to role permissions and to who is in which admin group. Tenant configuration. And access policies themselves, which are protected automatically so that the control cannot be quietly removed by the person it constrains.
Two properties are worth stating plainly because they are the ones that make it a real control rather than a formality.
An administrator cannot approve their own request, and that holds all the way up. A change submitted by a Global Administrator still requires a different administrator to approve it. The most privileged account in the tenant does not get to self-serve, which is unusual and is the property that makes this worth deploying.
It now applies to automation as well as to people. Calls made with application credentials through the Graph API are intercepted the same way, and a call that does not carry the approval headers is refused. An application cannot approve its own request, only an interactive administrator can. Read operations are unaffected. This closes the obvious bypass, which was to do through a service principal what you were being asked to get approved in the portal.
Where it quietly does nothing
A control that is believed to be on and is not is worse than no control, because it displaces the attention that would otherwise go somewhere useful. Multi Admin Approval has three ways to be exactly that, and all three are in the documentation rather than in anybody’s runbook.
It is opt-in per workload. There is no master switch. Protecting applications does not protect scripts. An organisation that turned it on for the resource it was thinking about that day has a control over that resource and no others, and the admin center will not tell it so.
The approver group has to be the right kind of object, and the wrong kind fails silently. It must be a security group. A distribution list, a Microsoft 365 group or a mail-enabled security group is not supported and does not resolve approver membership, without an error that makes that obvious. The failure mode is a policy that looks configured and an approver list that is empty.
The approver group must itself hold an Intune role, directly. It has to be added as a member group to at least one Intune role assignment, and permissions its members hold individually or through other groups do not satisfy the requirement. If the group is not assigned that way, its members are periodically removed from it. That is a control that decays on its own, quietly, after somebody has ticked it off.
There is also an operational edge that is not a defect but will be experienced as one: a request that is not carried through expires after three days and has to be resubmitted. Deploy this without telling the people who will use it and the first genuine emergency change becomes an argument about the control rather than about the emergency.
What the threat model asks you to change
Not much, and none of it is exotic. The point of writing it down is that each of these is obvious once the capability is stated correctly and none of them is obvious while Intune is filed under device configuration.
Treat the roles that can create assignments as privileged access, with the same activation and expiry you would apply to anything else that can run code widely. Turn on approval for the resource types that execute code, which is applications and scripts first and role based access control immediately after, because that last one is what an attacker changes in order to stop needing approval. Then verify the approver group is a security group, is directly assigned to an Intune role, and has somebody in it who is not the person who deployed the control.
And separate the two questions that scope tags blur. Whose devices can this person reach, and what is this person allowed to send to them. Most tenants have an answer to the first and have never asked the second.
The sentence this is all in aid of
Every organisation running Intune has already decided how much it trusts the people who can push code to its fleet. Almost none of them have noticed that they decided it, because the decision was made by a role assignment somebody granted in a hurry and nobody has revisited.
Writing the capability down in plain terms is most of the work. Once somebody has said the words remote code execution on every managed device out loud in a governance meeting, the controls follow on their own, and they follow quickly, because nobody in the room wants to be the person who argued against a second approver on that.
