VPN Access and 18 USC 1030: Permissions, Not Labels
A VPN changes an address, not an authorization. Separate the connection, the permission you were given, and the law governing the activity.
"Are VPNs legal" cannot be answered without naming an activity and a jurisdiction. An employee reaching an approved company service, a customer working around a regional restriction, and a visitor opening a system they were told to leave carry different permissions and different rules. The tunnelling software is identical in all three cases. Almost nothing else about them is.
Three questions that do not collapse into one
Start with the connection: what traffic does the tunnel carry, and which organisation operates each end? Then the permission: which account, which resource and which actions has the owner authorised, and what restrictions or notices came with that? Then the framework: which jurisdiction governs the activity, the agreement and any proposed consequence?
Changing the exit address can change the address a service receives. That is the whole of the change: no agreement is amended, no entitlement appears, and no court has characterised anything. Reconnecting successfully proves the tunnel works and nothing more.
Nor is a service's refusal a legal ruling in the other direction. A website blocking a connection is a policy decision, and treating that as a verdict on legality confuses the same two layers from the opposite side. The layers interact, but neither converts into the other. Keeping them apart is what makes the rest of the discussion useful.
What the statutory example actually describes
The statute at 18 USC 1030, usually called the Computer Fraud and Abuse Act, covers specific conduct involving protected machines. Subsection (a)(2), for instance, is about deliberately reaching such a machine without permission, or going beyond the permission granted, and taking defined kinds of information in the process. The text cited here is the official compilation through 20 October 2026.
Notice what that sentence does and does not do. It names conduct and conditions; it does not announce that VPN use is prohibited. It also cannot tell you whether a particular change of IP address amounts to reaching a computer without permission, because that conclusion depends on facts and on how the provision is interpreted.
Subsection (g) adds a civil-action route with its own conditions. Criminal liability, a statutory civil claim and a service suspending an account are three separate outcomes, and none follows automatically from another. Nothing in this summary settles which of them, if any, fits a given case.
That is also why the example is bounded. It covers selected provisions, not every case, prosecution policy or other country's law. Turning a headline about one old dispute into a rule for all services and jurisdictions is the exact error that the three-question split exists to prevent.
Agreement, access and remedy are different
For any concrete question, collect five things: the version of the terms in force, the permission that was granted, any notice or restriction that came with it, which account is involved, and a precise description of what is being done. A claim about residence, a question about automated requests and a request to administer a private machine raise separate issues, and folding them into one category produces bad advice.
For a mistaken classification, use the service's supported correction or exception process. For an organisational requirement, get the resource owner to approve a suitable route. The exception should set out what is permitted rather than quietly altering an account's identity or location claims to fit a check.
If the outcome could matter, hand the specific facts to counsel qualified in the relevant jurisdiction. Do not assume that suspension is the only possible result, and do not assume that accepting a service's terms makes every clause and remedy enforceable either.
What to put in front of a reviewer
Write the situation down so another person can evaluate it without guessing:
| Question | What to record |
|---|---|
| Who owns the resource? | Company, service or individual, with contact |
| What were you allowed to do? | Account, entitlement, written exception |
| What restriction applied? | Notice, terms version, technical block |
| What exactly will you do? | Activity, frequency, data touched |
Those rows turn a vague worry into a reviewable question, and they show which layer a dispute is really about. A disagreement over the terms is not the same as a disagreement over authorisation, and neither is the same as a question about a statute. Naming the layer first saves everyone a meeting.
State the limits of the answer as well. A summary of one provision is not legal advice for a particular person, and the fact that a tool is widely used does not establish that a specific use is permitted.