Unattended Access Policy: When, Where and Who

Thursday, 22:15, at Ashgrove Housing. Imran is on call, and the overnight rent-processing job on the finance server has failed. He knows because the monitoring alert opened ticket 8104 an hour ago and his phone has been telling him about it since. Nobody is sitting at the finance server. Nobody ever is; it lives in a locked room with two other servers and a label maker. Imran opens the desk's unattended access register on his phone, finds FIN-APP-01, and reads that on-call staff may connect to it at any hour. The register says the finance systems owner approved that. It also says every connection alerts the desk lead and the finance systems owner. He connects, restarts the job, watches it run, writes the session note in 8104, and disconnects at 22:31.

At 22:16, Noor, the desk lead, received a message on her phone: "Unattended connection to FIN-APP-01 by i.malik." She knew about ticket 8104, matched the two in her head, and went back to sleep. Had the message said HR-WS-114, she would not have gone back to sleep. That is the housing officer's workstation on the second floor. That difference is the whole of this article. Unattended access is connecting to a computer with no person at it to accept the connection. The consent that every other remote session rests on cannot be given, because there is nobody to give it. So something has to stand in for it. That something is a written approval, from a named role, for a named device, that alerts somebody each time it is used. This article is part of our Remote Support Tooling series, and it is about the when, the where and the who of that approval.

It covers what unattended access is and why it needs its own rules. Then it covers servers versus workstations and out-of-hours work, planned and unplanned. Next come the approval and what it must say, the alert that every use raises, and the account behind the access and keeping it narrow. The register itself and the quarterly review follow. Then come a decision table by device class, a short war story, and the unattended access register to copy, in that order.

Why Unattended Access Needs Its Own Rules

An attended session has a person at the other end who sees the prompt, clicks allow, watches the cursor and can end it. The whole of Consent, Every Time rests on that person. Unattended access removes them. The connection opens because the device has been set up in advance to accept connections from the desk's tool without asking. From the moment that setting is made, anyone with the right account can reach that device at any time. They can do so whether or not anyone is there and whether or not anyone would have agreed. The convenience is real. So is the fact that you have built a door that opens from the outside.

That door is the most valuable thing an attacker could borrow, which is why the rules are tighter rather than looser. A technician's attended session needs a person to click allow; an unattended path needs only the technician's credentials. If those are stolen, guessed or still known to someone who has left, the unattended devices are reachable with nobody to notice. Every rule in this article is about narrowing that. The rules cover fewer devices, named approvers, a record of each use, an alert to a second person, and accounts that are protected and reviewed. Vendors call the feature "always-on remote management", which is accurate, in the way that "unlocked" is accurate.

The three things unattended access needs can be said in one sentence, and it is the sentence the policy should carry: a reason, an approver, and someone who is told each time it is used. If a device cannot be given all three, it does not get unattended access. If it has unattended access and cannot be given all three, the access is removed. Most desks have more unattended access than they know, and all of it was installed by someone helpful.

Servers Versus Workstations

A server has no user to ask, and that makes unattended access the normal way to reach it rather than an exception. Nobody sits at FIN-APP-01. Its owner is the organisation, represented by whoever is responsible for the finance system. That person's approval stands in for consent. Servers also tend to need attention at the hours when nobody is in the building, which is the point of having on-call staff. So the default for a server is that unattended access is allowed, by named roles, with an approver, an alert and a register entry. The question for each server is not whether but who and when. Servers do not mind being connected to at 22:15. They have no evenings.

A workstation is a person's workspace, and the default is the opposite. Unattended access is not allowed, because the person who would have been asked exists and simply is not there. "Sam's out, I'll just remote on and sort his drives" is an unattended session on a workstation. The chair's silence is not a yes, however convenient the timing. The exceptions are narrow and each needs its own register entry. They include a kiosk in reception, a meeting-room machine, and a shared computer in a workshop or a lab where nobody's personal work lives. Another is a scheduled maintenance window with notice to the user and confirmation that the building is empty. Even for those, prefer a scheduled script to a live session where a script will do. A script does one known thing and leaves a log. A session does whatever the technician decides at the time.

