Remote Support Sessions: Controlling How the Service Desk Takes Over a User Device

A remote support session hands a stranger's voice on the phone the keyboard of a signed-in user's device, and attackers have learned that impersonating the service desk is one of the fastest ways in. Most organisations have hardened the remote management platform itself, but the individual session, how it starts, who consents, what the helper may do, whether elevation is allowed and what is recorded, is often left to analyst habit. This guide sets out the controls for desk-to-user sessions: verifying both parties, consent and control levels, handling elevation without sharing passwords, recording and privacy, closing a session cleanly, and spotting sessions that should not exist. It is for service desk managers, endpoint engineers and security teams who own remote support policy.

Key takeaways

• Verification runs both ways. The desk must verify the user, and the user must have a reliable way to verify the desk; unsolicited "IT support" contact is the attacker's opening move.
• Grant the least session level that solves the ticket. View, control, elevated and unattended sessions carry different risk and should need different permissions.
• Elevation uses the helper's own just-in-time rights. Never ask a user for a password, and never type a shared admin password into a user's session.
• One approved tool, one tenant. Remove or block consumer and unapproved remote support tools so a user cannot be talked into installing one.
• Every session ties to a ticket and leaves a trail. Session logs, ticket references and post-session clean-up are what make sessions reviewable.

What this guide adds to RMM and help desk controls

Two existing guides cover the neighbouring ground. The RMM Tool Security Guide covers approving, hardening and detecting remote management platforms. The Account Recovery and Help Desk Security Guide covers how the desk verifies callers before resets. This page sits between them: the moment an analyst connects to a user's live desktop. The Screen Sharing Security guide covers meeting-style sharing and is a useful companion for user awareness.

The threat is well documented. Microsoft reported in May 2024 that Storm-1811 phoned users while posing as IT or help desk staff, sometimes after flooding their inboxes with subscription email, then talked them through starting a Quick Assist session and approving screen sharing and remote control. The actor then downloaded further tooling and deployed ransomware. MITRE ATT&CK tracks the techniques as T1566.004 Spearphishing Voice and T1219 Remote Access Tools.

Session types and the permission each needs

Tools differ in how they express these levels. Microsoft Intune Remote Help, for example, uses role-based access control to set which helpers can only view and request full control and which can run with elevated privileges; elevation lets helpers enter UAC credentials on the sharer's Windows device once the sharer has granted access; and unattended control (remote sign-in) applies only to physical, corporate-owned, Intune-managed Windows devices. Whatever the tool, map its permissions to the table above and assign them through roles, not individual exceptions.

Starting a session: verifying both parties

Desk verifying the user

Before connecting, confirm the user is who the ticket says, using the same verification tiers as for resets (see the Help Desk Identity Verification Policy Template). A view-only session on a standard device can use a lower tier than an elevated or unattended session on a privileged user's device.

User verifying the desk

• User-initiated by default: Sessions start from a ticket the user raised or from a call the user placed to a published number. Analysts do not cold-call users to offer remote help unless a ticket exists and the user can see it in the self-service portal.
• Verifiable helper identity: Prefer tools where both helper and user sign in with organisation accounts. Remote Help requires both parties to sign in with a Microsoft Entra account from the same organisation, so it cannot be used to reach users outside the tenant. Quick Assist is designed for general help between any two people: the helper signs in with a Microsoft account or Entra ID and the sharer sees the helper's first name and last initial, so the callback rule below matters most where it is available.
• Callback rule: If the user did not expect contact, they hang up and call the desk on the published number. Teach this as the one rule users remember.
• Chat channel checks: When contact comes through a collaboration tool, users check for external-sender labels. Microsoft's Storm-1811 guidance tells users to verify the External tag in Teams.

The Co-op incident in 2025 shows the reverse of the same problem: attackers impersonated an employee to the desk to obtain a password reset, then used the account to move into the network. See Co-op Cyber Attack 2025: How Help Desk Social Engineering Exposed the Data of 6.5 Million Members. Both directions need a verification step the attacker cannot simply talk past.

Consent and control during the session

• Explicit, staged consent: The user approves screen sharing, then separately approves control. Quick Assist works this way (Allow to share, then Allow or Deny when the helper selects Request control), and most enterprise tools offer a similar prompt for attended sessions. Do not configure attended sessions to skip the prompt.
• Visible indicator and easy stop: Users must be able to see a session is active and end it at any moment. Tell them they may do so without penalty.
• Sensitive screens: Ask users to close personal email, banking and HR systems before control is granted. Analysts pause or switch to view-only when a user must type a password or personal data.
• No password requests: Analysts never ask users to read out or type their password, MFA code or recovery code into chat. If a credential is needed, the session is the wrong tool.
• Scope stays on the ticket: Browsing the user's files, mail or chats outside the ticket's purpose is a policy breach, and session logs should make it detectable.

Elevation without shared passwords

Elevation is the moment a support session turns into privileged access. Handle it the way you would any other admin action.

See the Local Administrator Password Solution (LAPS) Guide for rotation after use, and the JIT Access Guide for time-bound admin roles. NCSC's secure system administration principles make the same point at system level: protect administration interfaces, tier administrative access, use privileged access management to control who, where, when, why and how, and log all administration activity.

Unattended access

Unattended access removes the user's consent prompt, so the controls move to the platform and the approval process. Our recommendation at NHI Mgmt Group:

