Zero Trust Implementation Guide: NIST 800-207, the CISA Maturity Model, and a Rollout Order That Works

Zero trust has been a stated federal policy since 2021 and a marketing label for longer. This guide sticks to the primary documents: what NIST's SP 800-207 says, how CISA's maturity model breaks the work into stages, what the U.S. federal deadline in OMB memo M-22-09 taught agencies, and what NIST's practice guide SP 1800-35 offers as tested builds. It ends with a rollout order and a worked example of how privileged-account coverage grows phase by phase.

It covers the whole environment: users, devices, networks, applications and data. Securing the SaaS applications a company already runs, including OAuth grants and offboarding, is a narrower problem covered in our SaaS security best practices guide. Cloud misconfiguration is in the CSPM guide.

What the standards define

NIST's SP 800-207 says zero trust assumes no implicit trust based on physical or network location or on asset ownership, and that the focus moves from network segments to protecting resources. It lists seven tenets, paraphrased here:

1. All data sources and computing services count as resources, including SaaS and personally owned devices that reach enterprise resources.
2. All communication is secured regardless of network location. A request from inside the old perimeter meets the same requirements as one from outside.
3. Access is granted per session, with least privilege, and access to one resource does not carry over to another.
4. Access is decided by dynamic policy, using the state of the client identity, the application and the requesting asset, plus behavioral and environmental attributes where the organization chooses.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted.
6. Authentication and authorization are dynamic and strictly enforced before access is allowed, with continuous reevaluation.
7. The enterprise collects as much information as possible about the state of assets, infrastructure and communications and uses it to improve its posture.

The document says these tenets are an ideal goal and that not all may be fully implemented in their purest form. That sentence is a permission slip for phasing the work. NIST's SP 800-207A extends the model to cloud-native applications in multi-cloud and hybrid environments, with policy tied to identities rather than IP addresses or subnets. For multi-cloud context, see our multi-cloud strategy guide.

The CISA maturity model, version 2.0

CISA's Zero Trust Maturity Model (version 2.0, April 2023) has five pillars and three cross-cutting capabilities, and gives examples of four stages inside each pillar.

Version 1.0 had three stages; version 2.0 added "initial" and aligned the pillars with M-22-09. CISA describes the model as one of many roadmaps, so you can self-assess pillar by pillar. Expect an uneven result: in CISA's report on federal progress, some pillars were easier to address than others, and agencies put their effort there first.

The federal deadline as a case study

Executive Order 14028 (May 2021) directed agencies to move toward zero trust. OMB's memo M-22-09 (January 26, 2022) set specific goals to be met by the end of fiscal year 2024, organized by the CISA pillars. It applies only to federal civilian agencies. Requirements worth copying as benchmarks include:

• Enterprise-wide strong MFA enforced at the application layer, with phishing-resistant MFA required for agency staff, contractors and partners, and offered as an option to public users.
• Removing password policies that require special characters or regular rotation, within one year.
• Considering at least one device-level signal alongside identity when authorizing access.
• A zero trust architecture plan for each agency, submitted to OMB and CISA.

CISA's January 2025 report to Congress says agencies made considerable advances over three years and that phishing-resistant MFA rose significantly after the mandate. It also lists what slowed them: constrained budgets, legacy technology that could not integrate with zero trust capabilities and needed workarounds, and vendors whose products lacked required features (encrypted DNS support in servers is the example). Measured progress on unglamorous groundwork was large: unknown or uncategorized device types in agency dashboards fell from 55% in the first quarter of fiscal 2023 to just under 5% in the third quarter of fiscal 2024.

A private company should take three points from this. Inventory comes first, since you cannot apply device or identity policy to assets you cannot see. Legacy exceptions are the norm, not a sign of failure. And funding matters: the report credits Technology Modernization Fund money for much of the progress, and few companies have an equivalent unless they budget for it.

NIST SP 1800-35: tested example builds

NIST's National Cybersecurity Center of Excellence published the final SP 1800-35, Implementing a Zero Trust Architecture in June 2025, after five drafts starting in August 2022. According to NIST's announcement, the work involved 24 vendors and demonstrated 19 sample zero trust architecture implementations. The builds follow a crawl, walk, run progression and map their security capabilities to the NIST Cybersecurity Framework and SP 800-53 Rev. 5.

How to use it: find the example whose identity provider, endpoint tooling and network layout are closest to yours, and read its configuration and the capability mapping. It is a reference for what works together and for the policy decisions you must make, not an endorsement of any product, and it does not price anything.

A rollout order, with a worked example

The order below is our recommendation, not a NIST or CISA sequence. It follows the principle that a stolen privileged credential does more damage than an unsegmented subnet, so identity and privilege come before network redesign.

Illustration: a company with 240 privileged accounts: 40 human administrators, 60 cloud administrators, 90 service accounts, 30 vendor accounts and 20 break-glass accounts. All numbers and phase results are assumptions we chose, checked with a script, to show how coverage builds.

Thirty legacy service accounts (12.5% of the total) stay outside the controls because their applications cannot use short-lived credentials. The right response is to vault them, rotate their secrets, restrict where they can log in and set a retirement date, then report them as an exception rather than count them as covered. Break-glass accounts are excluded from the no-standing-privilege measure by design, so the count for phase 3 is 86.4% of the 220 accounts that are not break-glass.

The table also shows why phase 1 alone can mislead. Half the estate is protected against phishing, yet no one has lost a standing admin right, so a token stolen after login still carries full privilege. The second phase does the work that limits blast radius.

Where products fit

Zero trust network access (ZTNA) products broker connections to specific applications instead of placing a user on a network. They can replace much VPN use, but check that they support the protocols and legacy applications you have, since some older client-server systems need extra connectors. Endpoint tools supply the device signal. Identity providers are the policy decision point for most of the design. Segmentation tools matter most in phase 3. Ask every vendor which pillars and which tenets its product covers, and how it reports its decisions to your logs, since tenet 7 depends on that data.

The SaaS security guide applies the same ideas to third-party applications. For insurance questions tied to MFA and access controls, see our cyber insurance guide, and for how attackers use AI against identity systems, the AI threat intelligence guide. Data classification, which the data pillar needs, is in the cloud data governance guide.

Why programs stall

• Report-only mode never ends. Policies that only log stay in that state because someone fears breaking a workflow. Set a review date for each one.
• Exceptions have no owner. Every entry on the exception list needs a named person, a compensating control and an expiry date, or it becomes the new perimeter.
• The device signal is optional. M-22-09 asks agencies to consider at least one, and if your policy ignores device state, stolen credentials on an unmanaged laptop will pass.
• Metrics measure purchases. Count coverage instead: the share of privileged accounts with phishing-resistant MFA, applications behind SSO, administrators with standing rights, and traffic that is encrypted.

Limits of this guide

We give no cost estimates because none of the primary sources publish them, and vendor pricing changes. The phase timings and the 240-account example are illustrations. CISA's model is guidance, and NIST's SP 1800-35 builds show one path of many. Neither replaces a design review with a qualified security architect who knows your systems.

This article is for informational purposes only and does not constitute professional cybersecurity or IT advisory services.