Do not enable unattended access on a workstation "for now". "For now" is the longest period in IT. The workstation that got it for a migration weekend will still have it when its user has moved departments twice. If a one-off job genuinely needs the desk on an empty workstation, do it as a registered exception with an end date. Remove that access when the date arrives. The register has a column for the date for that reason, and the quarterly review is where the column is read.

Out-of-Hours Work

Out-of-hours work comes in two kinds, and they are approved differently. Planned work is the patching window, the migration, the restart that has to happen when nobody is using the system. It is approved as a change, in advance, with a record of what will be done and how it will be undone. That is the business of The One-Page Change Record. The unattended session is how the planned change is carried out; the change record is the reason the session exists. Users are told beforehand, in the form set out in Planned Maintenance Notices. That is also how the desk learns that the finance team is working late on Thursday and would rather the server stayed up.

Unplanned work is Imran's Thursday: something failed, an alert raised a ticket, and the on-call technician needs to reach a server now. The approval for that is the standing one in the register. It says that on-call staff may connect to this device at any hour for incident work. The ticket from the alert is the reason. The desk does not need to wake the finance systems owner for permission at 22:15. The register entry is the owner's permission, given in advance for exactly this. What the owner gets instead is the alert at 22:16, which tells them the approval was used. They also get the session note the next morning, which tells them why. Unplanned work can turn into a change. Restarting a job is not a change, but altering the job's configuration to stop it failing again is. The rules for doing that safely at night are in Emergency Changes.

The out-of-hours session has a particular discipline about its note, because there is nobody to confirm anything with. The note says what the alert was, what was done, and what the system showed afterwards. It also says that the technician checked the job's output rather than assuming it. The note is written before the technician goes back to bed. Overnight notes written the next morning are written by a different person. The person who remembers what the error said has gone to sleep. The one who wakes up does not remember. Write it at 22:31. It is six lines.

The Approval

The approver is the person responsible for the device or the system it runs, not the desk. The desk asks; the owner approves. The distinction matters because the desk approving its own access is a sentence with a problem in it. I noticed this some time after approving my own access to a server I had asked for access to. For a server, the owner is whoever is accountable for the system. Examples are the finance systems owner for FIN-APP-01, the housing systems owner for the tenancy database, the infrastructure lead for the domain controllers. For a shared workstation or kiosk, it is the manager of the area it sits in. For anything nobody owns, the first job is to find an owner, and until then the answer is no.

The approval says six things, and all six go in the register. Which device, by the name the desk and the tool both use. Who may connect, as a role or a group rather than a list of names, so that it survives staff changes: "on-call desk staff", "infrastructure team". It says when, as a window. Examples are "any time, for incident work" for a production server and "the maintenance window only" for a system that must not be touched in the day. Another is "this weekend only" for an exception. Why, in a sentence. Who is alerted on each use, and how. And when the approval will be reviewed, which for standing access is quarterly and for an exception is its end date.

The approval is given in writing, in the approver's own words, and kept with the register. That usually means an e-mail forwarded into the ticket that requested the access, or a reply on that ticket. "Verbal approval from the finance director" is a claim. A line in the ticket from the finance director is a record, and the difference is the one that matters in the review that follows an incident. Approvers tend to be busy and to approve readily when the request arrives with the six things already filled in. A request that says "can we have unattended access to the finance server?" produces a meeting. A request that says "for on-call incident work, any hour, alerting you and the desk lead, reviewed quarterly" produces a yes by return.

The Alert Every Use Raises

Every unattended connection notifies someone who is not the technician making it, at the moment it begins. And this single rule does more to make unattended access safe than any other. Most remote support tools can send a message when a session starts, by e-mail or by a webhook to another system. That is the mechanism; the policy decides who receives it. The recipient is the desk lead at minimum, and for servers the system owner as well. That is why Noor's phone and the finance systems owner's both knew about FIN-APP-01 at 22:16. On a two-person desk the recipient is the other person and the manager the desk reports to. The alert does not need an answer. It needs a reader.

