Using a Public Computer With a VPN: What to Check First
A tunnel protects the path, not the machine at either end. Decide who controls the host, what stays on disk, and how to revoke before you sign in.
Borrowed machine, urgent task, and a VPN client that promises to encrypt everything: the sequence feels safe and is not. A tunnel protects the path between two endpoints, and the endpoint in front of you is the part you cannot verify. Three steps below decide whether the device is usable at all, how to keep credentials off it, and what to do afterwards so a temporary session does not become a permanent copy.
The tunnel starts after the host has already seen the data
Encryption happens at the VPN client, which runs as a program on the machine. Everything above that program, including the browser, the operating system and any extension or driver with sufficient access, handles your data before it is encrypted. That is not a flaw in the protocol; it is where the protocol sits.
Checking the exit address therefore proves almost nothing about the host. A machine can route all traffic through a clean exit and still log every keystroke, and the two facts are not in tension.
The useful framing is to ask what the host can observe rather than what the network can. On a machine someone else administers, that set is larger than you can enumerate.
Step one: establish who controls the device
Control is a question about administrative rights and physical access, not about politeness. If another person can install software, load a driver, attach a device or restore an image, the machine's behaviour is not something you can establish by looking at it. Administration is a capability, and capabilities do not show up in a screenshot. Ask the person who handed you the machine.
Look for the ordinary signals, and treat each one as evidence about control rather than proof of safety. None of them is decisive on its own.
- A guest or kiosk account that cannot install software is a better starting point than an administrator account someone handed you.
- A managed device with a known owner and a support contact is better than an unattended terminal, even when the terminal looks cleaner.
- A machine where you cannot determine who logged in last is a machine whose state you cannot describe.
None of these checks makes a shared host trustworthy. They tell you whether the risk is bounded enough to continue with a limited task, which is a different and more honest question. Record the answer before you continue.
Step two: keep credentials off the host
A live profile is not a bookmark. An OpenVPN profile may contain inline certificates and a private key, and importing it writes that material to a device you do not own. The same is true of a browser session that stores a cookie, and of any password manager that caches a vault locally.
| Decision | Safe default | What it buys you |
|---|---|---|
| Which device to use | One you control, or an approved managed device | A host whose software you can account for |
| Which account to sign in with | A session that does not persist, with a second factor | Limited exposure if the machine retains state |
| What to install | Nothing; use the browser and the service's own portal | No profile or client left behind for the next user |
| What to do afterwards | Sign out everywhere and revoke sessions from a trusted device | An end to access that does not depend on local cleanup |
Prefer the least persistent access the service supports. A web portal that authenticates per session and requires a second factor leaves less behind than a desktop client with a saved profile, and a session that ends when the browser closes is better than one that survives a reboot.
Then check what the machine keeps. On a shared Linux host the profile location is easy to inspect, and on Windows the equivalent search takes one command. Finding a previous user's profile is a useful reminder that yours would be treated the same way.
ls -la ~/.config/openvpn 2>/dev/null
Get-ChildItem -Path $HOME -Recurse -Filter *.ovpn -ErrorAction SilentlyContinueStep three: end access from somewhere you trust
Cleaning up locally is worth doing and is not sufficient. Sign out of the service, close the browser, remove any downloaded file, and then perform the step that actually matters: revoke the session or the credential from a device you control.
That last action is the one people skip, because the local screen looks clean. A session token copied by software on the host keeps working after you walk away, and it does not care that the browser was closed. Revocation is the only step that assumes the host may have been hostile. It is also the only one that still works if it was.
If a private key or recovery secret touched the machine, treat it as exposed and rotate it rather than inspecting for copies. For an account that used a second factor, also review the devices and sessions listed by the provider, because a token issued during your visit may still be active.
Write the outcome down while it is fresh: which device, which account, what was installed, what was revoked and when. That note is what lets the next person answer the only question that matters afterwards, which is whether anything still has access.
A privately controlled device still needs maintenance, and it gives you a basis for managing the endpoint that a borrowed terminal never will. The tunnel was the easy part.