Vendor-neutral remote support governance

Prove every remote session was authorized.

Use these 24 checks to define who may connect, which endpoints they may reach, when attended or unattended access is permitted, what the technician may do, and which evidence must survive after the session closes. Adapt the checklist to customer agreements, applicable law, product capabilities, and the risk of the managed system.

Evaluate RMM remote access Troubleshoot a failed connection Compare RMM with remote desktop software Decide whether you need access, RMM operations, or both Compare RMM, remote support, MDM, and UEM Assess GoTo Resolve remote-support fit Define remote-support authority for insurance-agency IT Review technician permissions Prepare an incident runbook Print this checklist

1. Establish authority

  1. Document the customer agreement, policy, ticket, or named approver that permits remote support for the endpoint class.
  2. Separate attended support, approved unattended administration, emergency access, and prohibited access instead of using one global rule.
  3. Define which customers, sites, device groups, operating systems, and critical systems require additional approval or are out of scope.
  4. Record the legal, privacy, notification, consent, recording, and data-retention requirements that apply to the session.

2. Verify the technician

  1. Require a named technician identity, strong authentication, and an approved administrative device before granting remote-control rights.
  2. Limit access by role, customer, site, device, capability, support window, and expiration rather than relying on broad team membership.
  3. Review employment status, business justification, last use, temporary elevation, exceptions, and the next access-review date.
  4. Prohibit shared credentials, unexplained persistent sessions, unmanaged technician devices, and access that cannot be attributed to one person.

3. Authorize the session

  1. Bind the session request to a customer, endpoint, issue, ticket, requester, expected work, support window, and approving authority.
  2. Confirm the endpoint identity and tenant placement before connecting; stop when hostnames, users, serials, sites, or customer context conflict.
  3. Use customer notice or interactive consent when required, and record the approved unattended-access exception when consent is not interactive.
  4. Choose the least-capable mode that can complete the work, such as view-only, terminal, file transfer, background tools, or full remote control.

4. Control the work

  1. Display the customer and endpoint identity throughout the session and warn before crossing into a different tenant, device, or privilege boundary.
  2. Set idle, maximum-duration, reconnect, clipboard, file-transfer, recording, and local-input rules appropriate to the endpoint risk.
  3. Require separate approval for destructive commands, credential changes, security-control changes, bulk actions, or access to regulated data.
  4. Prevent hidden persistence, unauthorized account creation, unexplained tool installation, or transfer of customer data outside the approved workflow.

5. Retain evidence

  1. Record the technician, approver, customer, endpoint, session ID, source context, start and end time, access mode, and final outcome.
  2. Link the ticket, approval, commands or changes, file transfers, recording or audit reference, customer communication, and follow-up work.
  3. Use synchronized time and durable audit storage so the session can be reconstructed without relying on one technician's notes.
  4. Alert on sessions outside approved windows, unknown technicians, high-risk endpoints, missing tickets, failed authentication, or policy bypass.

6. Close and review

  1. End the session explicitly, confirm no hidden reconnect or unattended process remains, and verify the endpoint returns to the intended state.
  2. Revoke temporary elevation, one-time approvals, shared links, transferred secrets, or emergency access immediately after the work.
  3. Escalate unexpected access, unexplained commands, data exposure, policy bypass, or missing evidence through the incident-response process.
  4. Review exceptions, false positives, customer complaints, abandoned sessions, and repeated work to improve policy, roles, training, and controls.

Minimum session record

A defensible record identifies the actor, approver, customer, endpoint, reason, ticket, access mode, start and end time, material actions, file transfers, outcome, evidence reference, and any exception or follow-up owner. A tool showing only “connected” and “disconnected” is not enough to prove authorization or explain what happened.