What Is Zero Trust Security? Principles and How It Works

Zero trust security is a cybersecurity model built on a single rule: never trust, always verify. Instead of assuming that anyone or anything already inside a corporate network is safe, a zero trust architecture checks the identity, device, and context of every single request for access, every time, regardless of whether that request comes from a laptop on the office Wi-Fi or a phone on the other side of the world. The model was formally defined by the U.S. National Institute of Standards and Technology (NIST) in Special Publication 800-207, and it has since become the default blueprint that governments and major technology vendors point to when they talk about modern network security.

What Is Zero Trust Security?

Zero trust is not a product you install or a box you buy. It is a security strategy, or what NIST calls "an evolving set of cybersecurity paradigms," that shifts the focus of defense away from the network perimeter and onto individual users, devices, applications, and data. NIST's operative definition describes zero trust as "a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised." A zero trust architecture is simply an enterprise's cybersecurity plan for putting those concepts into practice across its infrastructure, workflows, and access policies.

Crucially, zero trust assumes a breach has either already happened or could happen at any moment. Rather than building one strong wall around the network and trusting everything inside it, zero trust treats every access request, no matter where it originates, as a potential threat until it is explicitly verified. That is a direct response to how enterprise computing has actually changed: employees work from home and on personal devices, applications live in multiple clouds, and contractors and partners need access to narrow slices of company data without ever touching the rest of the network.

Why Perimeter-Based Security Falls Short

For decades, enterprise security worked like a castle with a moat. Firewalls, virtual private networks, and network segmentation formed a hard perimeter, and anyone who got past that perimeter, whether a remote employee logging in through a VPN or an attacker who stole valid credentials, was generally trusted to roam the internal network. NIST's own introduction to zero trust architecture points out exactly why this model has broken down: "This complexity has outstripped legacy methods of perimeter-based network security as there is no single, easily identified perimeter for the enterprise. Perimeter-based network security has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered."

That lateral movement problem is the heart of the issue. A single successful phishing email or an instance of credential stuffing against one employee account could once hand an attacker the keys to an entire internal network, because internal network location was treated as a stand-in for trustworthiness. Cloud services, bring-your-own-device policies, and distributed workforces have erased the idea of a single, defensible network edge, which is exactly the trend NIST cites as the catalyst for zero trust.

The Core Principles of Zero Trust

NIST SP 800-207 lays out seven basic tenets that describe the ideal zero trust architecture, acknowledging that "not all tenets may be fully implemented in their purest form for a given strategy." Distilled, those tenets hold that:

• All data sources and computing services are treated as resources that need protecting.
• All communication is secured regardless of network location, so being on the corporate network grants no automatic trust.
• Access to any individual resource is granted on a per-session basis, evaluated fresh each time rather than once at login.
• Access decisions are determined by dynamic policy, including the identity of the client, the application involved, and observable attributes of the requesting device.
• The enterprise continuously monitors and measures the security posture of all owned and associated assets.
• Authentication and authorization are strictly enforced before access is granted, and are treated as dynamic, not one-time, events.
• The enterprise collects as much information as possible about assets, network infrastructure, and communications, and uses it to continually improve its security posture.

Vendors tend to compress these ideas into something more memorable. Microsoft, for instance, describes its own zero trust model around three guiding principles: verify explicitly, meaning every access request is authenticated and authorized using all available signals; use least-privilege access, meaning users and workloads get only the access they need for only as long as they need it; and assume breach, meaning security controls are designed on the premise that an attacker might already be operating inside the environment. Those three ideas map closely onto NIST's seven tenets and are a useful shorthand for what zero trust is trying to achieve day to day.

Identity Verification: Knowing Who's Really Asking

