GoTo Resolve and LogMeIn Rescue Security: Technician Roles, PINs, Zero Trust and Audit

A remote support account can take control of a desktop, run scripts and move files, so the way technicians sign in, which permissions they hold and how a customer joins a session decide whether the tool stays a support channel. GoTo offers two remote support products that IT teams commonly run: GoTo Resolve (shown as LogMeIn Resolve in current GoTo documentation), managed through GoTo Admin, and LogMeIn Rescue, managed through the Rescue Administration Center. This guide covers how identity and access work in each, the administrator and technician roles to restrict, how session codes and PINs are issued, unattended access, sign-in protection, session recording and reports, and a hardening baseline. It is written for service desk owners, IT administrators and identity engineers who run either product. Products are listed alphabetically and each gets its own section; the order is not a ranking.

This is an independent guide from NHI Mgmt Group, based on GoTo's public documentation for GoTo Resolve and LogMeIn Rescue as of November 2026. It is not sponsored or reviewed by GoTo. Product features change, so confirm settings against GoTo's current documentation.

Key takeaways

• Treat technicians as privileged users. Both products let a technician launch remote control, deploy scripts and transfer files, so technician accounts belong in your privileged access programme, with named owners, strong sign-in and quarterly review.
• Use the zero trust signature key in GoTo Resolve. Once approved, the signature key is required to deploy unattended devices, remotely control devices, run commands or PowerShell scripts and create groups, which adds a second secret on top of the account sign-in.
• Use technician group permissions in LogMeIn Rescue. Rescue permissions are set per Technician Group and inherited by members, so build small groups with only the permissions each support tier needs, such as script deployment or unattended access.
• Short-lived codes and customer prompts limit misuse. Keep session code and PIN validity short, and prompt the customer for permissions at session start, so a code read out over the phone cannot be reused later.
• Record and report. Turn on automatic session recording where policy allows, and export session, login and audit reports to your SIEM so unusual technician activity is visible.

How identity and access work in GoTo Resolve and LogMeIn Rescue

Each product separates account administrators from the technicians who run sessions, and connects either through an attended session, where the end user joins with a code or link, or through unattended access installed earlier.

GoTo Resolve

GoTo Resolve users are managed in GoTo Admin. Every user has a role (Super admin, Admin or Member), and administrators can also build custom roles from a list of permissions. Agents run sessions from the Console. For attended support, the agent starts a session from the Instant remote support card on the Support tab and the end user joins at helpdesk.me/join with a support key, or through a direct link or email link. GoTo's documentation states the support key expires after 60 minutes on paid plans and after 5 minutes on trial plans. The end user then downloads and runs the session application. The agent can choose to request remote control as soon as the end user arrives and to request admin mode when switching to remote control.

Unattended devices are reached from the Devices list with the Remote control action. With zero trust set up, the agent enters their signature key before the session starts. If the end user is present but ignores the request, a 60 second timer runs before the agent can select Connect now.

LogMeIn Rescue

LogMeIn Rescue uses an organisation hierarchy in the Administration Center. The Rescue administrator guide describes these levels:

• Master Administrator: full control of the Administration Center, and the only role that can open the Global Settings tab.
• Administrator: manages assigned technicians and Technician Groups, generates reports and configures channels for those groups; can be assigned to several groups.
• Administrator Group: uses either Standard administrator rights or Restricted administrator rights, which limit access to specific tabs.
• Technician Group: holds the permissions that its members inherit.
• Technician: works in the Technician Console with the group's permissions.

Customers connect by PIN Code, link, or through one of the ten channels that can be assigned to Technician Groups and renamed. Under Time-outs, the Private code validity period sets how long a PIN Code or link stays valid; after it expires, the customer is told the code has expired. Under Customer Applet, Prompt customer for permissions with the option One time when session starts forces a permission dialog when the session begins.

Admin roles and privileged access

GoTo Resolve roles and permissions

GoTo's documentation describes three built-in roles. A Super admin has all system permissions. An Admin has all system permissions except adding Super admins, managing other Admins, viewing reports and managing billing; access to reports and call recordings must be granted by a Super admin. A Member has no system permissions and cannot open the GoTo Admin portal. Custom roles are built from these permissions:

Zero trust interacts with roles. GoTo describes Admins and Super admins as having extra zero trust tasks beyond Members, including approving or rejecting another agent's signature key, creating a zero trust recovery file and viewing the history of zero trust keys. Keep two named Super admins.

