What is Zero Trust?

Zero Trust replaces location-based trust with continuous verification. Where a perimeter model treated anything inside the network as trustworthy by default, Zero Trust evaluates every request as though it originated somewhere untrusted, regardless of where it actually came from or what the same user was granted an hour earlier.

Three ideas define the model in practice:

• No implicit trust. Network position grants nothing on its own, and sitting inside the firewall is not evidence that a request is legitimate.
• Continuous verification. Trust is evaluated at each request rather than established once at login and held for the duration of a session.
• Least privilege. Access is scoped to what a specific request requires and does not extend beyond it.

Zero Trust is not a product that organizations can purchase. It is a strategy spanning identity, devices, networks, applications, and data rather than a technology that lives in any one of those layers. Vendors who present it as a product are generally describing a single component of the architecture.

The term itself dates to 1994, when Stephen Paul Marsh used it in a doctoral thesis on computational trust at the University of Stirling. It reached mainstream security in 2010, when Forrester analyst John Kindervag published “No More Chewy Centers: Introducing the Zero Trust Model of Information Security” and made the case that trust was itself a vulnerability. Google’s BeyondCorp project, begun in 2009, was among the first large-scale implementations.

NIST SP 800-207 defines seven tenets that any zero-trust architecture has to satisfy.

1. All data sources and computing services are resources. Databases, applications, SaaS services, IoT devices, and user workstations all require protection, with no exemptions granted on the basis of location or perceived importance.
2. All communication is secured regardless of network location. Traffic crossing the internal network is authenticated and encrypted to the same standard as traffic arriving from the public internet.
3. Access is granted on a per-session basis. Trust is evaluated for the session at hand and does not carry forward, so reaching one resource confers nothing about access to another.
4. Access is determined by dynamic policy. Decisions incorporate client identity, application state, asset posture, and behavioral and environmental attributes rather than resolving against a static rule set.
5. The enterprise monitors the posture of all assets. No asset is trusted by default, and device integrity is measured on an ongoing basis so that it can factor into access decisions.
6. Authentication and authorization are dynamic and strictly enforced before access. Verification operates as a continuous cycle of granting, scanning, adapting, and re-evaluating rather than as a single gate at the start of a session.
7. The enterprise collects as much information as it can and uses it to improve posture. Telemetry gathered from assets, infrastructure, and communications feeds back into the policies that govern access.

A shorter three-part framing also circulates widely: verify explicitly, assume breach, enforce least privilege. That formulation originates with Microsoft and works reasonably well as a summary, but it is not what SP 800-207 actually specifies, so organizations building to NIST should build to the seven tenets above.

Every access request is intercepted and decided in real time, following a sequence that stays consistent regardless of who built the underlying stack:

1. A subject requests access to a resource, where that subject may be a person, a service account, a workload, or an AI agent.
2. Signals are gathered, including identity, device posture, location, time, prior behavior, and threat intelligence.
3. A policy engine evaluates the request against organizational policy and a calculated risk score.
4. A decision is issued and enforced, granting access, denying it, or stepping it up with an additional authentication factor.
5. The session is monitored, so that changes in risk trigger re-evaluation and access can be revoked while the session is still open.

That final step is what distinguishes Zero Trust from the models that preceded it, since perimeter security makes one decision at the boundary and then lives with the consequences, while Zero Trust keeps evaluating for as long as the session lasts.

The clearest way to understand the difference is that a VPN extends the perimeter while Zero Trust does away with the perimeter altogether.

When a user connects through a traditional VPN, they are placed on the corporate network and inherit broad network-level access on the strength of a single verification performed at connection time. Anything reachable from that network position is reachable by that user, and by anyone who manages to steal their credentials.

Zero Trust grants access to individual resources rather than to networks, so the authorization to reach one application does not extend to other resources. Each request is re-evaluated against current risk conditions.

NIST Special Publication 800-207, published in August 2020, is the reference architecture most organizations build against. It draws a deliberate line between the components that make and enforce access decisions and the data sources that inform them.

Three core logical components

Policy Engine (PE). Makes the access decision by evaluating enterprise policy against the inputs described below, applying a trust algorithm, and then granting, denying, or revoking access.

Policy Administrator (PA). Executes that decision by opening or closing the communication path and issuing the credential or token the subject uses to reach the resource. Together the PE and PA form what NIST calls the policy decision point.

Policy Enforcement Point (PEP). Enables, monitors, and terminates the connection between subject and resource, sitting in the request path and applying whatever the policy decision point determines.

Data sources feeding the policy engine

The following supply the signals the policy engine evaluates, without making decisions themselves:

• Identity management system. Accounts, identity records, roles, attributes, and entitlements.
• Data access policies. The rules defining who may reach which resources and under what conditions.
• Continuous diagnostics and mitigation. Asset inventory and device posture.
• Threat intelligence. Internal and external indicators of newly discovered attacks and vulnerabilities.
• Activity logs and SIEM. Aggregated telemetry used to refine policy over time.
• Industry compliance systems. Regulatory requirements the enterprise is obligated to enforce.
• PKI. Certificate issuance and validation for subjects and resources.

Teams frequently blur this line during implementation, treating an identity system or a threat feed as though it were making access decisions, when in the NIST model those systems only supply input to the policy engine that actually decides. The distinction matters most when evaluating which parts of the architecture a vendor actually covers.

As a concept, Zero Trust is straightforward enough: don’t trust anyone or approve any action until you’ve validated the person and authorized the request it. Implementation is where most organizations stall, because Zero Trust touches identity, network, endpoint, application, and data simultaneously, and few security teams have the budget or the political capital to address all five at once. That raises the practical question of where to begin, and the answer is almost always identity.

