![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Jan 5, 2026
\nZero Trust Networking (ZTN) is an architecture descended from Google's\r\nBeyondCorp design.
\nAlthough many products now advertise \"zero trust,\" it is not always clear\r\nexactly what it means. We summarize it this way: zero trust means that you\r\ncan't trust the physical network anymore.
\nTraditional network security has a \"hard crunchy outside, soft chewy\r\ninside.\" In that design, you put a corporate firewall at the edge between\r\nyour \"private\" network and \"the internet.\" But inside the firewall, security\r\nis usually much more lax. If an attacker gets access to the private network, it's\r\ngame over.
\nThat old architecture had been known to be problematic for many years, but\r\nthe Snowden revelations about how they infiltrated Google's and Yahoo's\r\nprivate networks—the famous SSL added and removed here :)\r\npost-it note—brought the problem into focus.
\nGovernments and persistent attackers were actively breaching the physical\r\nnetworks of major corporations. To say nothing of unencrypted DNS, and\r\nwide-open public Wi-Fi in your neighborhood cafe.
\nConceptually, the solution is simple: instead of \"adding and removing\"\r\nencryption at the firewall, put a firewall around every device and every\r\nservice, and ensure that sessions are always encrypted between every pair of\r\nendpoints. Then if an attacker has physical access to the network, all they\r\ncan get is meaningless encrypted packets.
\nFurthermore, even if they get access to one insecure device, that still only\r\ngives visibility into the traffic directly to and from that device. By\r\ncarefully restricting which encryption keys are accepted by each service on\r\nthe network, a zero trust network prevents or dramatically slows down\r\n\"lateral motion\" from one compromised device to the next.
\nEvery security team nowadays would like to migrate to a Zero Trust\r\narchitecture, but it's daunting. Encryption is easy—everything supports\r\nHTTPS nowadays—but deploying certificates and encryption keys is hard.\r\nEven though we call it \"zero trust,\" rolling out a real zero trust network\r\nrequires a lot of trusted components: certificate authorities, identity\r\nproviders, authorization and policy engines, and so on.
\nTo make rollouts simpler, we recommend proceeding in several steps:
\nAt this step, you aren't quite at \"zero trust\": you don't have to trust\r\nthe physical networks in your offices, but you still trust the \"physical\"\r\n(or sometimes virtual) network in your data centers or cloud VPCs.
\nOnce end-to-end encryption is activated on a server, and you've migrated\r\nall traffic to the encrypted link, you'll want to lock down each server\r\nby disabling non-encrypted traffic to that server entirely.
\nFinally, after migrating all the servers on a particular subnet entirely\r\nto the end-to-end encrypted zero trust model, disable the subnet routers for\r\nthat subnet completely.
\nRepeat these steps as necessary for each subnet in each location.
\nNaturally, we recommend gradually deploying Tailscale as part of each step.
\nTailscale is available as a native client app for your users' devices\r\nrunning Windows, macOS, iOS, Android, and Linux.
\nTailscale supports a mesh of subnet routers using any\r\ncombination of IPv4 and IPv6. It minimizes latency by\r\nforming a mesh between all subnets, rather than routing through a central\r\nchoke point.
\nTailscale supports a hybrid configuration of Zero Trust and subnet routes,\r\nmaking it easier to migrate huge networks cautiously and incrementally.
\nTailscale integrates with your corporate SSO and\r\nhandles all issues with login, key distribution, key rotation, packet\r\nfiltering, and access control.
\nYou can read more in How Tailscale Works.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}