What Is Zero Trust Architecture? A Guide for IT Leaders

Zero trust architecture is a security model that stops treating anything inside your network as safe by default. Every request to an application or data set is checked on its own merits, based on who is asking, from what device, and under what conditions, before access is granted for that session only.

This guide is for CIOs, IT directors and business leaders who keep hearing "zero trust" in vendor pitches and audit findings and want a plain account of what it means, what it costs in effort, and where to start.

Key takeaways

• Zero trust is a set of design principles, not a product. NIST defines it in Special Publication 800-207, published in August 2020.
• The core idea is that network location no longer earns trust. Being on the office Wi-Fi or the VPN does not by itself grant access to anything.
• NIST lists seven tenets, including per-session access, dynamic policy, and continuous monitoring of device security posture.
• Most organizations organize the work around five pillars: identity, devices, networks, applications and workloads, and data.
• There is no single build. NIST's own reference project produced 19 different example implementations using commercial products.

What does zero trust actually mean?

Zero trust means you assume an attacker may already be inside your environment, so you verify every access request instead of trusting the network it came from. In NIST's words, it moves defenses "from static, network-based perimeters to focus on users, assets, and resources."

The older model is often called "castle and moat." You built a strong perimeter with firewalls and a VPN, and once someone was inside, they could reach most internal systems. That worked when employees sat in one building and applications ran in one data center. It breaks down when your payroll runs in a SaaS platform, your developers use a public cloud, and half your staff work from home.

NIST's SP 800-207 Zero Trust Architecture separates two terms that people often blur:

• Zero trust (ZT): the principles themselves, described by NIST as "an evolving set of cybersecurity paradigms."
• Zero trust architecture (ZTA): an enterprise plan that "uses zero trust principles to plan industrial and enterprise infrastructure and workflows."

In practice, a ZTA is your specific set of identity, device, network and application controls wired together so that access decisions are made consistently, logged, and revisited when conditions change.

What are the seven tenets of zero trust?

NIST SP 800-207 lists seven tenets that any zero trust design should satisfy. They are the most useful checklist for judging whether a proposed project is really zero trust or just a relabeled VPN.

The tenets, quoted from section 2.1 of the full NIST SP 800-207 text, are:

1. All data sources and computing services are considered resources.
2. All communication is secured regardless of network location.
3. Access to individual enterprise resources is granted on a per-session basis.
4. Access to resources is determined by dynamic policy.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
7. The enterprise collects as much information as possible about the current state of assets.

Read them as a business leader and three ideas stand out. First, the office network gets no special status (tenet 2). Second, access is granted per session and can be withdrawn (tenets 3 and 6). Third, you cannot make good decisions without good data about your users, devices and applications (tenets 5 and 7). That last point is why so many zero trust programs stall: the organization does not have an accurate inventory to start from.

How does a zero trust architecture make access decisions?

A zero trust architecture puts a decision point and an enforcement point between every user and every resource. The decision point evaluates policy, and the enforcement point opens or closes the connection based on that decision.

NIST names the parts plainly:

• Policy engine (PE): decides whether to grant, deny or revoke access by running a "trust algorithm" against enterprise policy and outside signals such as threat intelligence. It also logs each decision.
• Policy administrator (PA): carries out the engine's decision by setting up or shutting down the communication path, and can issue session-specific credentials.
• Policy decision point (PDP): the engine and administrator together.
• Policy enforcement point (PEP): the gateway, agent or proxy that enables, monitors and ends the connection between the user and the resource.

In a typical enterprise, your identity provider, device management tool, and an access proxy or secure gateway share these roles. When an employee opens the HR system, the policy engine checks their identity, whether they passed multifactor authentication, whether their laptop is managed and patched, and whether the request looks normal. If everything checks out, the proxy lets that session through. If the laptop falls out of compliance an hour later, the next request can be refused.

What are the five pillars of zero trust?

The five pillars are identity, devices, networks, applications and workloads, and data. CISA's Zero Trust Maturity Model is built on five pillars plus three cross-cutting capabilities, and the federal zero trust strategy uses the same five pillars to set its goals.

The White House Office of Management and Budget memorandum M-22-09, issued on January 26, 2022, gave federal agencies a goal for each pillar and a deadline of the end of fiscal year 2024. Those goals are a useful benchmark for private companies too, even though the memo only binds federal agencies.

Pillar	Federal goal in M-22-09	What it looks like in a private enterprise
Identity	Staff use enterprise-managed identities, with phishing-resistant MFA required for staff, contractors and partners	One identity provider, single sign-on for every business app, MFA everywhere, no shared admin accounts
Devices	A complete inventory of every device operated and authorized for use	Endpoint management on laptops and phones, device health checked at sign-in
Networks	Encrypt all DNS requests and HTTP traffic inside the environment	HTTPS for internal apps and APIs, segmentation so one compromised system cannot reach everything
Applications and workloads	Treat all applications as internet-connected and test them rigorously	Internal apps published through an access proxy, not reachable just because someone is on the VPN
Data	Deploy protections based on thorough data categorization	Classify sensitive data (payroll, health, customer records) and tie access rules to that classification

Two lines from M-22-09 capture the shift well. It says "every application should be treated as internet-accessible from a security perspective," and it requires agencies to "enforce HTTPS for all web and application program interface (API) traffic in their environment." Where you are working through any legal or contractual requirement tied to these controls, this article is general information, not legal advice.

How do you start implementing zero trust?

Start with identity and inventory, then move application by application. Trying to redesign the whole network at once is the most common reason zero trust projects lose funding.