In a zero trust model, identity becomes the new perimeter. Before any request for data or an application is granted, the system has to establish, with a high degree of confidence, exactly who or what is asking: a human user, a service account, or an automated process. That typically means strong authentication, such as multi-factor authentication or hardware-backed credentials like passkeys, combined with checks on the device being used, its patch level and security posture, and contextual signals like location and time of day. CISA's maturity model treats this as the Identity pillar and describes the most mature stage as one where an agency "continuously validates identity with phishing-resistant MFA, not just when access is initially granted," rather than trusting a single login for the rest of a session.

This is a meaningful shift from older models where a username and password, checked once, was often enough to unlock broad access for hours or an entire workday. Under zero trust, that same login event is just the first of many checks; the system keeps asking "is this still the right person, on the right device, behaving normally?" throughout the session.

Least-Privilege Access

Verifying identity only solves half the problem. Zero trust also insists that, once a user or service is verified, it should be granted the absolute minimum level of access needed to complete a specific task, and nothing more. NIST frames this as granting access "on a per-session basis" with "the least privileges needed to complete the task," which may only apply to a single transaction rather than a standing grant that lasts until someone remembers to revoke it.

In practice, this means an employee in finance does not get blanket access to every internal system just because they are logged into the corporate network; they get access to the specific finance applications and data sets their job requires, for a defined window of time, with that access automatically re-evaluated or expired afterward. CISA's Identity pillar describes the most advanced form of this as organizations moving toward "just-in-time and just-enough access," where privileges are granted dynamically and narrowly rather than assigned permanently.

Micro-Segmentation

Where traditional networks relied on a handful of large perimeter firewalls, zero trust architectures break the network into many small, tightly controlled zones, a technique generally called micro-segmentation. Instead of one broad "trusted" internal network, resources are isolated into individual segments or even wrapped in their own enforcement boundary, so that a compromised laptop or server cannot simply move sideways to reach everything else on the network.

NIST describes one version of this as the "enclave-based deployment" model, in which resources with similar protection needs sit behind their own local gateway rather than a single enterprise-wide boundary. CISA's Networks pillar describes the most mature form of this approach as "distributed micro-perimeters with just-in-time and just-enough access controls and proportionate resilience," meaning network boundaries are drawn tightly around individual workloads and adjusted dynamically rather than fixed once and left alone. The practical effect is that even if an attacker gets a foothold somewhere on the network, they are contained to a small segment rather than free to roam.

Continuous Monitoring and Validation

Because zero trust assumes the network may already be compromised, verifying a request once is never considered sufficient. Systems need to continuously collect telemetry, logs, and behavioral signals about users, devices, and traffic, and feed that information back into access decisions in close to real time. NIST's seventh tenet of zero trust puts it plainly: an enterprise "collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture."

CISA groups this activity under the cross-cutting capability it calls Visibility and Analytics, which it says should "inform policy decisions, facilitate response activities, and build a risk profile to develop proactive security measures before an incident occurs." Combined with the related capabilities of Automation and Orchestration and Governance, continuous monitoring is what allows a zero trust system to detect a stolen credential or an abnormal access pattern quickly and automatically shrink or revoke access, rather than waiting for a human analyst to notice something has gone wrong days or weeks later.

The NIST Model: Policy Decision and Enforcement Points

Underneath the principles, NIST SP 800-207 describes a concrete logical architecture for how access decisions actually get made. At the center of every request sits a policy decision point (PDP), paired with a policy enforcement point (PEP). When a device or user, which NIST refers to generically as a "subject," wants to reach an enterprise resource, that request first passes through the PDP/PEP pairing rather than going straight to the resource. The PDP evaluates the request against dynamic policy, which can account for who is asking, what device they are using, their behavioral history, and other environmental attributes, and the PEP then allows or denies the connection accordingly.

NIST illustrates this with an airport analogy: passengers pass through a single security checkpoint, the PDP/PEP, and once past it, they are considered part of a smaller "implicit trust zone," the boarding area, rather than being trusted for the entire airport. The goal of a mature zero trust architecture is to shrink that implicit trust zone as much as possible, moving the equivalent of the checkpoint as close as possible to each individual resource rather than relying on one checkpoint for an entire network.

