Customer VPN Access: Give Privileged Work Its Own Device

The connection profile says Production, the tunnel comes up, and every window on the desktop can now reach the customer's systems. Nothing in that sequence separated the privileged session from the browser tab next to it. A VPN profile is a name plus a set of routes; the boundary you actually care about is built from device identity, a controlled execution environment and a credential path. Those three are enforced in different places, which is why adding one and skipping the others produces a design that looks compliant and is not.

A profile name is not a boundary

The client applies routes and DNS configuration when the tunnel comes up, and whatever runs on that machine afterwards inherits both.

A name in a dropdown changes what an operator recognises, not what the operating system permits.

Device identity is what the gateway can check

A gateway that supports device certificates or posture checks authenticates the machine as well as the person. That is the layer that can refuse a connection from an unmanaged laptop before anyone types a password. It also gives you something concrete to revoke when a device is lost. Copying one certificate onto three machines removes exactly that property, which is why the certificate lifecycle belongs in the agreement rather than in a shared folder.

The customer decides which of those controls its policy requires, and a supplier-built virtual machine may not satisfy a posture check at all.

Where a VM boundary leaks

A virtual machine keeps customer tools and network state together, and that is genuinely useful. It also depends on its host and on the hypervisor, and several conveniences cross the line: shared folders, clipboard integration, credential agents and host-level management access. A privileged guest on a daily-use host is not independently trustworthy, because the host can observe what the guest does. Treat the VM as a control that reduces exposure, not as a separate security domain.

A dedicated physical device removes the host dependency and adds a maintenance obligation in its place.

Credentials and transfer paths

Use individual, revocable identities per engineer and per customer, and keep them out of personal browser profiles and chat history. Credentials shared by a whole team cannot be attributed, rotated or revoked cleanly. Decide the transfer path for tools, files and diagnostic output before the first session, because ad-hoc file movement is how a boundary quietly stops being one. If two customers must be reached at the same time, get the network and identity separation approved first.

Never bridge two customer networks through one workstation because it was convenient that afternoon.

The agreement that makes it repeatable

Write a short record per customer and keep it where both sides can find it. It should name the approved device or remote environment and who maintains it, the identities permitted, the systems and operations they may reach, the transfer path, and the normal way a session ends.

Five lines that someone reviews when a person joins or leaves beat a policy nobody can apply:

• Approved device or remote environment, with a named maintenance owner.
• Individual user and device identities permitted for support.
• Systems and operations those identities may reach.
• Permitted path for tools, files and diagnostic output.
• Session-ending process and an authorised emergency alternative.

Emergency access without moving credentials

When a control blocks an urgent repair, the exception process is the path, not a second laptop carrying the same credentials. An approved exception records who authorised it, what was relaxed, and when it ends. Moving a credential onto a daily-use machine changes the boundary at the worst possible moment, and it usually stays changed afterwards. The emergency route deserves a rehearsal while nothing is broken.

Then end the session the way the agreement says, and confirm that the access actually stopped.