The recipient's job is to match the alert to a reason, and the reason is nearly always a ticket. Noor matched FIN-APP-01 to ticket 8104 in her head, because she knew about the alert that had opened it. When the match is not obvious, the recipient asks within the hour if it is working time and first thing in the morning if not. For example: "I saw you connected to the tenancy server at 15:10; which ticket is that?" Nine times in ten the answer is a ticket number and a mild apology for not having mentioned it. The tenth time is why the alert exists. Where the alert can land as a ticket in the desk's own queue rather than in a mailbox, it becomes visible and assignable. That ticket is closed by linking it to the session's ticket. This is tidier than a folder of e-mails that nobody admits to reading.

The alert also catches the thing the register cannot: a device that has unattended access and should not. If a connection alert arrives for HR-WS-114, which is not in the register, two things are wrong at once. The second is worse than the first. Somebody connected unattended to a workstation, and the workstation was set up to allow it without anyone approving. Both are conversations for today, and the second ends with the access removed and a check of how many other workstations have the same setting. An alert that nobody reads is decoration. One that is read is the only way the desk finds out what it does not know about its own tool.

The Account Behind the Access

Unattended access rests on credentials, and least privilege, the fourth of the five principles, applies to them twice. The technician's side is a named account for each person, protected by a second factor. Its scope reaches only the devices their role needs. On-call staff can reach the servers in the register. The desk's first-line technicians cannot reach servers at all. Nobody's day-to-day account can reach anything unattended without the extra step the tool provides for it. The device's side is whatever the tool installs to accept connections. It should run with the least rights that still let the desk do its work. It should be configured so that only the organisation's own tool and accounts can reach it. It should also be removed from any device that leaves the register.

Leavers are the test. The day someone leaves the desk, their account in the remote support tool is disabled, before their e-mail is, because the remote tool reaches further. If any shared secret exists anywhere in the arrangement, it is changed the same day. Examples are a password on an unattended agent, a code used to enrol devices, a service account the tool uses. Add the remote support tool to the leaver checklist, by name, with a tick box. "Remove from systems" on a checklist means "remove from the systems the person doing the removing remembers". The log review in Logging and Session Records looks for sessions by leavers' accounts for exactly the months when this step was missed.

Keep the number of people who can connect unattended small, and keep the number of devices they can reach smaller. A desk of five does not need five people with unattended rights to every server. It needs two, who are on the rota, and a way to add a third quickly when both are on leave. Rights that exist in case they are needed are rights that exist. The register's "who may connect" column is where the number is counted, and the quarterly review is where it is argued down.

The Register, and the Quarterly Review

The unattended access register is the list of every device that accepts unattended connections, with the six things from the approval beside each one. It also records the last use and the next review. It is the single source of truth for the question "is this allowed?" If a device is not in it, the answer is no, whatever the tool's settings say. (It is a spreadsheet, or a page in the knowledge base. It is fine for it to be a spreadsheet.) It is visible to the whole desk and to the approvers, maintained by the desk lead, and read, in full, four times a year.

The quarterly review is a meeting of one person with the register, the tool's list of unattended-enabled devices, and the staff list. The first job is to compare the register with the tool. Every device the tool will connect to unattended should be in the register. And every device in the register should still exist and still need it. Devices in the tool and not in the register are removed from the tool or added to the register with a fresh approval, the same day. The second job is to read the "last used" column, and to ask of anything not used in two quarters whether it needs the access at all. The third is to read the "review date" column and to remove any exception whose date has passed. The fourth is to check that every approver still holds the role, and every person in the "who may connect" groups still works here.

Write the review's result as a short note kept with the register. Record how many entries, how many removed, how many added, and anything found in the tool that the register did not know about. The last number is the interesting one. On a desk that has never reviewed, it will be large the first time and should fall to zero by the third review. If it does not fall, someone is enabling unattended access outside the process. That calls for a conversation about the process rather than the person. The process is evidently easier to go round than through. Make the register entry the easy path. A form that takes two minutes beats a rule that takes a meeting.

A Decision Table by Device Class

Most of the decisions in the register repeat by kind of device, so write the defaults down once and let individual entries inherit them. The table below is a starting set for a small organisation; your classes will differ. And the point is that each class has a default answer, an approver by role, an alert recipient and a review period. That way, the question "can we have unattended access to that?" is answered by looking up the row rather than by starting a debate.

