Zero Trust Explained: What the Model Actually Says, and What It Costs to Do

Why nowWhat it is reacting against

Zero trust security makes sense only against the model it replaced, so that model is worth stating plainly.

The traditional approach to network security is a perimeter, often called castle and moat. A firewall separates a hostile outside from a trusted inside, and remote workers are brought inside through a VPN.

Once inside, a machine can reach a great deal because the network is flat. Access control exists on individual systems, but the network itself is permissive, and reaching a system is most of the work of attacking it.

Three things broke that design, and none of them was a security fashion.

Applications left the building. Email, files and the finance system moved to cloud services nobody's firewall sits in front of, and so did the data in them. The perimeter stopped containing the things worth protecting.

Users and their devices left the building. Remote work made the exception into the norm, and a VPN that puts every laptop on the internal network scales the trust problem rather than solving it.

Threats got in anyway. Phishing puts an intruder inside the perimeter on day one, and inside a flat network the difference between one compromised device and a compromised company is a few hours.

Zero trust architecture is the response: stop treating the network as a security boundary, and verify every request from every user and device before granting access to resources, based on identity and context rather than location.

The idea is older than the products built on it. NIST Special Publication 800-207, published in August 2020, traces it to the Jericho Forum's work on de-perimeterization in 2004, and credits John Kindervag, then an analyst at Forrester, with coining the term zero trust.

PrinciplesThe core principles, and what each one costs

The marketing version of zero trust security is the never trust always verify slogan. The working version is three principles, and this is where an honest assessment starts.

Verify explicitly, every time. Continuous verification means authenticating and authorizing each request using every signal available: user identity, device health, location, the sensitivity of the data being reached, and the behavior of the session. Not once at the door.

Least privilege, and time limited. Grant the minimum access needed, for the shortest period that works. Standing access to everything is the thing zero trust exists to remove.

Assume breach. Design the security architecture as though a threat is already inside, because sooner or later it is. That assumption is what makes segmentation and monitoring load bearing rather than optional.

Those three principles are the summary in the zero trust architecture NIST publishes, and each one is expensive in a specific way. Verifying explicitly needs an identity system good enough to be the decision point. Least privilege needs somebody to know what the minimum actually is, which most organizations do not. Assuming breach needs monitoring that somebody reads.

The parts that have to exist

The pattern to notice is that four of those six already exist in most organizations, badly. Zero trust projects are rarely about buying new security products. A zero trust project is usually about making the identity system authoritative, the device inventory accurate, and the logs read.

How it worksHow zero trust works, request by request

Zero trust explained as a mechanism is a single access decision, repeated. NIST SP 800-207 describes it with three logical components that sit between users and the resources they want to reach.

1. A request arrives. A user, a device or a workload asks for access to an application or to data. Nothing about the network it came from counts in its favor. 2. The policy engine decides.

It weighs the security signals available: the identity and how it authenticated, device posture, location, time, threat intelligence and the sensitivity of the resource. Access is granted based on policy, not on address. 3. The policy administrator acts on the decision.

It sets up or shuts down the path between the user and the resource, issuing a token or credential that is valid for that session only. 4. The policy enforcement point applies it. This is the gateway, agent or proxy in the traffic path, and in a zero trust network access product it is the broker.

It allows the secure connection, monitors it, and ends it when told to. 5. Verification is continuous. The session is evaluated again as signals change. A device that falls out of compliance, or behavior that matches known threats, can lose access in the middle of a session.

The same approach covers on-premises systems, cloud workloads and SaaS applications, which is why zero trust security suits environments where data and users are no longer in one place. Every decision is logged, and those logs are what security teams use to detect threats that did get through.

The pillarsThe five pillars, and what each one actually asks

The maturity model CISA publishes organizes zero trust into five pillars, with three capabilities running across all of them. It is the most useful zero trust framing available, because it turns a slogan into five questions an organization can honestly answer about itself.

Identity. Can you prove who is asking, every time. This is the pillar every zero trust decision starts from. This means one authoritative directory, phishing resistant authentication where it matters, and privileged accounts that are separate from ordinary ones. Every other pillar assumes this one works.