LogMeIn Rescue technician group permissions

In Rescue, the Technician Group is the unit of privilege. The administrator guide lists permissions that include:

• Remote control and files: Launch remote control, Send files, Receive files and Access File Manager tab (with Manage files).
• Scripts: Script deployment and Run embedded scripts.
• Unattended access: Unattended access, plus Connect On LAN for local network connections.
• Credentials: Request Windows credentials.
• Recording: Record sessions, which can be limited to only with customer consent.
• Collaboration: Transfer sessions, Send collaboration invitations and Invite external technicians, which can be limited to only approved individuals.
• Other: Start private sessions, Allow clipboard synchronization, Reboot, View system information, Screen capture and Use single prompt for all permissions.

Our recommended pattern is tiered groups: first line with remote control but no scripts, unattended access or Request Windows credentials; second line adding file manager and scripts; and a small infrastructure group with unattended access. Set Invite external technicians to only approved individuals, and give administrators Restricted administrator rights unless they genuinely need every tab. In Global Settings, turn on Show Technician Groups only to Assigned Administrators so administrators see only the groups they manage.

Sign-in, SSO and two-step verification

GoTo Resolve

GoTo Admin supports enterprise sign-in with SAML 2.0. GoTo's set-up article describes verifying at least one company email domain in the Organization Center, by DNS TXT record or a file on your web server; verifying the first domain creates your organisation. You then add your identity provider, preferably automatically from its metadata URL, or manually with sign-in and sign-out URLs, bindings, entity ID and public certificate. Supported identity providers named in the article include AD FS, Azure AD (now Microsoft Entra ID), Okta, OneLogin, RSA and SecureAuth. You can ask GoTo support to make enterprise sign-in the only sign-in method; an exclusion list is possible but applies only to Member-role users, so Admins and Super admins always use SSO once enforcement is on. Put your identity provider's MFA, preferably phishing-resistant, in front of the GoTo application. See the SAML Security Guide and the Phishing-Resistant MFA Guide.

The signature key adds a second secret on top of SSO. It must be at least eight characters, GoTo cannot restore a forgotten key, and a new agent who is not the first in the organisation receives a six-digit verification code shown once, which the administrator asks for through a separate channel before approving the key.

LogMeIn Rescue

Rescue users can sign in through the same GoTo organisation SSO, and GoTo points Rescue software SSO to a separate Rescue SSO set-up guide; confirm which applies to your account in GoTo's current documentation. Inside Rescue, Global Settings provide:

• Two-step verification: enforced for selected members; for a Technician Group, set Enforce two-step verification on the group's Settings tab. Administrators can reset it for members of their groups.
• Password policy: Minimum password strength (Good, Strong or Excellent), Maximum password age, Notification before password expires and Admin password changes force user to change password at next logon. Passwords are at least 8 characters.
• IP restrictions: global restrictions grant or deny access to all components by network ID, and Technician Console restrictions are set per Technician Group. Technician Console restrictions do not apply to external collaborating technicians, so control external invitations separately.

Our recommendation: enforce two-step verification on every Technician Group and administrator, restrict the Technician Console to your corporate egress addresses or ZTNA ranges, and use SSO wherever your account supports it. See the Remote Access Identity Guide.

Integrations, API tokens and service accounts

Each connection to another system carries a credential that deserves the same care as a technician account.

• Rescue Active Directory synchronisation: the administrator guide describes AD synchronisation using a service token and a default first-login password that users must change at first login. Deleted or moved AD users are disabled in Rescue rather than deleted. Store the service token in a vault, limit who can see it, and replace it when an administrator who handled it leaves. See the Secrets Management Guide.
• GoTo Resolve user lifecycle: use your identity provider as the source for who holds a GoTo account. Where you provision users automatically, the provisioning credential is a non-human identity with user management rights. See the SCIM Provisioning Guide.
• Ticketing integrations: GoTo publishes apps that start Resolve sessions from service desk tools. Grant the integration the narrowest account available and review it with your other SaaS integrations.
• Zero trust recovery file: the GoTo Resolve recovery file restores zero trust administration if keys are lost. Store it offline or in a vault with break-glass controls. See the Break-Glass Account Guide.

Logging and detection

GoTo Resolve reports and recordings