The last row is the one most often missing, and it is the one the war story is about. Suppliers who install a system frequently install their own way of reaching it, for support, and that path is unattended access by any definition. It belongs in the register, through the desk's tool where possible so that the desk's log and alerts see it. Where the supplier insists on their own path, the register records that, with the alert and the review attached. In that case, it also records the system owner's written agreement that the supplier can reach the organisation's server without asking first. Many owners, asked that question plainly, discover they would rather be asked.

A Short War Story: The Supplier's Door at Northgate Retail

Northgate Retail's warehouse management system was installed by its supplier. The supplier's engineers set up their own unattended access to the warehouse server during the installation so that they could support it. Nobody at Northgate wrote that down because nobody at Northgate had a register to write it in. Long after the installation, on a Tuesday at 03:10, an engineer at the supplier connected to the server. He applied what he later described as a routine patch, which nobody at Northgate had requested, scheduled or been told about. The patch changed the format of the pick-list export so that the morning's dispatch run produced blank labels for every order. The desk spent the first three hours of the trading day treating it as a printer fault, because no alert had told anyone the server had been touched. The desk found the real cause only when a technician called Kemal noticed a service's modified time and asked the supplier whether they had done anything. Four stores received their stock a day late. The regional director was told about the supplier's access for the first time in the same meeting she was told about the delay. The system owner, when asked whether she had approved it, said she had not known it existed. The access was moved to the desk's tool with an alert and a register entry the same week. The policy gained the line Kemal suggested. An unattended path that is not in the register is a door nobody is watching.

The Unattended Access Register

The register below is one line per device, with the six facts from the approval, the last-used date and the review date. It has a block at the bottom for the quarterly review's note. Keep it where the whole desk and the approvers can read it. Fill in a line before the access is enabled rather than after. When a line is removed, keep it in a "removed" section with the date. The question "did that server ever have unattended access?" is one you will be asked. The session note for each use is in the ticket, not here. If you run QuerySolv, that note sits in the ticket's event history with the alert and the fix. In that setup, the register points at the ticket number rather than repeating it.

UNATTENDED ACCESS REGISTER
Maintained by: ______________ (role)   Last full review: ________   Next: ________

ACTIVE ENTRIES
Device: ______________   Class: ______________   System / purpose: ______________
  Approved by: ______________ (name, role)   On: ________   Where recorded: ticket ______
  Who may connect (role/group): ______________
  When: [ ] any hour, incident work   [ ] working hours   [ ] maintenance window only
        [ ] exception until ________
  Why (one sentence): ___________________________________________________
  Alert on each use goes to: ______________ and ______________   By: [ ] e-mail  [ ] ticket  [ ] other ______
  Last used: ________ (ticket ______)   Review due: ________

Device: ______________   Class: ______________   System / purpose: ______________
  Approved by: ______________ (name, role)   On: ________   Where recorded: ticket ______
  Who may connect (role/group): ______________
  When: [ ] any hour, incident work   [ ] working hours   [ ] maintenance window only
        [ ] exception until ________
  Why (one sentence): ___________________________________________________
  Alert on each use goes to: ______________ and ______________   By: [ ] e-mail  [ ] ticket  [ ] other ______
  Last used: ________ (ticket ______)   Review due: ________

(one block per device; copy as needed)

REMOVED ENTRIES
Device: ______________   Removed on: ________   By: ______________   Reason: ______________

QUARTERLY REVIEW NOTE
Date: ________   Reviewer: ______________
  Entries in register: ____   Devices enabled in the tool: ____   Difference explained: [ ]
  Removed this review: ____   Added (with approval): ____
  Entries unused for two quarters, questioned: ____
  Expired exceptions removed: ____
  Approvers and groups checked against staff list: [ ]
  Supplier access paths checked: [ ]
  Notes: _______________________________________________________________

Imran's 22:15 is what the register looks like when it works. There was a line that said yes before the question was asked, an alert that told two people, and a note in 8104 that said why. The desk lead went back to sleep because the message on her phone matched a ticket she already knew about. The rent job ran. The finance systems owner read the note over coffee and replied "thanks", which is the whole of the attention an approved unattended session should need. The ones that need more are the ones the register did not know about. And the point of the register is to run out of those.

Frequently Asked Questions