Intune Remote Help: An SMB Unattended Support Guide

An employee should not have to stay late just to let a technician inspect a company PC. But removing that dependency should not remove the business's control over who connects, what they change, or how the work is documented.

Microsoft introduced unattended Remote Help sessions for physical Windows devices in Intune's August 2026 service release. Authorized technicians can connect using their own credentials without an employee present. This guide reflects documentation checked on September 21, 2026. Microsoft's release notes establish the feature's availability; your tenant, licensing and device readiness still need verification.

ITECS recommendation: treat unattended support as a narrowly approved maintenance capability, not permission to enter every employee computer at any time. Start with a small device group, named technicians, a written operating policy and a tested way to revoke access. The checklist below is planning guidance, not evidence that your environment is ready.

Understand what an unattended session actually does

Remote Help's unattended Windows experience creates a separate authenticated Windows session. It is not simply invisible control of an employee's existing desktop. Microsoft's overview also describes Remote Help as a same-tenant service, not an out-of-the-box cross-tenant support console. An MSP must plan the customer-tenant identity and access model rather than assume its own tenant grants access to client PCs. Read Microsoft's Remote Help overview.

For SMBs, that distinction helps separate two jobs: troubleshooting an issue the employee needs to demonstrate, and completing approved device maintenance when the employee is away. Choose attended support for the first when practical. Consider unattended support for the second only when the technician can complete and validate the task without impersonating the employee or borrowing their password.

Illustrative example: a technician checks a failed application installation on an approved office PC after closing time. The ticket names the application, device, permitted changes and fallback. A request to inspect the employee's personal documents is outside that maintenance scope and requires escalation, not a broader interpretation of remote access.

Check licensing before buying another subscription

Microsoft's current Intune licensing page lists Remote Help in Intune Plan 2, which is additive to Plan 1; Intune Suite includes Plan 2. Its deployment planning guide says Microsoft 365 E3 includes Plan 2 and Remote Help starting July 2026, with E5 and E7 including those capabilities too. That is not a statement that every Microsoft 365 subscription includes Remote Help.

The Remote Help-specific planning page still describes an additional subscription requirement and calls for Remote Help licensing for both helpers and users receiving support. Because these pages are not fully aligned, confirm your purchased SKU, enabled service plans and user assignments with your licensing owner before rollout. Do not assume unattended Windows removes the user licensing requirement. Check the product-specific requirements.

Record what is already owned, what must be purchased, who needs assignment and when a trial expires. Include technician training, deployment packaging, audit retention and ongoing access reviews in the budget—not just the subscription line. Ask for a written entitlement answer if your shared-device or outsourced-support arrangement is unclear.

Build a device-readiness inventory

Microsoft limits unattended Windows control to physical, corporate-owned, Intune-managed x64 devices that are Microsoft Entra joined or hybrid joined. BYOD, unenrolled devices, Windows 365 Cloud PCs and Azure Virtual Desktop targets are excluded. Required components include the Intune Management Extension (IME), enabled Remote Desktop, the Azure Virtual Desktop agent and its bootloader. The PC must be awake, powered on and internet-connected. Verify supported platforms and prerequisites.

Create one readiness row per proposed pilot device. Capture its owner, operating-system edition and servicing status, architecture, join/enrollment state, installed prerequisites, network location and maintenance window. Flag unsupported or ambiguous devices for a separate support path. A working attended session does not prove unattended eligibility.

Use currently supported Windows builds and confirm that the edition supports the required Remote Desktop configuration. Do not treat an installer's minimum-version setting as an operating-system support promise. Test office desktops and remote laptops separately: a powered-off laptop in an employee's bag is not an available maintenance target. Agree on charging, connectivity and sleep arrangements without casually weakening the organization's normal power or security policies.

Deploy the correct components and test the network path

Attended and unattended Windows support use separate applications and workflows. Microsoft's unattended deployment instructions require the Azure Virtual Desktop agent first, followed by its bootloader; Intune Win32 dependencies can enforce that order. Installing the attended Remote Help app alone is not the complete unattended setup. Microsoft also documents automatic agent updates, so a successful initial install is not the last compatibility check. Follow the current deployment instructions.

Keep device assignments explicit. Check successful installation and IME health before treating a support-session failure as a licensing problem. Record the package versions and policy assignments in the pilot evidence.

Use Microsoft's current Remote Help network endpoint list when reviewing outbound connectivity and inspection policies. Do not turn a Remote Desktop prerequisite into an instruction to expose inbound RDP to the internet. Have the network owner validate the actual connection path from office and remote networks; request narrowly reviewed exceptions rather than disabling protective controls wholesale.

Enable the tenant, then scope the people and devices

Remote Help is off by default. Enabling it under Tenant administration > Remote Help makes the service available tenant-wide; your pilot boundary must come from deployment and permissions. The built-in Help Desk Operator role does not include Windows unattended remote sign-in. Microsoft requires a custom role with the Windows unattended control remote sign-in permission for that capability. Review tenant setup and role configuration.

• Business owner: approves the eligible systems, acceptable maintenance windows and business impact.
• Tenant/security owner: approves the custom role, technician membership, target scope and review process.
• Support lead: assigns a named technician to a ticket with clear boundaries and a fallback.
• Technician: checks the target and authorization, performs only approved work, and records validation and session closure.

