Intune Unattended Remote Help: Set Up the RBAC Scoping Correctly or You Are Handing Out Standing Device Access

Intune’s unattended Remote Help now lets a helpdesk technician sign into and take full control of a corporate Windows device without the end user present or needing to approve anything, genuinely useful for after-hours support, unattended kiosk devices, or servers in a physical location nobody’s sitting at. It’s also a capability that, misconfigured, hands out exactly the kind of standing remote access an attacker would love to find. Setting it up correctly means treating the RBAC scoping as seriously as the feature itself.

What unattended Remote Help actually does

Traditional Remote Help in Intune requires the device’s user to accept the incoming connection, standard attended remote support. Unattended access removes that requirement entirely for devices that have been specifically pre-configured to allow it, a helper establishes a full remote control session with no interaction needed from whoever, if anyone, is at the device. This is genuinely valuable for scenarios where nobody’s there to click “accept,” an unattended kiosk, a device left in a conference room, after-hours emergency access, but it’s also a meaningful expansion of what a compromised or misused helpdesk credential can do.

The RBAC permission is not inherited, and that’s the point

A dedicated RBAC permission, “Take unattended control of remote device,” governs this specifically and is not automatically inherited by any existing role, including roles that already have attended Remote Help access. The default state is disabled tenant-wide and must be explicitly turned on under Tenant administration > Remote Help. This separation is deliberate: an admin having ordinary Remote Help access doesn’t automatically mean they should have the stronger unattended capability, and Microsoft’s design forces that to be a conscious, separate decision rather than an accidental side effect of an existing role assignment.

Best practice, and worth treating as a hard requirement rather than a suggestion, is assigning this permission only to a dedicated, narrowly scoped security group, for example a specific facilities or infrastructure support team, rather than enabling it tenant-wide or granting it broadly to general helpdesk staff who don’t specifically need it.

Setup requires three coordinated pieces

1. The RBAC role with the “Take unattended control of remote device” permission, assigned to your narrowly scoped group.
2. Remote Help agents deployed to the target devices.
3. A Settings Catalog configuration profile enabling “Allow users to connect remotely by using Remote Desktop Services” (under Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections), targeted at the same device group.

All three need to target the same device groups consistently, a mismatch between which devices have the agent, which have the Remote Desktop Services setting enabled, and which users hold the RBAC permission is the most likely source of “it’s not working” support tickets during rollout, verify all three line up before assuming a technical fault.

Real limitations worth knowing before you plan around this

At general availability, only corporate-owned physical devices are supported, personal devices and virtual machines are explicitly not supported for unattended access. A Remote Help license is required for every user who interacts with the feature in either direction, both the helper initiating sessions and the device’s assigned user, license planning needs to account for both sides, not just the helpdesk staff.

Don’t skip audit logging

Enable audit logging for Remote Help sessions specifically, every unattended session should be tracked, who initiated it, which device, when, and for how long. Given that unattended access is precisely the kind of capability worth monitoring closely (standing remote control with no user confirmation step), this is the control that lets you actually answer “who accessed this device and why” after the fact, rather than just hoping the RBAC scoping alone prevents every possible misuse.

Frequently asked questions

Can we enable unattended Remote Help for our entire helpdesk team at once to save setup time?
You can, but it works directly against the feature’s own security model. The RBAC permission is deliberately not inherited from existing roles specifically so this requires a conscious decision, granting it broadly defeats that design and creates a much larger population of accounts capable of unattended device access than most environments actually need or can adequately monitor.

Does unattended Remote Help work on Azure Virtual Desktop or other virtual machines?
No, at general availability only corporate-owned physical devices are supported, virtual devices including AVD are explicitly excluded. Plan your remote support strategy for virtual desktop environments around attended Remote Help or a different tool instead.

What’s the actual security risk if RBAC scoping is done wrong here?
An overly broad grant of the unattended control permission means more accounts than necessary can establish full, unconfirmed remote control of corporate devices, if any of those accounts are compromised (phished credentials, a malicious insider), the blast radius is direct, unmonitored-by-the-user access to whatever devices that role can reach. Narrow scoping plus audit logging together are what keep that risk proportional to the actual support need.