Choosing and Reviewing the Remote Support Tool

Tuesday, 15:30, at Oakmoor College. Dana, who runs the desk, is in a small meeting room with the finance director and the college's data protection officer. The officer has three questions about the remote support tool. Where does a session go between the technician's screen and the student services computer it is connected to, and who could read it on the way? How long are the session logs kept, and where? And when a technician leaves, how is their access removed? Dana can answer the third, because she did it last month and remembers the screen. She cannot answer the first two. The tool was chosen before she arrived, by a predecessor, because it was free for small teams and took ten minutes to install. Nobody has asked it a question since.

The meeting ends with Dana agreeing to come back in two weeks with answers. And the two weeks turn into the first real review the tool has ever had. Choosing a remote support tool is deciding which product will carry out the five principles in Remote Control Done Securely on your desk. Reviewing it is asking the same questions again, once a year. The review checks that the tool still carries out the principles and that you still need it. The two are one activity on two timescales. Both are done by criteria rather than by name, because the names change and the vendors change their cost models. The tool that was right for a desk of two in one building is often wrong for a desk of four with half the staff at home. This article is part of our Remote Support Tooling series, and it names no products on purpose. The criteria are the point, and they outlast every product that meets them.

It covers starting from the policy rather than the demo and the five criteria in plain words. Then it covers the categories of tool and what each is good at, followed by the security review and who signs it. Next come the trial that tests principles rather than features, the annual check, and retiring a tool without leaving a door behind. A table of categories, a short war story, and the criteria sheet to copy follow, in that order.

Start From the Policy, Not the Demo

The criteria for a remote support tool are already written if the desk has a remote support policy. Every rule in the policy is a thing the tool must make possible or must not make easy. "We ask before every session" needs a tool that prompts the user and cannot be set to skip the prompt on workstations. "Every session is logged" needs a log that the desk can read and export. "Technicians connect only to devices in their scope" needs device groups and roles. Write the criteria down from the policy before you look at a single product. And the demos become a test you are giving rather than a show you are watching. The general version of that discipline, for any help desk purchase, is in Requirements Before Demos. It applies here word for word.

Sort the criteria into must, should and nice before the demos too. Every demo will show you something impressive that is on none of your lists, and you need to be able to say so. The musts are the five principles, each as a testable sentence. The shoulds are the things that make the desk's week easier. Examples are a way to send the user a session link by e-mail, a chat window inside the session, a way to see which devices are online. The nices are everything else, and most of what a demo spends its time on is in that pile. A demo shows the tool on its best day. You are buying the other days.

Involve the person who will sign the security review at this stage, not at the end. On most small organisations that is whoever owns data protection or security. That may be a named officer, a finance director who has the role by default, or the manager the desk reports to. Their three questions are Dana's three questions. If they are in the room when the criteria are written, the review at the end is a formality. If they first see the tool after the desk has chosen it, the review is an argument. The desk loses arguments about security to the person whose job it is to say no.

The Five Criteria in Plain Words

The first criterion is consent. The tool must show the user a prompt before a session on a workstation. It must show an indicator throughout and give the user a way to end the session. It must also let the desk switch off any "connect without prompting" setting for workstations while leaving it on for the servers in the register. Ask to see each of those in the demo, on a real device. And ask specifically whether a technician can bypass the prompt and what stops them. A tool whose answer is "the technician just wouldn't" has given you the answer.

The second is logging. This covers what the tool records for each session and whether the desk can read it without the vendor's help. It also covers whether the log can be exported to a file the desk keeps and how long the tool keeps it. Another question is whether a technician can edit or delete their own entries. The answer to the last should be no. The log does not need to be joined to the ticketing system to be useful. The session note does that work, and the review in Logging and Session Records matches the two by hand. If you run QuerySolv, the note is written into the ticket's event history. In that setup, the tool's log is the independent record you check it against. That is the arrangement the review wants. What matters in the tool is that its half of the record is complete and yours to keep.

The third is encryption and identity. This means every session encrypted by default with no way for a technician to turn it off. It also means a clear answer about whether the vendor's servers relay the session and whether anyone at the vendor could read it. You need confirmation that the tool checks it is connecting to the device it thinks it is. You also need a second factor on every technician account. These are the data protection officer's first question, and the vendor should be able to answer it in a paragraph a non-specialist can follow. A vendor's security page that says "bank-grade" has described a feeling. Ask for the paragraph.

