docs-v2/about/security/zero-trust-networking.mdx

---
title: "Zero Trust Networking"
description: "Why Pangolin encrypts every connection and authorizes by identity rather than trusting the network it runs on."
---

Zero trust networking starts from an uncomfortable assumption: the network your traffic physically travels over cannot be trusted, even the parts you think of as "internal." Access should be decided by who and what is asking, not by which wire or subnet the request happens to arrive on.

## Why the old assumption stopped holding

For a long time, network security was designed like a building: a hardened perimeter - the firewall - kept threats out, and everything inside that boundary was implicitly trusted. VPNs extended that same trusted interior out to remote workers. It's sometimes described as a hard shell around a soft interior.

That model breaks down once you account for how internal networks actually get compromised. Well-documented breaches at major technology companies have shown attackers reaching deep into "internal" infrastructure once they cleared the perimeter once. Add unencrypted internal DNS traffic and employees working from coffee shop Wi-Fi, and the idea that anything inside the firewall is automatically safe stops being credible. If the perimeter is the only thing enforcing security, one gap anywhere in it compromises everything behind it.

## What replaces trusting the wire

The fix is removing the network itself from the trust decision entirely:

- **Encrypt every connection, always**, regardless of whether the traffic is "internal" or "external." There's no privileged segment where encryption gets dropped because it's assumed to be safe.
- **Authorize by identity, not location.** What a connection is allowed to reach should depend on who or what established it, not which subnet it originated from.
- **Contain compromise at the peer.** If a device is breached, restricting which encrypted peers it's authorized to reach means the attacker can't simply pivot to whatever else happens to share that network segment.

Even if someone gains physical or logical access to the network itself, all they find is encrypted traffic between authorized peers - nothing to sniff, and no ability to move laterally without valid credentials of their own.

## How this shows up in Pangolin's architecture

Pangolin is built around this model rather than having it added on top:

- **Every tunnel is encrypted, by default, with no exceptions.** Site connectors and clients build their tunnels on WireGuard, coordinated by Pangolin's tunnel manager ([Gerbil](/development/system-architecture#nodes)) on the node side and the shared client stack ([Olm](/development/system-architecture#shared-client-stack-olm)) on the device side. There's no unencrypted "trusted internal" path anywhere in the data plane.
- **Site connectors are deny-by-default proxies.** Installing a [site](/manage/sites/understanding-sites) doesn't expose anything on that network. Nothing is reachable until you explicitly define a [resource](/manage/resources/understanding-resources) and grant a role access to it - the network being reachable is never itself the authorization.
- **Authentication happens per request, not per network.** Public resources are enforced through forward-auth middleware ([Badger](/development/system-architecture#nodes)) sitting in front of every request, and private resources are only reachable by clients that already hold a valid, role-scoped tunnel - being on the same LAN as a site connector grants nothing on its own.
- **Access follows the user, not the connection point.** [Roles](/manage/access-control/create-user#roles) determine which resources a client is authorized to reach, and that access control list travels with the identity whether they're connecting from the office, home, or a coffee shop.

## Rolling this out without a flag day

You don't need to tear out your existing perimeter to start moving toward this model - it's meant to be adopted incrementally, service by service:

<Steps>
<Step title="Wrap one sensitive service first">
  Stand up a [site](/manage/sites/install-site) alongside your existing network and turn a single high-value internal service into a [private resource](/manage/resources/understanding-resources#private-resource-types). Traffic to it is now encrypted end-to-end and gated by role, independent of whatever perimeter controls already exist.
</Step>

<Step title="Verify access follows identity">
  Confirm that only the intended roles can reach the new resource, and that removing a role actually removes access - not just that the tunnel works.
</Step>

<Step title="Repeat until the subnet is covered">
  Move the rest of the hosts behind that network into resources one at a time. Once everything on that subnet is reachable exclusively through Pangolin, the broader network-level trust it used to rely on (a VPN route, a wide firewall allowlist) is no longer load-bearing.
</Step>

<Step title="Retire the old path and move to the next network">
  Remove the legacy access route for that subnet, then repeat the process for the next site or location.
</Step>
</Steps>

## What you still have to trust

"Zero trust" doesn't mean trusting nothing - it means narrowing what you trust down to a small, deliberate set of components: your identity provider, and the policy engine that decides who's authorized to reach what. In Pangolin, that's the [control plane](/development/system-architecture#control-plane) - the server that authenticates users, evaluates roles against resources, and pushes the resulting access decisions out to every node, site, and client. Everything else - the physical network, the datacenter, the office Wi-Fi - is treated as untrusted by design, which is precisely the point.

<CardGroup cols={2}>
<Card title="How Pangolin Works" icon="diagram-project" href="/about/how-pangolin-works">
  The product-level tour of sites, resources, and clients.
</Card>

<Card title="System Architecture" icon="server" href="/development/system-architecture">
  A technical look at the control plane, nodes, connectors, and clients.
</Card>

<Card title="Understanding Sites" icon="plug" href="/manage/sites/understanding-sites">
  How site connectors expose resources without opening inbound ports.
</Card>

<Card title="Least-Privilege Access" icon="shield-halved" href="/about/security/least-privilege-access">
  Scoping who's authorized to reach what once identity is the boundary.
</Card>
</CardGroup>