*This is the second article in our Microsoft Intune Suite series. Read the first article, Microsoft Intune Suite: What IT Teams Should Know for context on how the suite is evolving and what is changing with Microsoft 365 licensing.
One of the first questions that comes up when moving to cloud-native device management is also one of the most practical: how do we support devices remotely now?
Devices are internet-first, users are remote, and the tools most teams have relied on were built for a very different environment. For a long time, the honest answer was some version of a workaround. Remote Help is Microsoft’s purpose-built response to that gap, and with its inclusion in Microsoft 365 E3 licensing from mid-2026, it’s worth understanding properly before it lands in your tenant.
Traditional remote support tools assumed devices were on the corporate network, that helpdesk staff had reliable access, and that on-premises identity was enough. Cloud-native breaks all of those assumptions at once.
Built-in options like Quick Assist cover some scenarios, but they don’t give you the enterprise controls most IT teams actually need. Tools left over from a hybrid or on-premises setup don’t extend cleanly into a cloud-native model. Third-party remote support tools fill the gap well, but they sit outside the Microsoft management plane and bring their own licensing and overhead with them.
Remote Help is designed to close that gap from within Intune, using the same identity, the same access controls, and the same audit trail you’re already relying on for everything else.
Remote Help is a cloud-based remote support solution that’s part of the Microsoft Intune Suite. It lets IT support teams connect securely to end-user devices for real-time assistance, with authentication and authorization handled through Entra ID and Intune’s role-based access controls.
The key difference from ad-hoc alternatives is the integration. There’s no separate credential system, no shared link access, and no session that falls outside your audit trail. Support staff authenticate with their organizational identity, permissions are defined in Intune, and every session is logged.
Remote Help has historically been available as part of the Intune Suite add-on. From mid-2026, it will be included in Microsoft 365 E3 as part of Microsoft’s broader move to bring advanced Intune capabilities into core M365 licensing. For Education environments, it’s already included in A1, A3, and A5 plans.
Both the helper and the sharer connect outbound to Microsoft’s Remote Assistance Service at `remotehelp.microsoft.com`. Neither side needs an inbound connection, and neither needs a VPN. Communication runs over RDP on port 443 with TLS 1.2, which means it travels through standard HTTPS paths and clears most network environments without special firewall rules beyond what Intune already requires.
Entra ID handles authentication at both ends. Helpers sign in with their organizational account, and their Intune permissions determine what they can do during the session. Sharers do the same, which means Remote Help only operates within a single tenant. A helper can’t connect to a device in a different Entra ID tenant.
Platform support is important to understand before deploying. The level of functionality varies significantly depending on the platform and how each party connects.
Windows is where Remote Help is most capable. The native Windows client supports view-only, full control, and elevation, which lets a helper interact with UAC prompts without the user needing to step in. There’s also a remote launch feature that lets a helper kick off a session directly from the Intune admin centre. For most enterprise helpdesk scenarios, Windows covers the primary use cases well.
macOS support exists but at a reduced level. Helpers use the web client rather than a native app, and elevation isn’t supported. View-only and full control are available, but teams with a large macOS fleet should test the experience before assuming it’s on par with Windows.
Android covers both attended and unattended session modes for enrolled corporate-owned devices. Unattended access is particularly useful for dedicated device scenarios like kiosks, logistics hardware, and frontline worker phones, where you need to manage the device without requiring user interaction. During unattended sessions the screen is hidden, with a visible indicator that a remote session is active.
Linux doesn’t have a native Remote Help client. The web-based sharer experience may work on supported browsers, but it’s not a formally supported configuration.
Deploying Remote Help is straightforward, but there are a few dependencies worth planning for ahead of time.
Licensing is the starting point. Remote Help needs to be enabled at the tenant level before any sessions can happen. It’s off by default, so confirm your licensing covers it and enable it before doing anything else.
Client deployment requires the Remote Help app to be installed on devices that will be sharing their screen. Deploying it through Intune as a managed application is the recommended approach for Windows and macOS. It keeps versions consistent across your fleet and removes friction when a session is actually needed. For Android, the app is distributed through Google Play.
RBAC configuration defines what helpers can do. Remote Help includes specific permissions that can be assigned through custom roles or through the built-in Help Desk Operator and School Administrator roles:
|
Permission |
What It Allows |
|
View screen |
See the sharer’s screen without taking control |
|
Take full control |
Interact directly with the sharer’s device |
|
Elevation |
Handle UAC prompts on Windows during a session |
|
Unattended |
Connect to enrolled Android devices without user acceptance |
|
Offer remote assistance |
Initiate a session to a user |
|
Remote Assistance Connector - Read |
View Remote Help configuration in the tenant |
It’s worth being deliberate here, particularly around elevation and unattended. Access should reflect what helpdesk staff genuinely need to do the job, not a blanket grant of everything available.
Network endpoints need to be reachable from both helper and sharer devices. The primary endpoint is `remotehelp.microsoft.com` over port 443. Microsoft’s Intune network endpoints documentation covers the full list and is worth reviewing as part of deployment planning.
Remote Help automatically creates a session record for every interaction, which is a practical advantage over ad-hoc tooling. Intune logs each session with the operator identity, the device involved, session duration, and an activity record. Audit logs are accessible in the Intune admin center under Tenant Administration.
For organizations in regulated industries where remote access to endpoints needs to be documented, this matters. It also gives you a foundation for operational reporting: support volume, devices that get accessed frequently, and a clear record of what happened during a session.
It’s a meaningful step up from the zero visibility that most informal screen-sharing approaches provide.
Remote Help covers a lot, but there are limitations worth knowing before you commit. The product has evolved consistently since launch and these gaps are narrowing, but they’re real today.
Multi-tenant and MSP scenarios aren’t currently supported. Both the helper and sharer need to be in the same Entra ID tenant. For organizations managing devices across multiple tenants, this is a real constraint, and third-party remote support tools currently have the advantage there.
Unattended access on Windows is more limited than on Android. The full unattended session model available for enrolled Android corporate devices doesn’t have a direct Windows equivalent. If that’s a significant requirement in your environment, evaluate it carefully before making any decisions.
macOS functionality doesn’t match Windows yet. The web-only helper experience and lack of elevation support create a capability gap for macOS-heavy environments. It’s an area the product has room to grow, and one worth keeping an eye on in the release notes.
These gaps define where Remote Help fits today. The direction is clearly toward broader platform coverage and feature parity, and the release cadence reflects that.
For organizations on Microsoft 365 E3 or above, managing primarily Windows devices, and looking to bring remote support inside the Intune management plane, Remote Help makes a strong case. It removes the need for a separate licensing relationship, uses the identity and access model already in place, and gives you a proper audit trail without requiring VPN or inbound network access.
For environments with significant unattended Windows requirements, large macOS fleets, or MSP models spanning multiple tenants, the current limitations mean Remote Help may complement existing tooling rather than replace it entirely. The right answer depends on your environment and what you’re trying to consolidate.
The real question for most IT teams isn’t whether Remote Help is the best remote support tool in isolation. It’s whether the integration, the reduced overhead, and the audit capability make it the right fit for what’s already in place. For most organizations moving toward a fully cloud-native endpoint model, it will be.
A few things worth working through before deploying:
Define your RBAC model first. Work out who needs to provide support and what level of access each role actually requires. Elevation is a significant permission, so be deliberate about who holds it and review it as team membership changes.
Deploy the client through Intune. Use Intune to deploy and maintain the Remote Help app on managed devices rather than relying on manual installs. Version consistency matters when a support session is needed in a hurry.
Communicate to end users. Users encountering Remote Help for the first time may not know what to expect. A brief heads-up about when a technician might use it and what they’ll see during a session goes a long way.
Review existing tooling overlap. If you’re currently running a third-party remote support solution, map out which scenarios Remote Help covers before planning any transition. Running both in parallel for a period tends to produce better outcomes than a hard cutover.
Remote Help is the first individual component we’ve covered in this series. Coming up, we’ll work through Endpoint Privilege Management, Advanced Analytics, Cloud PKI, and Enterprise App Management, covering what each one does, where it fits, and what to consider when implementing it.
If you want to understand how Remote Help fits into your specific environment, get in touch with the Devicie team.