Zero trust for small teams without buying a whole platform

Most "zero trust" advice is enterprise cosplay.

It assumes you have a security team, a purchasing department, three identity engineers, and a quarter-million dollars to burn on a platform that promises to replace the phrase "VPN access" with "secure access experience."

Small teams do not need that.

They do need to stop treating one big private subnet as a trust boundary.

That is the real shift. Zero trust is not a product category. It is a design rule:

• every user is identified
• every device is identified
• every resource has an explicit access path
• broad network reach is the exception, not the default

If your current model is "join the VPN, now you can see half the company," you are not missing a buzzword. You are missing segmentation.

The mistake small teams make

The usual progression looks like this:

1. Put everything in a VPC or office LAN.
2. Add a VPN so remote people can get in.
3. Hand engineers, contractors, and support staff the same client.
4. Hope ACLs, security groups, and good intentions do the rest.

That model works until it does not.

The problem is not encryption. The tunnel is usually fine. The problem is the size of the blast radius after authentication succeeds.

A browser-only internal wiki does not need the same access path as production SSH. A contractor debugging a staging app does not need sight lines into every RFC1918 subnet you own. A finance person opening a dashboard does not need a layer-3 route to your Kubernetes nodes.

Zero trust starts when you stop pretending those are the same problem.

What a small-team zero-trust stack actually looks like

For most teams under 50 people, the sane shape is:

• a mesh network for engineer-to-machine access
• an application proxy for browser-based internal tools
• split DNS for internal names, not full-tunnel DNS for everything
• subnet routers only for legacy devices or entire networks that cannot run agents
• strong identity at the edge of every access path

That is already enough to be dramatically better than "flat VPN plus vibes."

Rule 1: identity first, IP second

You want access decisions tied to users and groups, not to the fact that a packet arrived from 10.0.0.0/8.

This sounds obvious, but plenty of teams still gate internal services with lines like "allow all traffic from the VPN subnet." That is not identity. That is a location guess.

The better model is:

• the user signs in with SSO or a local identity system you actually control
• the device joins a mesh or proxy with its own key material
• access policy is applied on top of that identity pair

This is why products like Teleport Application Access and agent-based meshes keep winning over old client VPNs. They let you ask, "who is this, and what exactly should they reach?" instead of "did they make it onto the inside?"

Rule 2: default to app access, not network access

If the target is a web app, expose the app.

Do not expose the subnet behind the app unless you genuinely need raw network reachability.

This is the cleanest small-team win because it removes whole categories of accidental access:

• no lateral browsing of adjacent services
• no mystery ports reachable "because the VPN is up"
• no reason to dump every non-engineer into the same private network

Teleport's docs are explicit that its Application Service is about putting role-based access controls, labels, and audit logging in front of specific apps. That is the right instinct. Protect the resource, not the whole neighborhood around it.

Use the mesh only where application-level brokering is not enough:

• SSH
• databases
• Kubernetes
• internal APIs and services that need direct client reachability

Rule 3: route only what you mean to expose

A surprising number of teams move to a mesh product and then rebuild the same old flat VPN inside it by advertising giant routes.

Do not do that.

Tailscale's own route injection docs make the layering clear: routes and access controls are different things. A route determines what is reachable; policy determines what is allowed. If you advertise half your environment, you have already made the possible blast radius much larger before policy even enters the picture.

For small teams, this means:

• prefer per-node access where an agent can run
• advertise only the subnets that truly need a router
• approve routes deliberately
• avoid 0.0.0.0/0 unless you are intentionally building an exit-node path

If you need a printer, a NAS, or an office-only DNS server, a subnet router is reasonable. If you are advertising three VPCs and two office LANs because "it was easier," you are backsliding into legacy VPN design.

Rule 4: DNS should help segmentation, not erase it

Good internal DNS makes zero trust easier because it lets users reach the right thing by name without exposing everything by network habit.

Bad internal DNS does the opposite. It encourages teams to push one internal resolver for all queries and then wonder why laptops behave strangely off-site.

The better pattern is split DNS:

• public resolvers stay public
• internal zones route only where needed
• overlay node naming stays separate from private corporate zones

That is why systems like MagicDNS and NetBird's internal DNS guidance are useful, but they are not interchangeable. Overlay naming solves "how do I reach known mesh nodes?" Split-horizon DNS solves "how do I resolve internal application names and AD zones without mangling everything else?"

Keep those as separate design problems and your network gets much easier to reason about.

Rule 5: broad admin access should be short-lived

Permanent standing access is usually a laziness tax disguised as an ops convenience.

For a small team, you do not need a giant privileged-access-management program to improve this. You just need better defaults:

• separate admin groups from general engineering groups
• require an explicit path for production access
• log every privileged session or privileged proxy request
• revoke contractor and emergency access aggressively

If your current answer to "who can SSH to prod?" is "everyone who is on the VPN and knows the hostname," your problem is not tooling. Your problem is policy shape.

A practical rollout in 30 days

If you are starting from a flat VPN, do this in order:

Week 1: inventory access paths

List every internal thing people use:

• web apps
• SSH targets
• databases
• Kubernetes clusters
• office-only devices
• DNS zones

You cannot segment what you have not named.

Week 2: separate apps from networks

Move browser-based internal tools behind an application proxy. Leave raw network access only for workloads that genuinely need it.

Week 3: shrink advertised routes

Replace giant route announcements with smaller, intentional ones. If a device can run an agent, stop hiding it behind a routed subnet just because that is how the old VPN worked.

Week 4: clean up identity groups

Create real access groups:

• eng
• prod-admin
• contractor-staging
• finance-apps

Then map resources to those groups instead of handing out one universal "internal" path.

That is already a meaningful zero-trust migration.

What not to buy yet

You probably do not need, on day one:

• a giant SASE contract
• full NAC theater
• endpoint posture gates on every login
• a new VPN plus a new app proxy plus a new IdP all in the same week

Small teams lose months by trying to perfect architecture before shrinking trust boundaries.

Start with the boundaries.

The RouteHarden opinion

For small teams, zero trust is mostly about refusing to expose whole networks when a narrower path would do.

Use a mesh for engineers. Use an app proxy for internal web apps. Route only the subnets that truly need routing. Keep DNS split and boring. Make admin access explicit and visible.

That will get you most of the security value people are supposedly buying from "zero trust platforms," without rebuilding your company around a vendor slide deck.

If you want the practical next step after this, read Teleport application access versus VPNs, split DNS for internal services, and site-to-site WireGuard for small offices.