Temporary Vendor Access Is Rarely Temporary: A Practical Control Checklist

A vendor needs access to fix one issue.

A VPN account is created. A local administrator password is shared. A remote-support tool is installed. The ticket is closed a few days later, but nobody is clearly responsible for removing the access.

That is how temporary access becomes part of the permanent environment.

The problem is usually not the decision to involve a vendor. External support is a normal part of running IT. The problem is treating access as a technical switch instead of a controlled workflow with an owner, scope and end time.

Start with six questions

Before access is granted, the request should answer:

1. Who needs access? Use a named identity wherever possible. A shared “vendor” account makes ownership and investigation harder.
2. Why is access needed? Link the request to a ticket, change, incident or approved project.
3. Which systems are in scope? Name the approved targets rather than opening a broad network path.
4. What actions are required? Viewing logs, restarting a service and changing production configuration are different levels of privilege.
5. When should access begin and end? An expiry time should be part of the request, not an optional clean-up task.
6. Who owns the decision? Someone inside the organisation should approve the access and remain responsible for reviewing it.

If these questions cannot be answered, the access request is not ready.

MFA is necessary, but it does not define scope

MFA should be required for remote and privileged access. CISA recommends MFA for remote access and administrative accounts, with phishing-resistant methods preferred where they are available.

MFA confirms that the person has presented more than one factor. It does not decide whether that person should reach every server, retain access for six months, or use the same privilege for an unrelated ticket.

Identity, scope, time and approval still need to be defined separately.

Give access to the resource, not the whole environment

Traditional remote access can place a user inside a network and leave other controls to decide what happens next. A better design starts with the resource the person actually needs.

NIST SP 800-207 describes access decisions around users, devices and individual resources rather than assuming trust from network location. It also calls for least-privilege, per-session access.

For a vendor workflow, that can translate into:

• One named account for the assigned technician
• Access to the approved system or application only
• The minimum privilege needed for the task
• MFA before the session begins
• A defined session or account expiry
• Reauthentication when a new session is required

This is more useful than granting a broad path and relying on everyone to remember its original purpose.

Make expiry part of provisioning

“We will remove it later” is not a control.

The expiry should be created at the same time as the access. If a maintenance window ends at 6:00 PM, the approved path should not remain available indefinitely. If the work needs to continue, the extension should be reviewed and recorded.

A simple lifecycle looks like this:

1. Request: Record the technician, business reason, systems, privilege and required window.
2. Approve: Assign an internal owner and confirm that the scope matches the work.
3. Provision: Create the identity, enforce MFA and restrict the reachable resources.
4. Observe: Retain useful session, authentication and administrative evidence.
5. Expire: Disable the access automatically at the agreed time.
6. Review: Confirm whether the work was completed and whether any extension is justified.
7. Revoke: Remove accounts, credentials, tools and group memberships that are no longer required.

The workflow matters because vendor access can exist in more than one place. Closing a VPN account does not remove a local account. Removing a remote-support tool does not rotate a password that was shared during troubleshooting.

Keep evidence that can answer a real question

Logging everything is not the same as having useful evidence.

For each vendor-access event, an organisation should be able to determine:

• Who approved the access
• Which identity was used
• Which device or endpoint initiated the session
• Which systems were reached
• When the session started and ended
• Whether privileged actions were performed
• Which ticket or change authorised the work
• When the access was reviewed, extended or revoked

This does not require turning every support session into a large compliance exercise. It requires enough evidence to explain what happened without relying on memory.

A short audit for existing vendor access

Start with the access that already exists:

• List active vendor, contractor and support accounts
• Identify accounts with no named internal owner
• Check for shared credentials and local administrator accounts
• Review VPN groups, firewall rules and remote-support tools
• Find accounts with no expiry date
• Confirm that MFA is enabled where supported
• Compare current access with active contracts, projects and tickets
• Remove access that no longer has a valid business reason
• Set a review date for what remains

Do not wait for the next incident or audit to discover an old support path.

Where ControlIT fits

ControlIT helps Computer Port provide encrypted access to approved internal systems with identity checks, MFA, endpoint context and technician visibility. The objective is to connect support access with an operational record: who requested it, what was approved, which systems were involved and when the access should end.

If your organisation is reviewing vendor access, remote support or third-party administration, explore ControlIT and start with the access paths that are currently open.