The fourth is permissions. This means named accounts for every technician, roles that limit what each can do, and device groups that limit where each can connect. It also means control over file transfer and clipboard use. The leaver process must be one that one administrator can complete in a minute without the vendor's involvement. This is least privilege made concrete, and it is where free and basic offerings most often fall short. A tool where everyone is an administrator and every device is reachable by everyone is not a tool a growing desk can run safely, whatever its other virtues.

The fifth is the cost model, by which I mean how the charge is calculated rather than what it comes to. Models include per named technician, per technician connected at once, per device, as a one-time licence, as a subscription, or free with limits. Each model suits a different desk. Per concurrent technician suits a desk where five people share support duty but two are ever connecting at once. Per device suits a desk with few staff and many machines. The thing to find out is what the model does to the criteria above. Some offerings put logging, device groups or the second factor in a higher tier than the one the desk would buy. That means the cheap version fails the musts. The wider question of what free and commercial tools really cost a small team is in The Hidden Costs of Free. The short version for remote support is that the costs tend to hide in the second and fourth criteria.

The Categories of Tool

Remote support tools fall into a handful of categories, and knowing which category you are looking at tells you most of what to check. The first is remote control built into the operating system. It costs nothing extra and works well on the office network with a person present. It tends to be weakest on central logging, device grouping and home workers behind a home router. The second is the standalone remote support product, which exists to do this one job. It usually relays sessions through the vendor's servers so that home workers are reachable. It varies enormously on the five criteria depending on the offering. The third is remote control as part of an endpoint management suite. It is strong on device groups and unattended servers because the suite already knows every device. It can be heavier than a small desk wants to run.

The fourth category is the one-off session tool. The user reads a short code to the technician or clicks a link. A session runs, and nothing stays installed afterwards. The one-off tool is excellent for consent, because nothing can happen without the user's action, and for devices the desk does not manage. It is useless for unattended servers, by design, and its logging is often thin. The fifth is screen sharing inside a meeting tool, which is not remote support at all but gets used as it. The user shows their screen; the technician talks. It has no session log the desk controls and usually no way to take control at all. It has no place in the register. It is fine for "show me what you see" and nothing more.

Most small desks end up with two. One is for attended sessions on managed devices and home workers, and one is for servers. Or they use the built-in tool for the office plus a standalone product for people at home. Two tools are not a failure of decision. Two tools with two policies, two registers and two sets of accounts to review are. So the policy names both and treats them as one system with one set of rules. Three tools is where I would start asking why. Tools breed when nobody owns the list, and each one arrives installed on every laptop.

The Security Review

The security review is a written set of questions put to the vendor and to the desk, with written answers. It is signed by the person who owns security or data protection in the organisation. It happens before the tool is bought and again every year. It is not a technical audit; a small organisation cannot audit a vendor and should not pretend to. It is a plain-language record that the right questions were asked and answered. That way, when the data protection officer asks where the session goes, the answer is on a page with a date.

The questions for the vendor are the ones the five criteria raise, asked plainly. Where is session data and the log stored, in which country, and for how long? Is every session encrypted by default, and can anyone at the vendor read a session in transit or a stored recording? How are technician accounts protected, and can a second factor be required for all of them? How does the desk remove a leaver, and how quickly does that take effect? What does the vendor do if they themselves are breached, and how and when would the desk be told? And what happens to the desk's data when the contract ends? A vendor that answers these in a page has probably been asked before. One that answers with a link to a certification badge has not answered.

The questions for the desk are about how the tool will be run. The answers come from the policy and the register. They cover who administers the tool, who can create accounts, and which devices will have unattended access and under whose approval. They also cover who reads the alerts, who reviews the log and how often, and what the leaver checklist says. The reviewer signs when both sets of answers exist and are consistent with the policy. The review needs three people: the one who runs the desk, the one who owns the data, and the one who is willing to say no. On a small desk the last two are often the same person, and the desk should be glad of it.

The Trial That Tests the Principles

A trial of a remote support tool tests the five criteria on your devices with your people. It is scripted in advance so that every candidate is put through the same twelve things. The general shape of a fair trial, with scoring done before the demos and the same scenarios for every product, is in Designing a Fair Trial. Here are the remote support specifics. Run a consent session with a real user who is not on the desk, and watch what they see. Look for the prompt, the indicator, and the end button. Ask them to press the end button mid-session to see what happens. Connect to a home worker through their home router and judge the speed and the encryption answer. Try to connect to a workstation without a prompt and confirm the tool refuses when configured to.