NIST's National Cybersecurity Center of Excellence spent four years building 19 example implementations with 24 industry collaborators for its SP 1800-35 guidance, released in June 2025. As one NIST computer scientist put it in that announcement, "everyone's network environments are different, so every ZTA is a custom build." The sequence below works for most mid-size and large organizations.

1. Inventory what you have. List users, service accounts, devices and applications, including the SaaS tools teams bought on their own. Unsanctioned apps are a blind spot, and a shadow IT governance playbook helps bring them into scope.
2. Consolidate identity. Put every application you can behind one identity provider with single sign-on. Retire local accounts and shared passwords.
3. Enforce strong MFA. CISA notes that MFA means "even if one credential becomes compromised, unauthorized users will be unable to meet the second authentication requirement." Prefer phishing-resistant methods such as security keys or platform passkeys. If you are weighing fingerprint or face options, our look at whether biometrics beat passwords under NIST guidance covers the trade-offs.
4. Check device health at sign-in. Require managed, patched devices for sensitive applications. Pay particular attention to low-cost Android hardware, since preinstalled backdoors on some devices undermine any posture check.
5. Apply least privilege inside each application. Zero trust at the front door means little if everyone gets broad rights once inside. Role design guides such as designing Workday security groups for role-based access show how to scope access to what each job needs.
6. Publish internal apps through an access proxy. Move apps off "anyone on the VPN" access one at a time, starting with the most sensitive.
7. Segment and encrypt. Encrypt internal traffic and split the network so a compromised workstation cannot reach your databases directly.
8. Log, review and adjust. Feed access decisions into your monitoring, review denied and unusual requests, and tighten policy as you learn.

Where does zero trust fit with cloud, SaaS and vendors?

Zero trust fits cloud and SaaS better than the perimeter model did, because it never assumed a single network in the first place. The same identity, device and policy checks apply whether the application runs in your data center, a public cloud, or a vendor's platform.

The NIST announcement makes the point directly: with multiple networks, cloud services and remote work, "there is no single perimeter." For cloud workloads, pair zero trust access with the controls covered in our overview of cloud security techniques for HR and IT leaders, such as encryption, key management and configuration monitoring.

Vendors and contractors are where many organizations still grant the widest standing access. Give third parties their own identities, time-limited access to specific applications, and no network-level VPN unless there is no alternative. A structured third-party risk management program gives you the vendor inventory and review cadence that zero trust policy depends on.

Administrators deserve the same scrutiny. A zero trust design should not let a single IT admin account read every sensitive record. Separation of duties, just-in-time elevation and logging matter here, and the practical steps in protecting confidential HR files from IT admin access apply to finance and legal data as well.

Common mistakes to avoid

Most zero trust failures come from treating it as a purchase rather than an operating change. These are the patterns that show up again and again.

• Buying a "zero trust product" and calling it done. No single tool covers all seven tenets. A secure access gateway with weak identity behind it is still weak.
• Skipping the inventory. You cannot write policy for devices and apps you do not know exist.
• Leaving legacy exceptions open forever. Old systems that cannot support modern authentication often get a permanent bypass. Put them behind a proxy, isolate them, and set a retirement date.
• Ignoring service accounts and API keys. Non-human identities often have more access than any person and never use MFA. Rotate, scope and monitor them.
• Making it painful for users. Constant prompts push people toward workarounds. Use single sign-on and risk-based checks so low-risk access stays smooth and step-up checks happen only when conditions change.
• No owner. Zero trust spans identity, endpoint, network and application teams. Without one accountable leader and a roadmap, each team optimizes its own piece.

Frequently asked questions

Is zero trust the same as getting rid of the VPN?

Not exactly. Zero trust removes the idea that being on the VPN earns trust, so many organizations do retire broad VPN access over time. But a VPN can still exist as an encrypted tunnel. What changes is that every application checks identity, device health and policy on its own, regardless of how the connection arrived.

How long does a zero trust rollout take?

For most enterprises it is a multi-year program, not a single project. The federal strategy in OMB M-22-09 gave agencies until the end of fiscal year 2024 to meet a defined set of goals, and NIST spent four years building its reference implementations. Plan in phases: identity first, then devices, then application-by-application migration.

Does a small or mid-size business need zero trust?

Yes, though in a lighter form. A smaller company can apply the same principles with a cloud identity provider, MFA on every account, managed devices and single sign-on to its SaaS apps. That covers the identity and device pillars, which address the most common attack paths, without large network redesign costs.

What is the difference between zero trust and least privilege?

Least privilege is one principle within zero trust: give each user only the access their role needs. Zero trust is broader. It also requires checking every request, evaluating device health, securing all communication regardless of location, and revisiting access decisions as conditions change. You can have least privilege without zero trust, but not the reverse.

What to do next

1. Read the seven tenets in NIST SP 800-207 with your security lead and score your current environment against each one.
2. Build or refresh your inventory of users, service accounts, devices and applications, including team-purchased SaaS tools.
3. Pick one high-value application, such as HR or finance, and move it to identity-based access with MFA and device checks as a pilot.
4. Assign a single owner and a phased roadmap aligned to the five pillars, with funding tied to each phase.

Sources

• NIST SP 800-207, Zero Trust Architecture (publication page)
• NIST SP 800-207, Zero Trust Architecture (full text PDF)
• NIST: NIST Offers 19 Ways to Build Zero Trust Architectures (June 2025)
• OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• CISA: Zero Trust Maturity Model
• CISA: Multifactor Authentication

Last reviewed: October 2026.