CONTRACTOR REMOTE ACCESS: WHERE COMPANIES LOSE CONTROL

Consider this scenario: a contractor has finished configuring the equipment, everything is working, and the service request has been closed. But the account remains active. Months later, it can still be used to connect to the system.

We continue the iQ-Solutions cybersecurity expert series with a closer look at why temporary access can remain active after work is completed - and what companies using remote support should check.

The reason can be quite ordinary. The service team accepted the work and closed the request, but a system administrator is responsible for deactivating the account. The administrator was never notified. The work is complete, yet access remains available because the two actions were not linked within the same process.

This gap is easy to overlook. That is why, when granting access, it is important to define its duration and assign responsibility for closing it. For a one-time configuration task, access can be limited to the agreed period. If a contractor provides ongoing support, permissions should be reviewed in light of current tasks and changes to the contractor’s team. A person may have moved to another project or left the company, even though the service contract remains in effect.

The next question is what the specialist is actually allowed to do. Someone who needs to review logs on one server does not need administrator privileges across an entire network segment. Yet the approved request and the actual configuration may differ. Companies should compare the permissions that were approved with those that were granted.

It also matters whose account is used. When several specialists share one login, the logs may show that a connection was made, but identifying the individual who performed the work becomes more difficult. Individual accounts help link actions to a specific user. Multifactor authentication makes it harder to sign in with a stolen password, but it does not address excessive privileges.

The contractor’s device is another consideration. Before a connection is established, the company should determine which computers may be used and how their security requirements will be verified. Even a properly configured account does not eliminate risks associated with an infected or lost laptop.

“We use a VPN for everything” answers only part of the question. A VPN protects the connection. The resources a user can access, the actions they are permitted to perform and the duration of their access are determined separately.

Logs require similar attention. A record showing a login at 14:05 confirms that a user connected, but it says nothing about changes made to the configuration. If a fault occurs after maintenance, an investigation may require records from the target system, a change history and, in some cases, a session recording. It is better to establish in advance whether the available records are sufficient to reconstruct the work and who will review them.

In an operational network, the production context adds another layer. The timing and scope of remote work should be agreed with the people responsible for operations, as configuration changes can affect equipment. The process for terminating access also needs to be considered. Who is authorised to end a session? Who should be contacted at night? If a configuration is being updated at that moment, the team on duty needs to understand the consequences of an interruption and follow an agreed procedure.

An initial review does not have to cover every connection at once. Take one completed service request: compare the approved permissions with those still in effect, review the session history and find out what happened to access after the work was accepted. Was it closed? Or was it retained for ongoing support, with a designated owner and a review date?

The review should produce a concrete result. For example, the completion notice may not have reached the administrator, an access expiry date may not have been specified, or access may still belong to someone who is no longer involved in the project. For each gap, the company should identify what needs to change in the process and who is responsible.

Acceptance of the work and closure of access should be linked. This allows the company to use remote support while retaining a clear view of who is authorised to connect to its systems after each task is completed.