Then test the parts nobody demos. Export the log and open the file; check it holds who, which device, when, and whether files moved. Create a technician account, give it a narrow scope, and confirm it cannot reach a device outside that scope. Remove the account and time how long until it cannot connect. Configure an unattended connection to one test server and confirm the alert reaches the right mailbox or ticket. Check whether a technician can edit their own log entries. Each of those is a must. A tool that fails any of them in the trial will fail it in the year, when the stakes are not a test server.

Score the trial on the sheet at the end of this article, with the evidence beside each line. For example: "tested on Tuesday with Amal from reception, prompt shown, end button worked". A trial without written evidence becomes an impression within a month, and impressions favour whichever demo was most recent. I chose a tool once because its installer was tiny and the demo was quick. It was tiny because it did not log anything, and quick because there was nothing to configure. The sheet would have caught both on the second line.

The Annual Check

The annual check is the security review repeated with the tool in production. And it adds the questions that only a year of use can answer. It takes a morning. It is done by the desk lead with the security owner reading the result. And it goes through seven things in order. Compare the tool's technician accounts with the staff list and disable anything that does not match. Compare the tool's list of unattended-enabled devices with the unattended access register, and resolve every difference. Confirm the log retention is still what the policy says and that the export still works, by exporting. Read the vendor's security notices from the year and confirm any fixes were applied. Re-ask the vendor the review questions, because their answers change when they move their hosting or change hands. Check the cost model against the desk's actual use, because the desk that was three people is now five, or two. And check the policy still describes the tool as it now behaves, because tools change under you.

Write the result on one page and file it with last year's. That makes the trend visible: accounts removed, register differences found, retention confirmed, vendor answers changed. The first annual check finds things, as Dana's did. The sessions were relayed through servers in a country nobody had thought about. The logs were kept for a period shorter than the college's ticket retention, and two former technicians still had accounts. None of it was a crisis. All of it was the kind of thing that becomes one on the day a complaint arrives. The check exists so that the day it arrives, the page already answers it.

The annual check is also when the desk asks whether the tool is still the right one. The honest answer is usually yes, because switching has a cost and the criteria have not changed. It becomes no when the vendor's cost model has moved against the desk or when a must has quietly become a paid extra. It also becomes no when the desk's shape has changed so that the built-in tool no longer reaches staff. Half the staff might now be at home, say. Another reason for no is when the vendor's answers to the review have become vaguer than they were. Any of those triggers a fresh trial, by the same sheet. Every tool's comparison chart has a column of green ticks, produced by the vendor, about the vendor. The sheet is the desk's column.

Retiring a Tool

Retiring a remote support tool is harder than installing it. The tool is on every device and the installation was done one laptop at a time by someone who has probably left. Tools do not leave when you stop paying for them. The agent stays on every laptop, waiting to be useful to someone. And an agent whose vendor account has lapsed or whose administrator has gone is a door nobody is watching. The retirement has five steps, and the order matters.

Export the logs first, while the desk still has an administrator login, and store them for the retention period the policy names. Before you cancel. Not the day after, when they belong to a login you no longer have. Then disable every technician account and remove every unattended configuration, so that the tool can no longer connect to anything even if an agent lingers. Then remove the agent from every device, by whatever means the desk uses to manage software. Check a sample by hand, because the laptops that were off during the removal will still have it. Then update the register, the policy, the home-worker card and the leaver checklist to name the new tool and not the old one. And finally, tell every user what the new tool looks like and that the old prompt should never appear again. From the day of retirement an old prompt on a user's screen is either a laptop the removal missed or someone who is not the desk.

Run the new tool and the old one side by side for as short a time as possible. Never have both able to connect to the same device unattended, because two doors are not twice as safe. If the two tools overlap for a month, the register during that month says which tool each server is reached by. During that month, the alert for each goes to the same person. The month ends with the old tool's accounts disabled and its logs in the desk's own folder. By then, the annual check's file also has a line saying when it went and who confirmed the agents were gone.

A Short War Story: The Free Tool at Westbrook Dental

