Back to CyberPedia
Zero Trust Architecture

What Is Zero Trust Architecture?
How ZTA Works & Best Practices

Zero trust architecture assumes no user or device is trusted by default. NIST SP 800-207 defines it as the framework that checks every request in real time — based on identity, device, context, and policy. This guide covers what ZTA is, the 6 core NIST principles, how it works (5-step PE/PEP flow), key parts (IAM, MFA, microsegmentation, EDR, SASE), pros and cons, best practices, and 7 FAQs.

10 min read
Cybersecurity
3 views

What Is Zero Trust Architecture?

Zero trust architecture (ZTA) is a security framework built on one core rule: never trust, always verify. It assumes that no user, device, or network is safe by default — even if they’re inside the company walls. Every access request is checked, scored, and approved (or denied) in real time, based on who is asking, what device they’re on, and what they’re trying to reach.

Here’s a simple way to think of it. Old security was like a castle with a moat. Once you crossed the moat, you could go anywhere inside. But zero trust architecture treats every room like it has its own lock. Even if you’re already in the building, you still need to prove who you are — and why you need access — at every door.

NIST defines ZTA in Special Publication 800-207 as a model that moves defenses away from static perimeters. Instead, it focuses on users, assets, and resources. Access is granted per session, not once and for all. And every request is checked against context — like identity, device health, location, and behavior.

This matters more than ever. Remote work, cloud apps, BYOD, and hybrid networks have erased the old perimeter. There’s no single wall to defend. So zero trust architecture protects each resource on its own — no matter where it sits or who is asking for it.

ZTA in One Line

No user or device is trusted by default. Every access request is checked in real time — based on identity, device, context, and policy. Access is granted per session, never left open, and logged end to end. That’s the core of zero trust architecture.


The Core Principles of Zero Trust Architecture

Indeed, NIST SP 800-207 lists seven key tenets. Here are the ones that matter most — in plain terms.

Every Resource Is a Target
All data, apps, devices, and services are resources. Each one must be secured on its own — not just the ones behind the firewall. In ZTA, there’s no “safe zone.” Every asset needs its own access controls.
All Traffic Is Suspect
ZTA assumes the network is always at risk — even the internal one. So all data in transit must be encrypted. And every request must be checked. Unlike RBAC or ABAC alone, ZTA treats the network itself as hostile — because an attacker may already be inside.
Access Is Per-Session
Trust is never left open. Each session must be checked on its own. If a user accessed a resource an hour ago, they must still prove they should have access now. Consequently, stale sessions can’t be used for lateral movement.
Decisions Are Dynamic
Access choices are based on real-time context — like identity, device health, location, time, and behavior. Static rules aren’t enough. The system must adapt as conditions change.
Least Privilege, Always
Users and devices get only the access they need — nothing more. Permissions are tight, scoped, and reviewed often. This limits the blast radius if any account is compromised.
Monitor Everything
ZTA requires continuous logging and monitoring of every access event. The system watches for anomalies, tracks who accessed what, and feeds the data back into the policy engine to improve future decisions.

How Zero Trust Architecture Works

Essentially, ZTA uses three core parts that work together for every access request. So here’s how the flow plays out.

Step 1
User Requests Access
A user or device tries to reach a resource — like a file, app, or API. The request goes to the Policy Enforcement Point (PEP), which blocks all access by default until the check is done.
Step 2
Context Is Gathered
The system collects context: user identity, device health, location, time, and behavior patterns. It also checks threat intel feeds and compliance status. All of this feeds into the next step.
Step 3
Policy Engine Decides
The Policy Engine (PE) checks the request against the firm’s access policies. It weighs all the context data and makes a choice: allow, deny, or require more proof (like MFA). This is the brain of ZTA.
Step 4
Access Is Granted or Denied
The PE tells the PEP to open or close the gate. If allowed, a secure session is created — encrypted end to end. The user gets access to that one resource only, for that one session.
Step 5
Session Is Watched
The system monitors the session the whole time. If the device gets flagged, the user changes location, or behavior shifts, access can be revoked mid-session. Every event is logged for audit.

This flow runs for every request — not just at login. As a result, zero trust architecture catches threats that one-time checks would miss.

Related Guide
Explore Our Zero Trust Architecture Solutions


Key Parts of a Zero Trust Architecture

Notably, ZTA is not one tool — it’s a set of parts that work together. Here are the main ones.

Part What It Does Example Tools
Identity & Access (IAM) Verifies who the user is and what they can do Entra ID, Okta, Ping Identity
Multi-Factor Auth (MFA) Adds a second proof on top of the password Passkeys, FIDO2, authenticator apps
Microsegmentation Splits the network into small zones, each with its own rules Illumio, Guardicore, VMware NSX
Endpoint Detection (EDR) Checks device health before and during access CrowdStrike, SentinelOne, Defender
SASE / ZTNA Provides secure, identity-based remote access — no VPN needed Zscaler, Cloudflare, Palo Alto Prisma
Policy Engine The brain — checks every request against the firm’s policies Custom or built into IAM / SASE tools

Pros and Cons of Zero Trust Architecture

Ultimately, ZTA trades simplicity for precision. So here’s a clear view of both sides.

