Zero Trust Networking Explained

Why the perimeter model stopped working

The perimeter model assumed that users, servers and data all lived inside one building or data center. That assumption has weakened in several ways:

• Work moved outside. Staff work from home and on the road, and many applications are SaaS services that never touch the corporate network.
• VPNs extend the inside. A classic remote-access VPN places the user's device on the internal network, often with reach to far more systems than it needs.
• Attackers move sideways. Once a phishing email or a stolen password gives an attacker a foothold, a flat internal network lets them scan and reach other systems. Many ransomware incidents spread this way.
• Devices multiplied. Printers, cameras, building systems and personal phones share the same networks, and many of them cannot defend themselves.

The term "Zero Trust" was popularized by Forrester analyst John Kindervag around 2010. Google's BeyondCorp project, described publicly from 2014, showed it working at scale by moving employee access to internal applications off the VPN and onto per-request checks of user and device. NIST then defined a vendor-neutral architecture in SP 800-207 in August 2020.

How a Zero Trust access decision works

NIST SP 800-207 splits every access decision into a small set of logical parts. They may live in one product or many, but the roles are always the same: something decides, something enforces, and the decision draws on as many signals as the organization can collect.

The Policy Engine makes the decision, the Policy Administrator carries it out by configuring the enforcement point, and together they form the policy decision point. The policy enforcement point is whatever sits in the path: an identity-aware proxy in front of a web app, a ZTNA gateway, a switch port running 802.1X, or an agent on the device itself. The same decision can be made again at any time, so a device that falls out of compliance or an account that starts behaving oddly can lose access mid-session.

The seven tenets in plain language

SP 800-207 lists seven tenets. Paraphrased, they are:

1. Every data source and computing service is a resource to protect, including personal devices that reach enterprise data.
2. All communication is secured the same way, whether it crosses the internet or the office LAN.
3. Access to each resource is granted per session, with the least privilege needed for the task.
4. Access is decided by dynamic policy that can use the user's identity, the device's state, the application and behavioral or environmental signals.
5. The organization monitors the integrity and security posture of every asset it owns or that connects to it.
6. Authentication and authorization are dynamic and enforced before access is allowed, then re-checked as conditions change.
7. The organization collects as much information as it can about assets, network traffic and access requests, and uses it to improve policy.

None of the tenets ban firewalls, VLANs or VPNs. They change what those tools are for: network location becomes one signal among many instead of the reason to trust a connection.

The pillars of a Zero Trust program

CISA's Zero Trust Maturity Model, version 2.0 from April 2023, groups the work into five pillars, each moving through four stages: Traditional, Initial, Advanced and Optimal.

Three capabilities cut across every pillar: visibility and analytics, automation and orchestration, and governance. In practice that means central logging, policy that can be changed in one place, and someone accountable for both.

Three ways to build it

SP 800-207 describes three broad approaches. Most real deployments mix them.

• Enhanced identity governance. The identity provider is the policy engine. Single sign-on and conditional access check the user, device and risk before each application session. This is where most organizations start, because SaaS applications already work this way.
• Microsegmentation. Workloads or groups of workloads sit behind their own enforcement points, such as host firewalls or switch and hypervisor policies, so a compromised server cannot reach its neighbors. On campus networks, 802.1X and MAC Authentication Bypass place each device in the right segment as it connects.
• Software-defined perimeters. Applications are hidden behind a broker that only builds a connection after the user and device are verified. This is the model behind most ZTNA products.

Each approach needs a strong way to identify devices as well as users. Device certificates are the most common answer, because a private key stored in hardware is much harder to copy than a password or a MAC address.

Where DNS fits

DNS is both a signal and a control point in a Zero Trust design:

• Protective DNS. A resolver that blocks known malicious domains stops many threats before a connection starts, as described in DNS Firewalls and Response Policy Zones.
• Encrypted DNS to a trusted resolver. If devices use DNS over HTTPS or TLS to the organization's own resolver, queries cannot be read or changed on untrusted networks, and the enterprise still sees them. DoH vs DoT vs DoQ compares the options.
• Private names for private apps. ZTNA clients often resolve internal hostnames through their own tunnel or a split DNS view, so internal names never need to be published publicly. Split-Brain DNS covers the trade-offs.
• DNS logs as telemetry. Query logs show which devices look up which domains, which feeds the activity signals the policy engine relies on.

When a policy engine or protective resolver flags a suspicious domain, Website Recon shows when it was registered, by whom, and whether it imitates a domain you know.

A practical order to adopt it

There is no single correct sequence, but many programs follow roughly this order, because each step makes the next one possible:

1. Inventory. List users, devices, applications and data, and who needs what. Policy cannot be tighter than your knowledge of the environment.
2. Strengthen identity. Move every application to a central identity provider and require phishing-resistant MFA, such as FIDO2 security keys, passkeys or smart cards. US federal agencies were directed to do this by OMB memorandum M-22-09 in January 2022.
3. Identify devices. Issue device certificates through your management platform and start using device health in access decisions.
4. Control the network edge. Turn on 802.1X for managed devices, use MAB with profiling for devices that cannot run it, and place each class of device in its own segment.
5. Replace broad remote access. Move users from full-network VPN access to per-application access, starting with the most sensitive systems.
6. Watch and tighten. Centralize logs from the identity provider, enforcement points and DNS, and use them to remove access that nobody uses.

Common misconceptions