Westbrook Dental's two-person desk had chosen its remote support tool because it was free for small teams. It had never looked at what "free" left out. That turned out to be the session log and any control over who could connect to what. A receptionist called Amara complained that a technician had connected to her screen during a patient booking. And the practice manager asked the desk for the record of the session. There was none, because the free offering kept no log the desk could read. The technician, Joel, could only say that he thought it had been a different afternoon. The practice manager then asked who else could connect to the reception machines. And the answer, after an afternoon of checking, included a technician who had left eight months earlier. Nobody had been able to remove that account because the administrator login belonged to a predecessor's personal e-mail address. The practice reported the matter to its regulator as a precaution. It spent a week with an outside consultant establishing that nothing had been accessed. It replaced the tool with one that cost money and kept a log. The desk's new criteria sheet has the line Joel wrote on it: free was the cost of the tool, and the review was the cost of free.

The Criteria Sheet

The sheet below is the five criteria broken into testable lines. Each has a must, should or nice marking for the desk to set before the demos. Each also has a pass or fail for each candidate and an evidence column. That column is filled in only from something the desk saw or read, never from a brochure. Use the same sheet for the first choice, the annual check and any later trial. And keep the filled-in copies together so that the desk can see how its answers changed. The bottom block is the security owner's signature and the date, which is the line that turns a comparison into a decision.

REMOTE SUPPORT TOOL — CRITERIA SHEET
Candidate: ______________   Category: ______________   Assessed by: ______________   On: ________
Marking set before demos: M = must, S = should, N = nice

1. CONSENT                                              M/S/N  Pass/Fail  Evidence (seen or read)
   Prompt shown to the user before every workstation session   ____   ____   ______________________
   Visible indicator throughout the session                     ____   ____   ______________________
   User can end the session at any time                         ____   ____   ______________________
   "Connect without prompt" can be disabled for workstations    ____   ____   ______________________
   Unattended access restricted to named device groups          ____   ____   ______________________

2. LOGGING
   Logs who, which device, start, end, attended/unattended      ____   ____   ______________________
   Logs file transfers and raised rights                        ____   ____   ______________________
   Desk can read the log without the vendor                     ____   ____   ______________________
   Log can be exported to a file the desk keeps                 ____   ____   ______________________
   Retention period known and at least ______                   ____   ____   ______________________
   Technicians cannot edit or delete their own entries          ____   ____   ______________________

3. ENCRYPTION AND IDENTITY
   Every session encrypted by default; cannot be switched off   ____   ____   ______________________
   Vendor states plainly whether sessions are relayed and readable ____ ____   ______________________
   Device identity checked; mismatch warning is a stop          ____   ____   ______________________
   Second factor available and enforceable for all technicians  ____   ____   ______________________
   Session data and logs stored in: ______________              ____   ____   ______________________

4. PERMISSIONS
   Named account per technician; no shared logins               ____   ____   ______________________
   Roles limit what each technician may do                      ____   ____   ______________________
   Device groups limit where each technician may connect        ____   ____   ______________________
   File transfer and clipboard can be controlled per role       ____   ____   ______________________
   Leaver removed by the desk in under a minute                 ____   ____   ______________________
   Alert on each unattended connection to a chosen recipient    ____   ____   ______________________

5. COST MODEL
   Model: [ ] per technician  [ ] per concurrent technician  [ ] per device
          [ ] one-time licence  [ ] subscription  [ ] free with limits
   Every "must" above included at the tier the desk would buy   ____   ____   ______________________
   Cost still fits if the desk grows or shrinks by two people   ____   ____   ______________________
   Exit: logs exportable and agents removable at contract end   ____   ____   ______________________

TRIAL EVIDENCE
   Consent session with a real user (name, date): ______________________________
   Home-worker session through a home router (date): __________________________
   Log exported and opened (date): ______________   Leaver test (time to cut-off): ______
   Unattended alert received by (recipient, date): _____________________________

SECURITY REVIEW
   Vendor answers received on: ________   Filed at: ______________
   Reviewed and signed by: ______________ (role)   On: ________   Next annual check: ________

Dana went back to the finance director and the data protection officer two weeks later. She had the sheet filled in for the tool the college already had. The tool failed four musts, two of them on the logging block. The replacement took a term to choose and a month to roll out. And the retirement of the old tool found the agent still on eleven laptops that had been in a cupboard. The data protection officer's three questions are now answered on a page that is re-dated every year. Dana has added a fourth of her own, which she asks the vendor annually. It has so far produced the most useful answers: what changed since last year that you did not tell us about?

Frequently Asked Questions