Devices. Do you know which devices exist, and is their state part of the access decision. A managed laptop with current patches, disk encryption and working endpoint protection is a different risk from an unmanaged machine presenting the same credentials, and zero trust treats them differently. Most organizations discover their device inventory is a spreadsheet from two years ago.

Networks. Is the network segmented so that reaching one system does not mean reaching all of them, and is traffic between segments inspected rather than assumed. This is the pillar that costs the most effort per unit of progress.

Applications and workloads. Are applications reached through something that can apply policy, rather than by being on the right network. This is where per application access replaces the flat VPN, and where internal applications stop being visible to anything that gets inside.

In a Microsoft tenant the thing applying that policy is conditional access, which is where the idea stops being a principle and becomes a rule that runs.

Data. Do you know what data you hold, where it is, how sensitive each kind is, and who should reach it. This is the pillar organizations skip, and it is the one that makes least privilege meaningful, because you cannot grant minimum access to data you have never classified.

Three capabilities cut across all five.

Visibility and analytics. Logs from every pillar, in a place where somebody looks at them. Without this, assume breach is a slogan.

Automation and orchestration. Decisions applied by systems rather than by tickets, because continuous verification at human speed is not continuous.

Governance. Written policy, owners, and review. The part that decides whether any of it survives a change of staff.

The honest zero trust self assessment is to score each pillar from nothing to strong, and then notice that most organizations are strong on identity, weak on devices, absent on data, and describing themselves as doing zero trust anyway.

SegmentationMicrosegmentation, and why it is the hard part

Segmentation is where zero trust security stops being an identity project and becomes a network one, and it is where most programs slow down.

The zero trust goal is that a compromised machine can reach only what it genuinely needs, rather than everything on its subnet. In a traditional network that means subnets and firewall rules between them. In a modern one it means policy attached to workloads, so the rule follows the application rather than the address.

Three reasons it is hard, all of them organizational rather than technical.

Nobody knows what talks to what. The prerequisite for restricting traffic is knowing which traffic is legitimate, and that inventory rarely exists. It has to be discovered by watching, for weeks, before anything can be enforced.

The first enforcement breaks something. There is always a dependency nobody documented. Which is why enforcement starts in a mode that logs what it would have blocked, and stays there long enough to be boring.

It never ends. Applications change, and a segmentation policy that is not maintained becomes a set of exceptions that add up to the flat network you started with.

The pragmatic version most organizations should actually do first: separate the things that clearly do not belong together. Servers from workstations. Payment systems from everything. Building systems and cameras from the corporate network. That is a fraction of the work of full microsegmentation and most of the benefit.

BenefitsBenefits and use cases of a zero trust approach

A zero trust approach is sold on many promises. Four benefits hold up, and none of them needs a statistic to make the case.

A smaller attack surface. Applications behind a broker are not visible from the internet, and users see only the resources they are entitled to. What cannot be found is harder to attack.

Limited lateral movement. An intruder with one stolen credential reaches one application rather than a network. This is the benefit that matters most against ransomware, which depends on spreading from the first machine.

Secure access from anywhere. Remote and hybrid users get the same security checks at home as in the office, without sending their traffic through a VPN concentrator first.

Better evidence. Every access decision is logged with user, device and resource, which is the evidence auditors, cyber insurers and customers ask for.

The common use cases follow from those benefits:

• Replacing or shrinking the VPN for remote users
• Giving contractors and third parties access to one application instead of the network
• Securing access to cloud and SaaS applications that sit outside any perimeter
• Protecting sensitive data and regulated systems with stricter policy than the rest
• Isolating IoT and building devices that cannot run security software
• Joining two organizations after a merger without connecting their networks

What it is notWhat it is not

The words zero trust are on a great many product pages, and the gap between the model and the products is where money gets wasted.

Zero trust is not a product. Nothing you buy makes an organization zero trust. Security products implement pieces of it: an identity provider, an access broker, a segmentation engine. The architecture is the arrangement.

Zero trust is not a project with an end. There is no state in which it is finished. Maturity models exist precisely because it is a direction rather than a destination.

It does not mean distrusting your staff. The trust being removed is trust in a network location, not in people. A user on the office wifi and the same user on the same device in a hotel get the same treatment, which is the point.