Session reports show the session key, start and end times, duration, agent name and IP, end user name and IP, session type (attended, unattended or camera share), end user operating system and device type, and session records (notes and accounting information the agent adds, which can link to the recording). Reports export as CSV. Administrators turn on automatic recording in GoTo Admin under Settings, Remote Support, System settings tab; agents can also start and stop recording with chat commands, and the end user is notified when recording starts and stops. GoTo states recordings are available indefinitely, subject to GDPR, and that agents and admins can play back recordings only for accounts they belong to.

LogMeIn Rescue reports

The Administration Center provides a Login Report, an Audit Report (List All), session reports, failed session reports and technician status reports. Recording is set per Technician Group on the Settings tab under Screen Recording: Forced screen recording records all Remote Control and Desktop Viewing sessions. Screen recording location takes a network share, FTP, HTTP or HTTPS server or cloud location, so restrict write and read access to that store, and technician monitoring settings in Global Settings control whether administrators can watch technician desktops, including Notify technician about desktop monitoring.

Export these reports on a schedule (daily is our recommendation) into your SIEM and correlate sessions with tickets. See the SIEM Log Source Onboarding Checklist.

Metrics that show it is working

• Percentage of technicians and administrators covered by enforced SSO or two-step verification (target 100%).
• Number of Super admins or Master Administrators (target two to three named people).
• Percentage of unattended sessions matched to a ticket or change (target above 95%).

Hardening baseline

Rollout steps (NHI Mgmt Group recommendation)

1. Inventory every GoTo Resolve and LogMeIn Rescue account, administrator and technician, including supplier and departmental accounts.
2. Verify your domains and connect SSO; test with a pilot group of technicians before requesting enforcement.
3. Rebuild roles: custom roles in GoTo Admin, tiered Technician Groups in Rescue. Pilot each tier with one team for a week, then move the rest.
4. Roll out zero trust signature keys in Resolve, starting with administrators, and store the recovery file under break-glass controls.
5. Set code validity, permission prompts, time-outs and recording, and announce the changes to the service desk and users.
6. Turn on report exports to the SIEM and build the detections above.
7. Roll back by restoring the previous role or group assignment for affected technicians; keep a record of the old settings before each change.

Small and large organisations

A small IT team can run one account with two top-level administrators, SSO and weekly report review. A large service desk benefits from roles or groups per tier and region, restricted administrator rights and automated SIEM exports. See the RMM Tool Security Guide.

Common misconfigurations

• Every technician in one group or role: first-line staff end up with script deployment, unattended access and Request Windows credentials. Split groups by tier.
• Too many top-level administrators: keep two or three Super admins or Master Administrators and review quarterly.
• SSO configured but not enforced: technicians can still sign in with a local password. Request enforcement and review the Member exclusion list.
• Zero trust postponed: agents keep deferring signature key creation. Set a date and make the administrator approval step part of onboarding.
• Long code validity and no permission prompt: a PIN or link stays usable after the call ends. Shorten validity and prompt at session start.
• Reports never leave the console: session and audit data are only looked at after a complaint. Export them on a schedule and alert on the signals above.

Framework mapping

Practitioner checklist

• Inventory all GoTo Resolve and LogMeIn Rescue accounts, administrators, technicians and integrations.
• Verify domains, connect SAML SSO and request enforcement; keep exclusions to named Member accounts.
• Enforce two-step verification on every Rescue Technician Group and administrator.
• Rebuild privileges as custom roles (Resolve) and tiered Technician Groups (Rescue); review quarterly.
• Roll out zero trust signature keys in Resolve and store the recovery file under break-glass controls.
• Shorten code validity, prompt customers for permissions at session start and set idle time-outs.
• Restrict unattended access, script deployment and Request Windows credentials to the groups that need them.
• Turn on session recording where policy allows and export session, login and audit reports to the SIEM.
• Vault the Rescue AD synchronisation service token and any provisioning credentials.

Standards and references

• GoTo: What is the difference between a role and a permission? (Resolve)
• GoTo: How do I set up zero trust authentication? (Resolve)
• GoTo: Working with reports (Resolve)
• GoTo: LogMeIn Rescue Administrators Guide
• GoTo: How to set up screen recording (Rescue)
• GoTo: Set up enterprise sign-in (SSO) (Rescue)
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• MITRE ATT&CK: T1219.002 Remote Desktop Software

Related NHI Mgmt Group resources: RMM Tool Security Guide · Remote Access Identity Guide · Privileged Access Management Guide · Help Desk Identity Verification Policy Template