CISA's Zero Trust Maturity Model and the Five Pillars

While NIST defines the concepts, the Cybersecurity and Infrastructure Security Agency (CISA) publishes a practical roadmap for getting there. CISA's Zero Trust Maturity Model, now in version 2.0, organizes an organization's journey around five technology pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Each pillar is supported by three cross-cutting capabilities that CISA says should run through all of them: Visibility and Analytics, Automation and Orchestration, and Governance.

For each pillar, CISA defines four stages of maturity: Traditional, where controls are manually configured and policies are static; Initial, where some automation and cross-pillar coordination begins; Advanced, where automated controls and centralized visibility take hold; and Optimal, described as having "fully automated, just-in-time lifecycles," dynamic least-privilege access, and centralized visibility with comprehensive situational awareness across the enterprise. CISA is explicit that this is meant as one possible path rather than a rigid checklist, and that the move toward optimal maturity is, in its own words, "an incremental process that may take years to implement."

Why Organizations Are Adopting Zero Trust Now

Zero trust has existed as an idea for well over a decade, but it has moved from an industry talking point to formal policy in just the past few years, largely because of action inside the U.S. federal government. Executive Order 14028, "Improving the Nation's Cybersecurity," directed federal civilian agencies to develop a plan to implement a zero trust architecture. That direction was made concrete by Office of Management and Budget Memorandum M-22-09, "Moving the U.S. Government Toward Zero Trust Cybersecurity Principles," which set specific zero trust objectives for agencies to meet by the end of fiscal year 2024.

That federal push matters well beyond government agencies themselves. CISA's maturity model was built in direct response to that mandate, and it has become a reference architecture that contractors, critical infrastructure operators, and private enterprises of all sizes consult even though they are not legally required to follow it. At the same time, the shift to remote and hybrid work, multi-cloud infrastructure, and software-as-a-service applications has made the old perimeter model increasingly impractical to maintain on its own, which is why major vendors including Microsoft have built zero trust directly into their own security architectures and guidance rather than treating it as a niche add-on.

Challenges and Common Misconceptions

Adopting zero trust is rarely a single project with a clean finish line. NIST is careful to note that "transitioning to ZTA is a journey concerning how an organization evaluates risk in its mission and cannot simply be accomplished with a wholesale replacement of technology." Most organizations end up running a hybrid of zero trust and legacy perimeter-based architecture for a long time, migrating use case by use case rather than ripping out existing infrastructure all at once.

A common misconception is that zero trust is a specific product that can be purchased and switched on. It is not. It is a strategy and an architecture pattern that gets implemented using a combination of identity providers, device management tools, network segmentation technology, and monitoring systems, many of which an organization may already own. Another misconception is that zero trust means eliminating trust altogether; in reality, it means trust is never implicit or permanent, it is explicitly granted, scoped narrowly, and continuously re-evaluated. CISA also flags a cultural dimension that is easy to underestimate: successful adoption requires "engagement and cooperation from senior leadership, IT staff, data and system owners, and users," not just new technology.

What to Do Next

For organizations just starting out, NIST's own road map in SP 800-207 is a reasonable place to begin: identify the actors, devices, and assets on the network, map the key business processes and the risks associated with them, and formulate access policies before shopping for specific tools. CISA's Zero Trust Maturity Model can then help translate that groundwork into a staged plan across the Identity, Devices, Networks, Applications and Workloads, and Data pillars, with realistic milestones rather than an expectation of reaching full maturity overnight.

For readers who are earlier in the process, it is worth getting the fundamentals in place first: strong, phishing-resistant authentication such as passkeys, defenses against credential-based attacks like credential stuffing, and a clear-eyed look at where a traditional VPN is being asked to do a zero trust architecture's job. None of these fixes a perimeter-based network on its own, but each is a building block that a genuine zero trust architecture depends on, and none of them require waiting for a single, sweeping project to finish before work can begin.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage