What actually changed, and how to govern it
Intune service release 2608 shipped this week, and buried in the release notes is a capability that materially changes what your helpdesk can do to a corporate endpoint:
Microsoft Intune now supports unattended Remote Help sessions on physical Windows devices. Authorized helpdesk agents can sign in to a remote device with their own credentials without requiring the user to be present or take action.
Until now, unattended Remote Help was an Android-only feature, and it was scoped tightly, dedicated-device enrollments, kiosks, warehouse scanners. Things without a human sitting in front of them. Windows was strictly attended: the user got a notification, saw the helper’s name and job title, and explicitly clicked Allow. No consent, no session.
That is no longer true.
This is a genuinely useful capability. It also removes the single most important control that made Remote Help easy to sign off on with a security team. If you are running Intune for clients or for a business that has an opinion about who can silently connect to a laptop, you need to understand this before someone enables it for you.
Why this landed now
Two things converged.
First, licensing. As of the July 2026 packaging change, Remote Help is no longer a separate Intune Suite add-on for most enterprise tenants, it now comes with EMS E3 (and therefore Microsoft 365 E3) and Microsoft 365 E5. A very large number of tenants acquired Remote Help without asking for it and without deploying it.
Second, capability. Attended Remote Help solves the “user is on the phone with me right now” problem. It does nothing for the far more common MSP scenario: a machine that needs work done outside business hours, a device stuck mid-provisioning, a task nobody wants to schedule a user’s time for. Unattended closes that gap and puts Intune in the same conversation as the third-party remote-access tools most shops are still paying for separately.
What an unattended Windows session actually looks like
This is the part worth reading carefully, because the flow is not what you’d expect from an attended session with the consent prompt removed. It’s architecturally different.
Launching it
From the Intune admin center, go to Devices > All devices, select the target device, and from the remote actions bar choose New remote assistance session > Remote Help > Continue. You then pick Initiate unattended control rather than Initiate attended control.
What blocks you
Intune runs a set of preflight checks and tells you which one failed:
- You don’t hold the unattended permission.
- The device is marked as personal (BYOD), unattended is not supported, full stop.
- The device doesn’t meet unattended prerequisites (you’re told which are missing).
- The device is offline.
- The device is non-compliant, this shows a warning banner only. It does not block you.
That last one matters. Non-compliance is advisory here, not a gate.
Connecting
A progress panel shows real-time status while Intune orchestrates the connection. When it’s ready, Open Remote Help launches the Windows App web client in a new browser tab, not the native Remote Help app. You authenticate again with the same account you used for the admin center, then choose which local resources to allow: file transfer, clipboard paste-through, and the Remote Desktop virtual printer.
Signing in to the device
Here’s the critical detail: you sign in inside the remote session with a real account. Supported types are:
- Local Windows account – ComputerName\UserName
- Active Directory domain account – Domain\UserName
- User principal name (UPN)
- Microsoft Entra ID account (UPN)
Least-privilege access is enforced – signing in with a standard user account does not grant administrator privileges.
Read that again if you’re about to write a runbook. Unattended Remote Help is not an elevation mechanism. It gets you a session on the box; your effective rights are whatever the account you signed in with already had. If your helpdesk has no admin credential for the endpoint, unattended gets them a standard-user desktop and nothing more. Plan your LAPS or EPM story accordingly, this feature does not replace it.
Concurrency. One helper per device, one unattended session per device. No stacking.
The part your users will notice
If someone is signed in to the target device, they get a notification and can choose Yes or No.
If they don’t respond, the notification displays for 30 seconds and then the unattended session starts automatically.
After that timeout, the user’s session is locked with their work preserved, Remote Help connects to a separate Windows session, and the user sees the lock screen and cannot observe any activity in the unattended session. If nobody is signed in at all, the session simply starts.
The user can reclaim the machine at any point by signing back in from the lock screen. When they do, they’re notified and can choose to continue or disconnect the unattended session and on the helper side, you’re told they came back. When the session ends, the device returns to its previous state and the user resumes where they left off.
So the honest summary for a client-facing conversation: a user who steps away from their desk for a coffee can have an authorized helpdesk session open on their machine without having agreed to it, and cannot see what’s happening in it. That’s a defensible design, the work is preserved, the sessions are separated, the user can take the box back but it is a change in the trust model, and you should be the one telling your client about it rather than their end users discovering it.
Prerequisites and deployment
Nothing here is new to Remote Help, but if you’ve never deployed it, this is the short version.
Tenant switch
Intune admin center > Tenant administration > Remote Help > Settings. Set Enable Remote Help to Enabled, it’s off by default. Two other toggles live here: Allow Remote Help to unenrolled devices (off by default; leave it that way unless you have a specific reason) and Disable chat.
Note the licensing lag: newly assigned or trial licenses can take anywhere from 30 minutes to 8 hours to activate, and sessions may keep insisting Remote Help isn’t enabled during that window. Don’t troubleshoot a problem that’s just propagation.
The app
Latest documented version is 5.2.1037.0, downloadable from aka.ms/downloadremotehelp. Two deployment paths:
- Enterprise App Catalog – prepackaged by Microsoft, handles updates for you. This is the path to take if you have it, and with the E5 packaging change more of you do.
- Win32 app – repackage remotehelpinstaller.exe as .intunewin.
Win32 command lines:
Install: remotehelpinstaller.exe /quiet acceptTerms=1
Uninstall: remotehelpinstaller.exe /uninstall /quiet acceptTerms=1To suppress auto-update (generally don’t):
remotehelpinstaller.exe /quiet acceptTerms=1 enableAutoUpdates=0acceptTerms and enableAutoUpdates are case sensitive.
Detection rule – file rule, path C:\Program Files\Remote Help, file RemoteHelp.exe, method String (version), operator greater than or equal to. Pull the version from a reference install:
(Get-Item "$env:ProgramFiles\Remote Help\RemoteHelp.exe").VersionInfoAssign to device groups, not user groups.
Firewall
If you’re running a hardened endpoint build, three executables need to get out:
C:\Program Files\Remote help\RemoteHelp.exe
C:\Program Files\Remote help\RHService.exe
C:\Program Files\Remote help\RemoteHelpRDP.exeNetwork
Port 443 to remotehelp.microsoft.com, RDP over TLS 1.2. If your proxy does SSL inspection, exclude the Remote Help endpoints, this is the number one cause of sessions that negotiate and then die. Also note the Intune Management Extension is required on the sharer’s device for remote launch.
The RBAC problem
Remote Help permissions are Intune RBAC, and there are six of them:
| Permission | What it grants |
| Remote Help – View screen | View the sharer’s screen, no control |
| Remote Help – Take full control | Full control of the device |
| Remote Help – Elevation | Interact with UAC prompts on Windows |
| Remote Help – Unattended | Connect without the sharer accepting each time |
| Remote Tasks – Offer remote assistance | Initiate assistance |
| Remote Assistance Connector – Read | See whether Remote Help is configured for the tenant |
A helper needs Offer remote assistance + Remote Assistance Connector – Read + at least one of the Remote Help permissions.
Here’s the thing to check before tomorrow morning: the built-in Help Desk Operator role already contains the Unattended permission.
It has had it all along, because until this week it only meant “Android dedicated devices”, a scope so narrow that most tenants effectively had a dormant permission sitting inside a role they’d handed out broadly. If Windows unattended is now honoured by that same permission, then everyone you assigned Help Desk Operator to has, without any action on your part, gained the ability to silently connect to Windows endpoints.
I’d treat that as the default assumption and verify it, rather than assuming you’re fine.
A wrinkle worth flagging
As of writing, Microsoft’s own documentation is out of sync on this. The start-session article was updated on 25 August 2026 and documents the full Windows unattended flow in detail. The planning article was last updated 24 June 2026 and still describes the Unattended permission as Android-only, with a mode-support table that shows unattended only for Android sharers. Don’t resolve that ambiguity by guessing. Open your own tenant, look at what the Help Desk Operator role actually contains, and test with a scoped pilot account against a lab device. Then write down what you found, because the docs will catch up and your notes are what your team will trust in the meantime.
What I’d actually do
Build a custom role. Split unattended out from the rest:
- Tier 1 – View screen, Offer remote assistance, Connector Read. Nothing else.
- Tier 2 – add Take full control and Elevation.
- Tier 3 / named individuals only – add Unattended, with a scope group that is deliberately narrower than All Devices.
This is exactly the least-privilege pattern Microsoft recommends in their own planning guidance, and it’s the difference between “our helpdesk can help users” and “eleven contractors can silently log into any laptop in the estate.”
One scoping trap: the All Devices scope group does not include unenrolled devices. If you support unenrolled machines, use a user scope group in the role assignment instead.
Conditional Access for helpers
Helpers now hold genuinely elevated access into endpoints, which makes a compromised helper account a much more attractive target. Conditional Access on Remote Help is supported on Windows and macOS, and you should be using it, require MFA and compliant device for anyone holding these permissions.
The Remote Assistance Service isn’t visible as a targetable resource in CA until you provision its service principal:
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppId "1dee7b72-b80d-4e56-933d-8b6b04f9a3e2"
Disconnect-MgGraphThat AppId is the Remote Assistance Service, the backend behind Remote Help. Once the SP exists, it appears in Conditional Access under Target resources > Resources as RemoteAssistanceService, and you can build policy against it.
Audit and privacy
What Microsoft retains: session start and end time, who helped whom on what device, and which features were used, all for 30 days. Session errors are written to the sharer’s Event Viewer. Remote Help writes session details to the Windows Event Log on both the helper’s and the sharer’s device.
Microsoft cannot access a session or view actions or keystrokes, and no session recordings are stored in the service. That’s a useful line for a privacy review, but note the flip side: there is no session recording. Your audit trail is metadata, who connected, to what, when, not a record of what was done. If your client’s compliance posture requires session recording for privileged access, unattended Remote Help does not provide it and you’ll need to say so plainly.
For monitoring, pair Intune audit logs with Entra ID sign-in logs to see who is authenticating to Remote Help. Unusual hours and unfamiliar helper accounts are the signals worth alerting on. And when someone leaves the support team, pulling them from the Remote Help RBAC role is what actually revokes the capability not disabling the app.
One more gotcha
If you have the EnableSecureCredentialPrompting policy enabled, it blocks elevation during Remote Help sessions. If your helpers report that UAC interaction silently doesn’t work, that’s your culprit. You have to disable the policy to allow elevation.
Bottom line
Unattended Remote Help on Windows is a real capability gain, and for single-tenant shops with a well-scoped helpdesk it’s worth turning on. But it arrives inside a permission that many tenants already granted broadly for a completely different purpose, in a release where the documentation hasn’t fully caught up, in the same quarter that Remote Help got bundled into E3 and E5.
That combination, dormant permission, expanded scope, wider licensing is how capabilities end up enabled in environments nobody audited. Go look at your Help Desk Operator role assignments before you do anything else.