But first – do you really need unattended? 

A door with even the strongest lock is still less secure than no door at all.​ Rescue operates in such a way that in many cases, not only is unattended access not necessary, you don’t even need to download an application on a device.  Instead of downloading an application, Rescue uses a temporary applet with full functionality so you can run admin tasks, without having any way to access a device again after the session has ended.  

In the cases where unattended access is required, there are a few ways you can protect your account with Rescue.  

Mitigating Example 1

Example scenario 1 only works if the remote support tool operates via a reusable User ID and password, whereby sharing those credentials with an agent grants access to your computer.  

Rescue works differently. For one, the unattended installer is account specific, meaning it can’t be used to set up unattended access for another account.  Additionally, to set up unattended access, you would need to enter credentials of the device itself (as opposed to the credentials of the remote support tool), and the end user would need to accept the connection. Not only do credentials often have much more stringent controls than an average application, this also means that it’s impossible for one Rescue account to get unattended access to a device without the end user approving it first.  

There are two ways a technician can log in to an unattended device 

1. 1. 1. 1. Entering the end user’s credentials during setup. In this instance, the unattended access is limited to two weeks 
         2. Entering administrator credentials for the device at the start of every session.  

In both cases, the end user needs to approve the request to set up unattended access for this specific Rescue account. You can also set up time restrictions for unattended access to further restrict the number of days a device is available, and even a range of hours in a given day or days in a given week. 

Mitigating Example 2 

Though following the guidelines in module two would ideally prevent your Rescue credentials from being compromised, you still may want to implement a more zero-trust strategy for unattended access. You can do this by requiring admin credentials at the start of every session.  

An added benefit of enabling this feature is that even if someone were to get your Rescue credentials, and via social engineering were able to convince an end user that they were legitimate, the end user would not be able to give them access to their device if they weren’t administrators.