1. Limit unattended access to corporate-owned, managed devices and a named group of analysts.
2. Require a ticket reference and a second approver for unattended sessions to user devices; shared kiosks and lab machines can use a standing approval.
3. Require phishing-resistant MFA for the helper at session start. Note that Microsoft documents Conditional Access for Remote Help as applying to sessions an end user accepts, not to unattended access, so check how your tool authenticates unattended sessions and compensate where needed.
4. Notify the device's primary user after the session with what was done and the ticket number.

Recording, logging and privacy

Session logs answer who connected to which device, when, for how long, and at what level. Intune Remote Help reports show who helped whom, on which device and for how long, and session audit entries sit under Tenant Administration, Audit Logs; Microsoft notes auditing is limited for unenrolled devices. Quick Assist is privacy-focused by design: Microsoft states that it keeps session timing and feature usage data, not session content, and creates no logs on either device. Microsoft suggests that organisations using Quick Assist within a single Microsoft Entra tenant consider switching to Intune Remote Help, and documents how to disable or remove Quick Assist.

• Metadata always: Keep session start, end, helper, device, user, level, elevation events and ticket reference, and forward them to the SIEM.
• Video recording selectively: Record elevated, unattended and file transfer sessions where your tool supports it. Recordings capture whatever was on screen, including personal data, so agree retention, access and notice wording with your privacy team before turning it on.
• Tell users: State in the session prompt or support policy what is logged and recorded and why.

Closing a session cleanly

• End and confirm: The analyst ends the session and the user confirms on screen that control has returned.
• Remove temporary tools: Delete any diagnostic tools, scripts or files transferred during the session.
• Revoke rights: Let just-in-time roles expire and trigger LAPS rotation if a local password was used.
• Record actions: Write what was changed into the ticket, so the next analyst and any investigator can match it to the session log.

Tool estate decisions

Pick one approved attended tool and, if needed, one unattended tool, then remove the rest. Microsoft's Quick Assist documentation explains how to disable or remove it, either by uninstalling the MicrosoftCorporationII.QuickAssist package or by blocking outbound HTTPS to remoteassistance.support.services.microsoft.com; note that blocking the endpoint also breaks Intune Remote Help, which depends on it. Block other unapproved remote access tools using the allowlisting and network controls in the RMM Tool Security Guide, and keep the evaluation criteria in the Remote Support and Screen Sharing Tools buyer's guide for the next renewal.

Small organisations: One tool, attended sessions only, admin rights through LAPS with rotation, and the callback rule taught to every user. Larger organisations: Role-based session levels, just-in-time elevation, unattended access with approval, SIEM integration and monthly sampling of session logs against tickets. Outsourced desks need the same controls written into the contract; see the GDAP and MSP Delegated Admin Access Guide.

How to implement

1. Inventory: List every remote support tool in use, who can start sessions, and how elevation is done today.
2. Write the session standard: Session levels, verification tiers, consent rules, elevation method, recording scope and clean-up steps.
3. Configure roles: Map analysts to view, control, elevation and unattended roles in the approved tool; pilot with one desk team for two weeks.
4. Switch elevation: Move analysts from any shared admin account to just-in-time roles or LAPS, then disable the shared account. Keep it disabled, not deleted, for a short rollback window.
5. Remove unapproved tools: Uninstall or block consumer tools in audit mode first, review the hits, then enforce.
6. Launch user messaging: Publish the callback rule and how users can check a ticket exists.
7. Turn on monitoring: Forward session logs and build the detections below.

Detection and measurement

• Session without ticket: Join session logs to the ITSM ticket reference; flag sessions with no matching open ticket.
• Unapproved tool launch: Alert on execution of remote support tools outside the approved list, especially shortly after an inbound call or chat from an external tenant.
• Unusual elevation: Alert on elevated sessions to privileged users' devices or outside desk hours.
• Unattended spikes: Alert when one helper starts unattended sessions on many devices in a short period.

Common failure patterns

• Desk cold-calls normalised: Analysts routinely ring users to offer help, so users cannot tell an attacker's call from a real one.
• Consumer tool left installed: A built-in or free tool remains available and is the one attackers ask users to open.
• Shared admin password: Every analyst types the same local admin password, which is then on screen in hundreds of sessions.
• Unattended for everyone: All analysts can connect silently to any device, including executives' laptops.
• No session-to-ticket link: Logs exist but nobody can say why a session happened.

Framework mapping

Practitioner checklist

• Approve one attended tool and remove or block the rest, including unused built-in tools.
• Define view, control, elevated and unattended session roles and assign them by role.
• Start sessions only from a ticket or a user-placed call; publish the callback rule.
• Keep staged consent prompts on for attended sessions.
• Elevate with just-in-time admin roles or LAPS with rotation, never a shared password.
• Limit unattended access to managed corporate devices with approval per use.
• Log every session to the SIEM with a ticket reference; record elevated and unattended sessions.
• Close sessions with tool removal, rights expiry and ticket notes.

Standards and references

• NIST: SP 800-53 Rev. 5
• NCSC: Secure system administration
• CISA: Guide to Securing Remote Access Software
• MITRE ATT&CK: Remote Access Tools
• Microsoft: Remote Help in Intune
• Microsoft: Use Quick Assist to help users
• Microsoft Threat Intelligence: Threat actors misusing Quick Assist in social engineering attacks

Related NHI Mgmt Group resources: RMM Tool Security Guide · Account Recovery and Help Desk Security Guide · Help Desk Social Engineering Incident Playbook · Local Administrator Password Solution (LAPS) Guide