Every Zero Trust decision comes back to a single question, which is whether this subject is who they claim to be and whether they should have this access right now. Segmentation and encryption cannot answer that question, and device posture narrows it without settling it, which leaves identity as the only control capable of resolving it. When identity is weak, every control downstream is faithfully enforcing a decision built on an unverified premise.

Identity carries the load in three places:

• Authentication. Verifying the subject through phishing-resistant methods rather than shared secrets that can be stolen, replayed, or socially engineered.
• Authorization. Determining what a verified subject is entitled to reach, based on governed roles rather than access that has accumulated over years of role changes.
• Continuous assessment. Re-evaluating both as risk signals change, and revoking access when the signals warrant it.

There is an uncomfortable corollary buried in this, which is that you cannot enforce a standard of least privilege that you have never defined, and you cannot define a standard of least privilege without knowing who has access to what today. Most organizations cannot answer that question with any confidence, which is why identity governance belongs at the start of a Zero Trust program rather than in a later phase.

Identity and access management supplies the components a Zero Trust architecture depends on.

Two requirements tend to be underestimated more than any others.

Authentication has to be phishing-resistant. MFA built on one-time passcodes delivered by SMS or email raises the bar without closing the gap, since adversary-in-the-middle attacks and MFA fatigue campaigns defeat push and OTP methods with some regularity. FIDO2 and device-bound passkeys bind the credential to both the device and the origin, which is the mechanism that actually stops the attack rather than slowing it down. RSA has been making this argument since well before it became the consensus position, as a FIDO Alliance board member and co-chair of the Enterprise working group.

Access has to keep working when the cloud does not. An architecture that routes every access decision through a cloud policy engine has introduced a single point of failure by design, and when that service becomes unreachable nobody can work. For organizations running on-premises, hybrid, air-gapped, or constant-availability environments, where an outage carries operational consequences rather than inconvenience, that is a poor trade. Zero Trust ought to reduce the number of things capable of taking an organization offline rather than concentrating them, which is why offline and on-premises enforcement paths are what make the model survivable in these environments.

Once an organization commits to Zero Trust, the real work begins. It runs as a multi-year program, and the organizations that get somewhere with it tend to sequence the work rather than attempting everything simultaneously.

1. Inventory identities, resources, and current access. Least privilege cannot be enforced against an unknown baseline, so start by establishing who and what can reach which resources today, including service accounts, contractors, and machine identities.

2. Strengthen authentication first. Deploying phishing-resistant MFA on the highest-value access paths delivers the largest risk reduction per unit of effort, and it is a prerequisite for most of what follows.

3. Define and enforce access policies. Translate roles and business needs into explicit policy, then remove standing broad access and replace it with entitlements that are scoped and reviewable.

4. Add context to access decisions. Introducing risk-based authentication lets low-risk requests pass cleanly while anomalous ones are challenged or blocked, which is also how you keep users from finding ways around the program.

5. Segment resources. Constraining what a compromised session can reach limits the blast radius for the moment when, rather than if, a control fails.

6. Monitor, review, and revoke. Entitlement reviews need to run on a schedule, because access that accumulates without review eventually becomes the privilege sprawl the program was meant to prevent.

Sequence matters more than pace here, since segmentation applied without governed identity underneath it produces well-partitioned networks that are still protecting over-privileged accounts.

Organizations never achieve or reach Zero Trust. They must continuously evaluate their posture and review every access decision.

User friction. Verification that is too aggressive drives workarounds, shadow IT, and help desk volume, though accessibility and security do not actually have to be traded against each other. Risk-based authentication matches the challenge to the risk an individual request poses rather than applying uniform friction to everyone.

Legacy systems. Applications predating modern authentication standards often cannot participate without a gateway, a proxy, or outright replacement, which makes this the longest pole in most programs and the one most often underestimated at planning time.

Availability dependency. Concentrating access decisions in a single cloud service creates a new critical dependency, and if the policy engine becomes unreachable then everyone is locked out of everything. It is worth asking any vendor directly what happens to authentication when their service goes down.

Organizational scope. Because Zero Trust spans identity, network, endpoint, application, and data teams, programs run entirely from one function tend to stall at that function’s boundary.

Vendor conflation. No single product delivers Zero Trust, so vendors are best evaluated on which architectural components they genuinely supply, and “Zero Trust platform” is better treated as a claim to verify than a category to buy.

Identity data sprawl. Identity is a growing data problem rather than a static one, and entitlements accumulate faster than most teams can review them by hand, which is the point at which automation and analytics stop being optional.

Zero Trust has moved from best practice to requirement across several regulated environments.

• Executive Order 14028 directs US federal civilian agencies toward Zero Trust architecture.
• CISA Zero Trust Maturity Model provides the framework federal agencies report maturity against, organized around five pillars: identity, devices, networks, applications and workloads, and data.
• DoD Zero Trust Strategy sets out Zero Trust activities for defense components.
• CMMC 2.0 imposes access control and MFA requirements across the defense industrial base.
• DORA and NIS2 impose access control, resilience, and operational continuity requirements on EU financial services and critical infrastructure that map onto Zero Trust principles whether or not the term appears in the text.

Identity appears as a pillar or a control family in every one of these, and it is also where auditors tend to ask for evidence first and where organizations are least often ready to produce it.

Resilience requirements and cloud-only architectures also pull against one another in ways that are worth thinking through early. Operational continuity expectations under DORA, along with constant-availability mandates in defense and critical infrastructure, are difficult to satisfy using an access model that stops functioning whenever a vendor’s service becomes unreachable.