Contractor access without a flat VPN

Contractor access is where lazy network design becomes visible.

A full-time engineer with broad internal reach is already a risk decision. A contractor with the same reach is a confession that nobody wanted to build a narrower path.

That is why "just give them the VPN" is such a bad default.

It solves onboarding speed by creating a much larger trust problem than the job usually requires.

Start with the access path, not the person

The right first question is not "what VPN account should we create?"

It is:

What exact thing does this person need to touch?

Usually the honest answer is one of these:

• one staging web app
• one support dashboard
• one SSH path to one environment
• one ticketing or admin workflow

Very rarely is the real answer:

• broad reach to multiple private subnets
• the same lateral visibility as full-time infrastructure engineers

If you grant the second when the need was the first, you did not simplify access. You just skipped the design work.

The safer patterns

For contractors, the safe order of preference is usually:

1. application access to a specific internal tool
2. one tightly scoped SSH or bastion path
3. one narrowly routed network segment
4. broad VPN access only as a last resort

That order matters because every step down the list increases the amount of private infrastructure the user can even see, regardless of what you intended them to do.

Why app access is usually best

If the work happens in a browser, use an application-aware access layer.

Teleport's application access model is a good example: the resource is enrolled explicitly, access is policy-driven, and the user is not dropped into a general internal network just to open one URL.

This is ideal for:

• agency designers reviewing a staging site
• outsourced support staff opening one dashboard
• auditors reading one internal portal
• finance vendors using one reporting tool

The less network they can see, the better.

When SSH is necessary

Some contractors really do need a shell.

When that is true, you still want to avoid the "VPN plus every hostname in Confluence" model. Give them a single, explicit admin path:

• one bastion or mesh identity
• one environment
• one documented access window
• one audit trail

That is a much more defensible shape than "here is the company VPN and a CIDR map."

If you need to expose SSH at all, pair it with the same hardening you would want for staff access. SSH hardening for bastions does not become optional just because the user is external.

Group design matters more than the client

A surprising number of teams obsess over which VPN or mesh client to use and never fix the group model underneath it.

For contractor access, your groups should look obviously narrow:

• contractor-staging-web
• vendor-finance-portal
• agency-content-cms
• external-support-readonly

They should not look like:

• vpn-users
• engineering
• internal

If your groups are broad, your access will become broad, no matter how pretty the client UI is.

Time-bound access should be real, not aspirational

Contractor access should expire.

That means:

• defined start and end dates
• no permanent reusable accounts "for next time"
• no shared logins
• no dormant access that survives the project because nobody wants to own cleanup

You do not need enterprise theater to do this. A calendar entry and an offboarding checklist are already better than what many teams actually do.

The important part is that someone owns the expiration.

Logging is part of the access grant

If you cannot later answer:

• who logged in
• which resource they used
• when they used it

then the access was not really controlled. It was merely tolerated.

This is one reason app-aware systems and audited bastions are better than generic network tunnels for outside users. The access path itself is more visible.

The VPN model tends to produce logs like "user connected." The better models produce logs like "user accessed this app" or "user opened this privileged session."

Those are very different incident-response starting points.

The worst contractor anti-patterns

• Shared vendor accounts
• One VPN group for all third parties
• Permanent access for "future projects"
• Broad subnet routes because narrowing them seemed annoying
• Production reach when staging would have been enough
• Letting the contractor's need define your long-term network shape

These are all common. None of them are necessary.

A simple playbook

For each contractor request:

1. Name the exact resource.
2. Decide whether it is an app, a shell, or a network segment.
3. Create a dedicated group for that access only.
4. Set an expiration date.
5. Verify the access path is logged.
6. Remove it when the work ends.

That playbook is boring, which is why it works.

The RouteHarden opinion

Contractors should almost never land on the same broad private network your staff uses.

Give them the narrowest possible path to the exact thing they need:

• app access first
• bastion or mesh access second
• routed network access only when nothing else works

The right design goal is not "make onboarding easy."

It is "make the minimum necessary access easy."

Those are not the same sentence, and confusing them is how small teams accidentally hand outside users a map of the whole company.