---
{
  "title": "Zero trust",
  "summary": "Understand resource-focused access decisions, identity and device evidence, and how zero trust works alongside existing controls.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Zero Trust Architecture",
      "url": "https://csrc.nist.gov/pubs/sp/800/207/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Why location is not enough evidence

Zero trust is an architectural approach that avoids granting implicit trust solely because an account or device is inside a particular network or owned by an organization. Its focus is access to resources: who or what is requesting access, which resource is involved, and whether the available evidence supports the requested action.

NIST SP 800-207 is a foundational reference for the approach. The phrase does not describe one appliance, nor does it mean an organization can eliminate all trust. Systems still rely on identities, policy decisions, enforcement mechanisms, and the integrity of the evidence used to make those decisions.

## An employee on two networks

Imagine an analyst accesses a reporting application from an office laptop. A traditional shortcut might treat the office network as sufficient evidence that the request is safe. That assumption becomes fragile when a device is compromised, an account is stolen, or a network includes systems with different responsibilities.

A resource-focused design checks the analyst's identity, the requested application, the relevant permissions, and the device conditions required by policy. The office location can remain useful context, but it does not automatically unlock every internal service. The same reasoning can support access from a remote location when the required evidence is present.

## Draw the decision and enforcement points

For a learning exercise, separate the component deciding whether access is allowed from the component enforcing that decision. Then identify where their inputs originate. Account status may come from an identity service; device information from a management service; resource permissions from an application policy.

This diagram exposes dependencies. What happens if the device information is stale? What happens when the policy service is unavailable? Does the application have another route that bypasses the intended check? These are design questions that a product label cannot answer.

## Least privilege still matters

A verified identity should receive only the access needed for the task. [[least-privilege]] limits the scope of a successful access decision. [[identity-and-access-management]] helps maintain the accounts and entitlements on which those decisions depend. [[network-segmentation]] can still reduce unwanted communication paths. These measures complement the architectural approach.

Ongoing evaluation also does not mean typing a password for every network packet. Different implementations use different signals and session policies. The useful requirement is to respond appropriately when important evidence changes, such as account suspension or a device falling outside the organization's policy.

## Start with one resource

Choose a fictional payroll application and list its legitimate users, administrative tasks, data flows, and dependencies. Define a narrow access policy and test allowed and denied requests. Include a lost device, a removed employee, and an unavailable identity service in the exercise.

Explain the operational consequences of each decision. A policy that blocks essential work without a recovery route may create a different risk. Moving toward zero trust is a sequence of architecture and process improvements, supported by evidence that the intended boundaries actually hold.