Advantages
Stops lateral movement — even if one area is breached, the rest stays safe
Adapts in real time — checks context for every request, not just at login
Built for hybrid work — secures users no matter where they connect from
Supports compliance — meets NIST, HIPAA, PCI DSS, and CISA requirements
Reduces attack surface — least privilege and microsegmentation shrink exposure
Limitations
Complex to build — needs changes across identity, network, and endpoints
Not a quick fix — full rollout takes months or years for large firms
Legacy systems — older apps may not support modern ZTA protocols
Needs clean data — bad identity or device data breaks the model

Zero Trust Architecture Best Practices

Here are the ZTA best practices from NIST and CISA that help you get this right.

First, start with identity. You can’t verify what you can’t see. So map every user, device, and service. Then build a strong IAM base with MFA for all accounts. Because identity is the first pillar of any zero trust architecture.

Then, apply least privilege everywhere. Give users and devices only the access they need — nothing more. Scope permissions tightly. Review them often. Consequently, even if an account is compromised, the damage stays small.

Also, segment your network. Break it into small zones with their own rules. This is called microsegmentation. It stops attackers from moving freely if they breach one area. Each zone acts like its own locked room.

Monitor, Automate, and Evolve

Log and monitor everything. Every access event, every policy check, every session — record it all. Use the data to spot anomalies, feed your policy engine, and prove compliance. However, monitoring only works if the data is clean and the alerts are tuned.

Start small and grow. NIST says ZTA is a marathon, not a sprint. Pick one high-risk workflow and apply ZTA there first. Test it. Learn from it. Then expand. Trying to do it all at once is the top cause of failure.

Finally, align with NIST SP 800-207 and CISA’s maturity model. Both offer clear roadmaps for ZTA. Use them to assess where you are, set milestones, and track your progress. Because ZTA is not a product you buy — it’s a model you build, step by step.

ZTA Checklist

Map all users, devices, and services. Build strong IAM with MFA. Apply least privilege everywhere. Segment the network with microsegmentation. Log and monitor every access event. Start small and expand. Align with NIST SP 800-207 and CISA. Review and adapt quarterly.

Frequently Asked Questions About Zero Trust Architecture

Frequently Asked Questions
What is zero trust architecture?
Zero trust architecture (ZTA) is a security framework that assumes no user or device is trusted by default. Every access request is checked in real time — based on identity, device health, context, and policy. NIST defines it in SP 800-207. Essentially, ZTA protects each resource on its own rather than relying on a network perimeter.
How does ZTA differ from traditional security?
Traditional security uses a perimeter — like a firewall — and trusts everyone inside it. In contrast, ZTA trusts no one by default. It checks every request, limits access per session, and monitors the whole time. So even if an attacker gets inside, they can’t move freely. This is what makes ZTA far more resilient.
What is NIST SP 800-207?
NIST SP 800-207 is the main standard for zero trust architecture. Published in 2020, it defines ZTA, lists seven core tenets, and offers deployment models. NIST also released SP 1800-35 with 19 example ZTA builds. Together, these guides are the go-to roadmap for any firm building a ZTA.
What is microsegmentation?
Microsegmentation splits the network into small zones, each with its own access rules. If an attacker breaches one zone, they can’t move to another. This stops lateral movement — one of the biggest risks in traditional flat networks. Consequently, microsegmentation is a core part of any zero trust architecture.

More Common Questions

Is zero trust architecture a product?
No — ZTA is a framework, not a product you buy. It uses many tools together — like IAM, MFA, microsegmentation, EDR, and SASE. No single vendor covers all of it. So building a ZTA means picking the right tools and wiring them together around NIST’s core tenets.
How long does it take to build a ZTA?
It depends on the firm’s size and current state. However, NIST calls it a marathon, not a sprint. Most firms start with identity and MFA, then add microsegmentation and ZTNA over time. A full rollout can take one to three years for a large firm. The key is to start small and expand.
Is ZTA required by law?
For US federal agencies, yes — Executive Order 14028 mandates zero trust. CISA’s maturity model guides them. For private firms, it’s not yet a legal must — but many compliance rules (HIPAA, PCI DSS, NIS2) align with ZTA principles. So the trend is clear: ZTA is fast becoming the standard.

Conclusion: Why Zero Trust Architecture Matters Now

In short, zero trust architecture is the most resilient framework for today’s threats. It doesn’t trust anyone by default. Instead, it checks every request and watches every session. And it limits access to only what’s needed, when it’s needed.

However, ZTA is not a quick fix. So start with identity and MFA. Then add microsegmentation. After that, expand to ZTNA and EDR. And ultimately, align with NIST SP 800-207 every step of the way.

Start now. First, map your users, devices, and assets. Then build strong IAM with MFA. Next, segment your network. After that, deploy a policy engine and monitor everything. Finally, audit and evolve. Because the firms that build zero trust architecture today are the firms that stay safe tomorrow.

Next Step
Get Help Building Your Zero Trust Architecture


References

  1. NIST — SP 800-207: Zero Trust Architecture
  2. CISA — Zero Trust — CISA
  3. NIST — NIST Offers 19 Ways to Build Zero Trust Architectures
Stay Updated
Get the latest terms & insights.

Join 1 million+ technology professionals. Weekly digest of new terms, threat intelligence, and architecture decisions.