In a co-managed arrangement, write down which team owns each decision. Avoid shared technician accounts and blanket administrator assignments. Test a technician who should be allowed and one who should be denied. Test an in-scope and an out-of-scope device. A successful connection alone cannot prove that the access boundary works.

Check the complete permission set, including Offer remote assistance and connector Read. The same-tenant boundary also covers helper devices, not just accounts. Review permissions and tenant planning.

Do not assume attended Conditional Access protects unattended access

Important limitation: Microsoft's current Windows overview explicitly says its Remote Help Conditional Access policies apply to attended sessions and do not apply to unattended access. Generic or other-platform statements about Conditional Access support should not be read as proof of enforcement on this new path. See the mode-specific limitation.

Ask the identity/security owner to map the actual authentication chain: admin-center sign-in, the browser connection and the Windows sign-in inside the remote session. Verify which protections apply at each step and retain evidence of the tests. Require strong protection for privileged identities, but do not label an unattended session “MFA-enforced” without proving the relevant path. If a required control cannot be demonstrated, keep that device class out of the rollout and use an approved alternative.

Remote connectivity is also not blanket administrative authority. Define separately which Windows account may sign in and what privileges it should have. Do not solve an access failure by handing the technician an employee's credentials or casually granting permanent local administrator rights.

Explain privacy and off-hours behavior before the pilot

Microsoft's Windows instructions say an active user can accept or decline an unattended connection. With no response, it proceeds after 30 seconds, locking the user's session while preserving their work. With nobody signed in, it starts automatically. The helper works in a separate session; the employee cannot watch that activity from the lock screen. A user can sign back in and choose to continue or disconnect the support session. Only one unattended session/helper can connect to a device at a time. Review the Windows session behavior.

Explain this plainly to employees. A timed-out notification is not an adequate substitute for an organization's written access policy. Specify why access occurs, which teams may connect, what information they may inspect, prohibited activities, notification practices and how to raise a concern. Have HR or counsel review requirements appropriate to your workforce and jurisdiction; the feature itself does not establish compliance.

Microsoft's connection workflow also offers local-resource options such as clipboard, file transfer and printer redirection. Standard-user sign-in does not automatically grant administrator privileges. Review these options as part of the task rather than accepting every capability by default. Check the connection workflow.

Collect evidence that explains the work, not just the connection

Microsoft documents Remote Help session reports with helper/recipient details, target device, session times and control type. Its monitoring guidance specifies 30-day server retention and says screen contents and keystrokes are not recorded. It also notes that Windows elevation is not reported in the sessions report. These are metadata records, not a complete recording of everything a technician did. Read the monitoring limitations.

During the pilot, inspect the fields actually populated for unattended Windows sessions. Pair those records with a controlled ticket containing the request, approver, technician identity, device, authorized actions, actual changes, result and follow-up. Decide who can access the evidence and how long the business needs it retained. Test your retention/export process rather than assuming a report remains available indefinitely.

Useful operating measures include rejected out-of-scope attempts, sessions without a matching ticket, unexpected off-hours access, revoked-access test results and changes that required recovery. Measure time savings only after establishing a baseline and checking the quality of the work.

Run a pilot with explicit stop and rollback rules

ITECS suggests the following acceptance checklist. These are operating controls to agree with your support team, not automatic product guarantees:

1. Prove the approved path. Use a representative enrolled test PC, a named authorized technician and a harmless maintenance task. Confirm prerequisites, sign-in, task completion and session end.
2. Prove the denied path. Confirm an unauthorized technician and an out-of-scope PC cannot be used. Keep the exact role and group evidence with the result.
3. Exercise real availability. Test office and remote connectivity, an asleep/offline device, user rejection and the user's return during support. Record observed behavior and communication gaps.
4. Validate the evidence. Reconcile session metadata to the ticket. Confirm the team can distinguish an attempted connection from completed work.
5. Rehearse revocation. End an active test session; remove the dedicated permission or approved membership, verify propagation and attempt a fresh connection. Do not assume revoking a role instantly terminates every existing session.
6. Approve expansion. Broaden device groups only after the business and security owners accept the results. Leave exceptions on attended or other approved support paths.

Pause rollout for unexplained access, missing evidence, unexpected user disruption, or an authentication requirement you cannot enforce. Rollback has two parts: stop further unattended access and undo the maintenance change if needed. Preserve the prior configuration and the task-specific recovery method before work begins.

Revert only policies and components introduced for the pilot after checking dependencies. Do not uninstall an agent used by another service or disable Remote Desktop globally without evaluating other approved uses. Disabling Remote Help tenant-wide affects more than this pilot; reserve that wider action for an authorized incident response. Keep attended support or an on-site option available while the issue is investigated.

Choose accountability before convenience

Unattended maintenance should mean an approved person doing an approved job on an approved device, with a record and an exit path. It should not mean unrestricted access because a remote-support product happens to allow a connection.

If your business wants to evaluate this capability within a managed or co-managed support arrangement, explore ITECS Microsoft 365 consulting or talk with ITECS about a scoped pilot. Start with the devices, responsibilities and controls you need—not a promise that every support request should become unattended.

---

Research note: Prepared with AI assistance for ITECS and checked against the linked Microsoft documentation on September 21, 2026. Licensing and Conditional Access documentation contain scope differences noted above. This is a planning guide, not a report of an ITECS client deployment, a security certification or legal advice. Recheck Microsoft's requirements and your tenant before implementation.