// TECHNOLOGY
The costliest mistake in remote access: forgetting to revoke
6 min readnijitech
In remote access, whoever connects holds the same privilege as the person sitting at the machine. The real risk is not the password but not knowing who can still get in.
Full post
When remote access tools get discussed, the argument almost always runs through encryption. Encryption matters, but the problem it solves is narrow: it stops someone listening on the wire from reading the traffic. Most real incidents come not from someone on the wire but from someone whose access was never revoked.
In remote access, whoever connects holds the same privilege as the person sitting at the machine. They open files, install software, delete records. So the question is not “is the connection secure” but “who can connect, and who knows that”.
1. Residual privilege accumulates quietly
An employee joins a project and gets access. The project ends; the access stays. A supplier provides support once and an account is opened; the work finishes, the account remains. None of these is a malicious step — all of them accumulate because none is reversed.
The access most often missed in an inventory
- A departed employee’s account — HR closes the process, technical access stays open
- A supplier account opened for a short piece of work
- The "temporary" administrator account opened during setup
- A shared team account — nobody can tell who used it
That last item poisons the other three: if there is a shared account, then even with a log you cannot say whose entry it is.
2. Without logs, an incident cannot be investigated
When something goes wrong, the questions are fixed: which machine, at what time, who connected, and what did they do in the session? Without a record of all four, the investigation turns into guesswork. Keeping the log costs a few lines; not keeping it costs never being able to explain an incident at all.
3. Least privilege, the most skipped principle
Most support work needs only to see the screen and take a few steps; it does not need full administrator rights. But because tiering privileges is extra work at setup, everyone gets the same level and it stays that way.
Tiering is simple in practice: view only, approved control and full control cover most teams. Three levels is far better than none.
4. Session consent is the user’s own control
A user approving the connection is a matter of trust before it is a matter of security. A setup where someone can connect to an employee’s screen without their knowledge works technically, but it lands heavily inside an organisation. On machines with no user, such as servers, the rule gets relaxed; on personal workstations it should not.
The network layer asks the same question
Remote access usually runs on top of a network layer, and the same question applies there: who is on the network, and who was removed? In a peer-to-peer network where devices connect directly there is no third party carrying the traffic — but the question of who manages the device list does not go away.
In short
Four controls
- Is the access list produced and reviewed regularly?
- Does every session have a who / when / which machine record?
- Is privilege tiered, or is everyone an administrator?
- At which step is a departing employee’s access closed?
All four are process questions, not tooling questions. A good tool makes them easier; none of them solves itself.
From the glossary: End-to-end encryption · Peer-to-peer network