It does not remove the need for a perimeter. A firewall still stops unsolicited inbound traffic and still costs almost nothing to run. Zero trust principles say the perimeter is not sufficient, not that it is useless.

Zero trust is not achieved by buying multi factor authentication. Strong authentication is the foundation and the single most valuable step, and it is one of six components.

How to startStarting, in the order that works

Zero trust programs that stall usually started with an architecture diagram. The ones that succeed usually started with one application and a defined group of users.

Get identity right first. Zero trust rests on this one. One directory that is authoritative, multi factor authentication everywhere it can be applied, and privileged accounts separated from ordinary ones. Nothing else in the model works if the answer to who is asking cannot be trusted.

Know what you have. An inventory of applications and devices, which users reach each one, and how sensitive the data behind it is. Unglamorous, and every later security decision depends on it.

Pick one application and move it. Something used by a defined group, ideally web based. Put it behind per application access with device checks. Learn what breaks on something small.

Take the easy segmentation. Separate servers from workstations, and put anything with regulated data behind its own boundary. Do not attempt full microsegmentation as a first move.

Make the logs useful. Sign in logs, access decisions, denied attempts, device posture failures. If nobody reads them, the assume breach principle is decoration.

Then repeat, application by application. The VPN shrinks as applications move behind zero trust access, and the day it can be switched off is the day the project reports a result.

What it costsWhere the money goes

Zero trust explained by a vendor rarely includes what it costs, so here is an honest note on where the money goes.

The license for an access broker is per user per month and is the visible cost. The invisible costs are larger: the inventory work, the discovery period before segmentation can be enforced, the applications that need re-platforming because they cannot be brokered, and the operational load of a policy that now has to be maintained.

The saving is real but indirect. Fewer systems reachable from a compromised laptop means a smaller incident when one happens, and incidents are the expensive thing. That argument is sound and it is not a spreadsheet, which is why zero trust is usually funded after an incident, a customer requirement, or an insurance question rather than on its own merits.

ComparisonA VPN and zero trust network access, side by side

The first practical zero trust project in most organizations is replacing remote access for users, so this comparison is the one that gets made. Zero trust network access, usually shortened to ZTNA, brokers a secure connection between one user and one application, based on identity and device posture, and never places the device on the network.

The last row is where projects meet reality. Web applications and modern protocols move easily. The line of business application from 2009 that needs a fixed port and a drive mapping does not, and it is usually the one keeping the VPN alive.

Most organizations end up running both for longer than they planned, which is fine as long as it was a decision rather than a surprise.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Remote access VPN vs Proxy The VPN this model replaces, and why it grants so much more than it needs to. Open this next13 min

• Identity and access · 16 min What Is MFA? Identity is the first pillar, and this is how it is actually done.
• Network security · 14 min What Is a Firewall? Segmentation is a firewall problem, and it is the pillar that costs the most.
• Remote access · 12 min VPN Technologies, and Which One Belongs on Which Job What comes after the remote access VPN.
• Network security · 12 min IDS vs IPS The detection layer that watches the lateral movement this model assumes will happen.
• Operations · 10 min Provisioning Where the orphaned accounts come from.
• Cryptography · 11 min Hash Functions, and Why the Right One Depends on the Job The model that stops treating one authentication as permanent.
• Endpoint management · 13 min MDM Explained What proves a device is trustworthy before the identity layer lets it through.
• Security operations · 10 min Data Classification, and Why Every Label Needs a Rule How to sort company data into a few levels, and the handling rules that make each level mean something.
• Cloud security · 12 min Cloud Security Architecture, and What the Providers Actually Publish Where zero trust is decided on a cloud platform, one account boundary at a time.
• Identity and access · 8 min Conditional Access, and the Policy That Locks Out the Person Who Wrote It What the idea looks like once it is a policy that runs.
• Network security · 11 min What a CWPP Is, What It Protects, and What It Costs The runtime layer that enforces zero trust on the workloads themselves.
• Identity and access · 12 min CyberArk vs HashiCorp Vault The two products that put zero standing access into practice, one for people and one for machines.