Zero trust in plain English: protect resources, not network locations

Zero trust is often reduced to a slogan or product category. NIST describes an architecture: do not grant access merely because an account or device is inside a network, and protect the resource through explicit policy decisions.

What zero trust means in the NIST model

Source fact: NIST SP 800-207 describes zero trust as a shift from static, network-based perimeters toward users, assets, and resources. It says no implicit trust is granted solely because of physical or network location or because an asset is enterprise-owned.

Source fact: Authentication and authorization of the subject and device are distinct functions performed before a session to an enterprise resource is established. NIST emphasizes protecting resources—including assets, services, workflows, and accounts—rather than treating a network segment as the main component of a resource’s security posture.

Remote users, bring-your-own-device practices, and cloud assets outside an enterprise-owned boundary are among the conditions that motivate this approach. SP 800-207 provides an abstract definition, logical components, deployment models, and use cases. It does not designate one product as a zero-trust architecture.

Find the trust that exists today

DSE recommendation: start by documenting where current access depends on location, ownership, a broad VPN route, a shared account, or a one-time sign-in. For one important resource, map:

• human and non-human identities that request access;
• managed, unmanaged, service, and specialized devices;
• the data, transaction, and privilege being protected;
• identity, device, resource, behavior, and environmental signals available to policy;
• the enforcement point, telemetry, exception path, and recovery dependency.

DSE recommendation: define the least access needed for that transaction and the conditions under which it is allowed, limited, re-evaluated, or denied. Validate strong authentication, device state, service identity, segmented reachability, session behavior, and logging without assuming that any single signal is sufficient. Preserve an emergency path that is independently protected and tested.

Adopt incrementally

Pilot a bounded user group and resource. Test ordinary use, remote use, device replacement, loss of a signal, provider outage, policy error, help-desk recovery, and rollback. Measure unauthorized paths removed, successful and denied transactions, support impact, and gaps in visibility. Expand only when the evidence supports the next step.

Applicability and limits

Zero trust does not mean trusting nothing, authenticating continuously without purpose, or eliminating networks and firewalls. It does not guarantee prevention and is not a certification. Legacy, operational-technology, safety, latency, availability, privacy, and support constraints require tailored designs. NIST’s architecture must be combined with current platform guidance and organizational risk decisions.

Official reference

NIST SP 800-207 — the foundational federal publication defining zero trust architecture.