What NIST’s zero trust definition quietly required agencies to know

The week

On August 11, 2020, the National Institute of Standards and Technology, the federal agency that writes many of the government’s technical standards, published the final version of Special Publication 800-207, Zero Trust Architecture. It was developed with federal agencies and industry.

The final text closed a process that had run for almost a year. NIST released a first public draft in September 2019 and a second in February 2020. The second draft added a section on different approaches to building zero trust and responded to public comments. Its comment period closed in mid-March 2020, just as federal offices began sending staff home.

Much of the federal workforce was logging in from kitchen tables that summer. The systems that let them do so had been built for a small fraction of that load, and for a world where most work happened inside a guarded building.

“Zero trust” sounds like a slogan, and for a while it was mostly used as one. NIST gave it a working definition: a set of principles that move defenses from static network perimeters to users, assets and resources. Under the old approach, anyone who got past the network perimeter could wander freely inside. Under zero trust, access is checked at every request, and the answer depends on who you are, what device you carry and what you are trying to reach.

The document described logical components that make this work. A policy engine decides whether a particular request should be allowed. A policy administrator sets up, or shuts down, the connection based on that decision. Policy enforcement points stand in front of applications and data and carry out the verdict. NIST also set out several deployment approaches, so agencies could choose a path that fit what they already had.

The publication went further than a diagram. It listed the information sources a policy engine would draw on, including an agency’s continuous diagnostics system, identity records, activity logs, threat intelligence and data access policies. It discussed the threats to a zero trust design itself, such as an attacker subverting the decision process or stealing valid credentials. And it closed with a section on how an organization moves from a perimeter-based network to the new model, one step at a time.

It was also concrete about where the model would be tested. NIST walked through a set of scenarios that matched how agencies actually worked. They included an organization with satellite offices and remote staff, one spread across more than one cloud provider, one relying on contractors and other non-employees, collaboration across organizational boundaries, and services offered to the public. Each scenario showed where enforcement points would go and what the policy engine would need to know. Each also showed that the hard cases were the ones involving people and devices the agency did not fully control.

The timing mattered. Five months into the pandemic, agencies had moved much of their workforce onto remote access built for a fraction of that load. Virtual private networks, the encrypted tunnels that connect a remote laptop to an office network, and trusted internal networks were carrying more traffic, and more risk, than their designers had planned for. Once you were through the tunnel, the network often treated you as a trusted insider.

The policy setting was shifting too. In September 2019 the Office of Management and Budget had updated its Trusted Internet Connections policy. The older version pushed agency traffic through a small number of approved gateways. The update gave agencies more room to secure cloud and remote use in other ways. The Cybersecurity and Infrastructure Security Agency, CISA, followed in the spring of 2020 with interim guidance on securing telework under the new policy.

The threat picture added pressure. Through 2019 and 2020, CISA repeatedly warned that attackers were exploiting known flaws in widely used VPN appliances. The very devices carrying the remote workforce had become targets in their own right.

The intended audience was clear from the text. NIST wrote it for enterprise security architects in federal agencies, and described it as a conceptual model rather than a product specification. Nothing in it was specific to government, though. Banks, hospitals, states and counties could read the same definitions and apply them, and many did. Because NIST publications are free and widely referenced, the definitions could spread without anyone having to buy or license them. The abstract components still had to be shown working with real products, and that work would take years.

SP 800-207 mandated nothing on its own. It was guidance, not a rule. What it did was give program offices, architects and auditors a shared reference point. For the first time, when someone in a meeting said “zero trust,” there was a document everyone could open to check what they meant.

Most coverage in August 2020 treated SP 800-207 as a technical document about network design. For an agency CIO or program director, its significance was organizational. The publication defined zero trust tightly enough that a product labeled with the term could no longer stand in for a program.

Read closely, it is less a blueprint than a set of conditions an agency has to satisfy about itself before any blueprint works. Those conditions concern knowledge rather than firewalls or software: what the agency owns, who works for it, where its sensitive information lives and what is happening on its systems right now.

That makes zero trust a leadership topic as much as a technical one, and the knowledge it depends on is spread across offices that the security team does not run.

The argument below moves through seven parts. The first two cover the shift itself: from a guarded perimeter to per-request checks, and what the document actually defined. The third, the core of the piece, sets out what the model required agencies to know about themselves. The fourth and fifth cover the stakes: what rides on that knowledge gap, and what the definition changed for buyers and auditors. The last two turn to action: the order of work, and the questions that test readiness.

From a guarded perimeter to checking every request

For decades, most organizations protected their computers with a strong perimeter, the network boundary, guarded by firewalls. Anyone inside the perimeter was assumed to be legitimate. Employees working remotely connected through a virtual private network, which effectively placed their laptop inside that perimeter.

That model had a fatal weakness. Once an attacker got inside, by stealing a password or tricking someone into opening a malicious attachment, the network generally trusted them. They could move from system to system, looking for valuable data, with few further checks. Security people call this “lateral movement.”

Zero trust flips the assumption. Being on the network earns you nothing. Every time a person or a program asks to use a resource, the request is checked on its merits: who is asking, whether their device is healthy and up to date, whether this is a normal request for them at this time of day, and how sensitive the thing they want is.

A modern bank card works the same way. Your card does not get a free pass because it worked yesterday. Each transaction is weighed in the moment: the amount, the merchant, the location, your usual habits. A purchase that looks wrong gets declined or triggers a text. Zero trust applies that same per-transaction judgment to access inside an organization.

Why the perimeter strained in 2020

The pandemic exposed the perimeter model’s practical limits as well as its security ones. Federal policy had long steered agency internet traffic through a limited set of approved gateways. A remote employee using a cloud email service might have their traffic sent through a VPN to an agency data center, inspected, and then sent back out to the cloud. Each round trip added load and delay.

When most staff went remote at once, those chokepoints filled. Some agencies rationed VPN time or split traffic so that only some of it went through the tunnel. Each workaround traded security for capacity, because traffic outside the tunnel escaped the inspection the perimeter model relied on.

The VPN appliances themselves were a second problem. A device that grants network-level access to anyone with valid credentials is a valuable target. When it has a known flaw and has not been patched, an attacker can skip the credentials entirely. Several widely reported intrusions in this period began exactly that way.

What zero trust does not mean

The term invites three misreadings. It does not mean removing network controls. Segmentation and firewalls remain useful; they stop being the main basis for trust. It does not mean distrusting employees. It means that the system stops assuming a request is legitimate because of where it comes from. And it does not mean a single product. NIST described a set of functions that many products, old and new, might perform.

A few terms worth knowing

• Authentication is proving who you are, for example with a password plus a code on your phone.
• Authorization is deciding what you are allowed to do once your identity is known.
• Device posture is the health of the device making a request: whether it is managed by the agency, patched, encrypted and free of known problems.
• Telemetry is the stream of signals that systems produce about what is happening on them, such as logins, file access and network connections. It is the raw material for spotting trouble.

What the document defined

The central principle is simple. No user or device gets implicit trust because of where it is on the network. Each request for a resource is authenticated and authorized per session, using dynamic policy that can weigh identity, device state and other signals. “Per session” means the decision is made fresh for each period of use, not once and then forgotten.

NIST separated the decision from the enforcement. A policy engine decides, a policy administrator configures the path, and enforcement points guard the resources. The engine applies the rules, the administrator opens or closes the path, and the enforcement points are where a request is actually let through or stopped.

The seven tenets

The document set out seven basic tenets. In paraphrase, they are:

1. All data sources and computing services count as resources to be protected.
2. All communication is secured, wherever on the network it happens.
3. Access to each resource is granted per session.
4. Access is decided by dynamic policy, drawing on the identity of the requester, the state of the device and other attributes.
5. The organization monitors and measures the integrity and security posture of all the assets it owns or that connect to it.
6. Authentication and authorization are dynamic and strictly enforced before access is allowed.
7. The organization collects as much information as it can about the current state of its assets, network and communications, and uses it to improve its security.

Three of the seven, the fifth, the sixth and the seventh, are about knowing and watching. They describe a continuous discipline of inventory, measurement and collection. Only the remainder describe how access is granted. The balance tells a reader where the work lies.

What feeds the decision

NIST described the policy engine’s logic as a trust algorithm. Its inputs include the access request itself, a database of subjects (people and programs), a database of assets with their known state, the access requirements for each resource, and threat intelligence and logs. Each input is something the agency must maintain.

The document also listed supporting data sources. For federal readers, the most telling was the continuous diagnostics and mitigation system, the DHS-led program that helps agencies see their devices and users. Others included identity management systems, a public key infrastructure for issuing digital certificates, security information and event management systems, activity logs and data access policies. The engine was only ever going to be as good as these feeds.

The deployment approaches

NIST described several ways to build this. One centers on enhanced identity governance, making the person’s or program’s identity the main factor in every decision. Another uses micro-segmentation, dividing the network into many small zones, each with its own guard. A third uses software-defined perimeters, where resources are hidden entirely until a user has been checked, so an unverified user cannot even see what is there to attack.

It then described deployment models, such as an agent on the device paired with a gateway in front of the resource, or a portal that brokers access to a set of applications. These models matter for buyers, because each one implies different products and different dependencies.

Threats to the design itself

A less cited section listed threats to a zero trust architecture. An attacker could try to subvert the decision process, or overwhelm an enforcement point so legitimate users are locked out. Stolen credentials and malicious insiders remain a risk, because a valid identity on a healthy device will pass the checks. Encrypted traffic limits what the network can see. The stores of policy and telemetry become targets because they describe the whole estate. And automated, non-person entities that administer the system need controls of their own.

That candor matters. NIST was saying that zero trust concentrates risk in the decision machinery and in the data that feeds it. Protecting those becomes a first-order job.

An incremental path, written down

The document also framed adoption as incremental, with agencies running hybrid environments for years. It set out a migration sequence: identify the actors, identify the assets, identify key processes and their risks, write policies for a candidate system, choose solutions, deploy and monitor, and then expand. The first three steps are discovery. Tools appear at step five.

That framing was realistic, and it gave agencies permission to start with one application or one user population instead of a full redesign. A sensible agency might begin with a single high-value system, prove the approach works, and expand from there.

What it required agencies to know

The easily missed part comes next. A policy engine can only decide well about resources it knows exist, users it can identify and devices whose state it can see. Each of those is a dataset that has to be complete, current and authoritative. In 2020 many agencies had none of them in that condition.

• An asset inventory. It has to cover on-premises, cloud and remote endpoints, including contractor and personally owned devices that reach agency resources. An “endpoint” is any device at the edge of the network: a laptop, a phone, a server. Many agencies held several partial inventories, each maintained by a different team for a different purpose.
• An authoritative identity source. Employees, contractors and service accounts each need lifecycle processes that remove access when roles end. A service account is an identity used by software rather than a person, such as the account a nightly billing job uses to read records. Contractor identities were often managed by the contracting company, outside the agency’s view.
• Classified resources. Access policy that varies by sensitivity requires knowing which applications and data stores hold what. Few agencies had mapped that below the system level. Knowing that a benefits system contains personal data is a start; knowing which tables hold Social Security numbers is what lets a policy treat them differently.
• Telemetry. Signals from endpoints, networks and applications have to feed decisions in near real time and be retained for review. Logging was frequently configured for compliance retention, not for live decisions. Keeping records for an auditor to read next year is a different job from feeding a decision that has to be made in the next second.

Each dataset needs an owner, a refresh frequency and a quality measure. For an inventory, the measure might be the share of devices seen on the network that appear in it. For identity, it might be the number of accounts with no matching person or contract. Those numbers are unglamorous, and they predict how far a zero trust program can go.

An agency cannot buy any of these. A vendor can supply a policy engine. It cannot supply an agency’s knowledge of its own estate. For that reason, programs that started by buying enforcement components often stalled. The components had nothing reliable to enforce against.

How each dataset gets built

Each of the four has a known path, and most of the raw material already exists somewhere in an agency.

Devices. The usual method is reconciliation. Endpoint management tools know about managed laptops. Network discovery sees whatever connects. Procurement and property records show what was bought. Comparing the three reveals devices that connect but are not managed, and devices that are recorded but never seen. Federal civilian agencies could draw on the continuous diagnostics program for much of this. The quality measure is the gap between the lists, and it should shrink each quarter.

People and programs. The human resources system is the natural authoritative source for employees, because it knows start and end dates. Contractors are harder. Federal agencies issue personal identity verification cards to many long-term contractors, which gives a hook for identity, but the agency still needs the contract end date to flow into the identity system. Service accounts need a named human owner, a stated purpose and an expiry review. Without an owner, nobody can say whether an account is still needed.

Data. Agencies have more classification material than they often realize. Records schedules describe what a system holds. Privacy impact assessments and Privacy Act system of records notices identify systems that hold personal information. Those documents are a starting point for labeling. Moving below the system level, to tables and files, takes the program office that owns the data, because only it knows what each field means.

Signals. The first task is to list which systems produce logs, where they go and how long they stay. The second is to decide which signals a policy decision needs in real time, such as device health or an unusual login location. Those feeds need reliable, low-delay delivery. The rest can go to cheaper storage for investigation and audit.

Why this lands on the leadership table

The prerequisites also cross organizational lines. Inventories belong to infrastructure teams, identities to human resources and security, data classification to program offices and records officers. A zero trust program that lives only inside the security office cannot fix data that other offices own. A program needs a sponsor with authority over all four datasets, which usually means someone above the CISO, the chief information security officer.

Hence a deputy secretary, a chief operating officer or a county administrator has a role here. The hardest problems are organizational, such as who tells human resources that departure dates must flow to the identity system the same day, or who makes program offices label their data.

How the burden differs by level of government

A federal civilian agency has shared programs to draw on, such as continuous diagnostics and government-wide identity cards, along with a central policy office setting expectations. It also has a large, layered workforce of employees and contractors, which makes identity cleanup slow.

A state agency often handles data under several regimes at once. Federal tax information shared with a state revenue or benefits agency comes with IRS safeguarding requirements. Criminal justice information comes with the FBI’s CJIS Security Policy, which sets its own authentication rules. A zero trust design has to satisfy each of them, and the data map has to show which data falls under which regime.

A county faces a different difficulty. Many counties are not single organizations in the management sense. The sheriff, the clerk, the assessor and the treasurer may be separately elected and run their own technology. No county administrator can order them to share a device list. Zero trust in that setting begins with an agreement among officials, not a purchase order.

One county’s first day with a gateway

Suppose a county wants to protect its property tax and social services systems, and its security team buys a modern access gateway. On day one, the gateway asks whether a device is managed. The county has three device lists, from IT, from the sheriff’s office and from a contractor who supports field laptops, and none agrees with the others. It asks whether a person is still employed. The identity system shows several hundred accounts with no matching current employee, many belonging to former seasonal staff and contractors. It asks how sensitive the data is. Nobody has labeled it.

The gateway is not broken. It simply has nothing reliable to decide with. The county had a better path. It could have spent the first months consolidating the device lists, cleaning up accounts and labeling its most sensitive data. Then it could have switched on the gateway for one system at a time.

What rides on the gap

A senior official could fairly ask why any of this deserves time on a crowded agenda. The answer is that the gap zero trust addresses touches almost everything an agency answers for.

Mission. Agencies hold tax records, health information, benefit files and law enforcement data. When an intruder moves freely inside a network, the damage goes well beyond the technical. Payments can be delayed, services taken offline and sensitive records exposed. Checking each request exists to make sure a single stolen password does not open every door.

Money. Security budgets are finite. Without a clear definition, agencies risk buying overlapping products that each claim to deliver zero trust. With one, spending can be directed at the specific gaps that matter, and existing tools can be reused rather than replaced.

Workforce. The pandemic made remote and hybrid work normal for many public employees. A model built around a trusted office network fits that reality poorly. A model that checks the person, the device and the request fits it well, and can make secure access smoother for staff who work from many places.

Oversight. Inspectors general, legislators and the public increasingly want evidence, not assurances. Zero trust done properly produces measurable facts: how many devices are known, how many accounts are clean, how much sensitive data is labeled. Those facts are easier to defend in a hearing than a list of products purchased.

Trust. Residents share personal information with government because they must, not because they choose to. Each breach erodes their willingness to engage with digital services, which in turn raises costs for everyone. Protecting that trust is part of delivering the service.

Where the gap does its damage

The knowledge gap does harm in specific ways. An unknown device cannot be patched, so it stays vulnerable after everyone else is fixed. An orphaned account belonging to a departed contractor is a credential nobody will miss if it is stolen. Unlabeled data gets the same protection as trivial data, which in practice means the minimum. And logs that nobody reads in real time turn an intrusion into a forensic exercise months later.

Each of these shows up in incident reviews across sectors. The common thread is that the organization could not protect what it did not know it had.

The case that zero trust was oversold

Skeptics had a fair argument in 2020. The term was already heavily marketed, and a new standard might simply give vendors a better label. Legacy systems, which many agencies depend on, could not make per-request decisions without costly rework. Some argued that agencies would do better to finish basic hygiene, such as patching and multifactor authentication, before chasing an architecture.

That argument is largely right about the order of work and wrong about the conclusion. NIST’s own migration sequence starts with exactly the basics the skeptics named. Reading the document carefully supports doing the fundamentals first. Its value was to explain why the fundamentals matter and how they connect to an eventual design.

What it changed for buyers and auditors

Before the publication, almost any security product could be marketed as zero trust. Afterward, a program office could ask a sharper question: which logical component in the NIST model a product implements, and what it depends on. That let contracting officers compare offerings by function and spot overlaps before buying a third tool for the same job.

The model also gave auditors and inspectors general a better yardstick. Perimeter-era reviews asked whether a firewall or VPN existed. The NIST model invites different questions: whether access decisions are made per session, whether device posture is considered, and whether policy is written down and enforced the same way across applications. Those questions expose weaknesses that checklist audits missed, and they push agencies toward measurable evidence.

State and local governments, which often adopt federal frameworks without federal budgets, used the model to map what they already owned. An existing identity provider or endpoint management platform could be placed in the architecture, and the gaps worth funding identified. That made a smaller budget go further than starting over.

There was a cost to the new vocabulary. Once zero trust had a standard definition, it also had a standard marketing claim. Agencies needed staff who could read a vendor’s architecture against the NIST components and tell the difference between a policy enforcement point and a rebranded VPN. That expertise was scarce in 2020 and remained scarce for years.

How procurement documents changed

A requirement written in perimeter terms might ask for a remote access solution supporting a set number of users. A requirement written against the NIST model asks different things. It asks which component the product provides. It asks which data sources it must consume, and in what format. It asks how its policy decisions are logged and how the agency can export them. And it asks how the product behaves when a data feed is missing or stale.

That last question is revealing. A product that fails open, granting access when it cannot check device health, behaves like a perimeter in disguise. A product that fails closed can lock out a workforce when a feed breaks. The agency has to choose, system by system, and write that choice into its policy.

What auditors began to ask for

The new questions came with new evidence. An auditor testing per-session decisions would ask for decision logs showing requests granted and denied, with the reasons. Testing device posture means asking how many requests came from unmanaged devices and what happened to them. Testing policy consistency means comparing written policy to the configuration of each enforcement point.

Those requests favor agencies whose datasets are clean. An agency with an accurate inventory can show coverage. One with three conflicting lists cannot even define the denominator.

The trade-offs that came with the model

Per-request checks have costs. Each check adds a small delay, and a poorly tuned policy can add many. Strict device rules can block staff using older equipment or personal devices for legitimate reasons. Help desks see more calls when a policy is introduced. And legacy applications that expect a trusted network may need proxies or rework before they can sit behind an enforcement point.

None of those costs is a reason to stop. They are reasons to pilot, measure the friction and fund the support that makes the new model usable. A program that ignores friction will see staff route around it, which recreates the trust gaps it was meant to close.

Datasets first, tools last

For a program director today, the practical reading of SP 800-207 is a sequence. Fix the datasets first, write enforceable policy second, and buy enforcement third. Agencies that followed that order spent the following years extending a working foundation. Agencies that reversed it spent those years integrating tools that could not see what they were meant to protect.

A sequence with milestones

A program can be laid out in phases, each with an exit test. In the first phase, the agency names its sponsor and dataset owners, and publishes baseline quality numbers for devices, identities, data labels and log coverage. The exit test is agreement on those numbers, however poor they are.

In the second phase, the agency fixes the worst gaps for one high-value system and its users. It reconciles their devices, cleans their accounts, labels the system’s data and routes its signals to a place where decisions can use them. The exit test is that a policy can be written for that system using only reliable inputs.

In the third phase, enforcement goes live for that system, with denials logged and reviewed. The exit test is a period of stable operation with measured friction. Only then does the program expand, carrying the dataset work ahead of each new enforcement step.

Signs of health and signs of trouble

A healthy program tends to show a few signs:

• One senior sponsor with authority over the inventory, identity, data classification and logging, and a regular report showing quality numbers for each.
• A written access policy that says clearly who may reach which category of data from which kind of device.
• A pilot on one important application, with results measured and shared before expansion.
• Procurement documents that map each purchase to a specific component in the NIST model.

Struggling programs show the mirror image:

• Buying first. Purchasing an enforcement product before the agency knows what it owns and who works for it.
• Leaving it to the security office. Treating zero trust as a cybersecurity project when most of the underlying data belongs to other parts of the organization.
• Forgetting non-human identities. Cleaning up employee accounts while service accounts and contractor access remain untouched.
• Logging for the archive. Collecting records to satisfy retention rules without making them usable for live decisions.
• Counting tools, not coverage. Reporting how many products are deployed rather than how much of the estate they can actually see and govern.

Choosing the first system

The first system shapes everything after it. It should matter enough that success is noticed, such as a system holding benefits data or tax records. Its user population should be small and well defined. Its owner should be willing to accept some friction in exchange for being first. And its data should be possible to label within a few months.

Agencies often pick the wrong first system for understandable reasons. A system used by everyone produces the most visible result but the most complaints. A low-value system is easy but proves little. The middle path, important but contained, gives the program a credible case for the next round of funding.

Device lists, accounts and data labels come before zero trust products

A senior official does not need to master the architecture to steer the program. These questions get to the heart of readiness.

• Do we have one list of every device that touches our systems, including contractor and personal devices, and what share of devices on our network actually appear on it?
• How many of our accounts match no current employee, contractor or documented service, how fast do we remove leavers, and can we revoke contractor identities the contractor manages?
• Which systems hold our most sensitive data, is it labeled below the system level, and do our logs feed real-time decisions or only satisfy retention rules?
• For each zero trust product we own or plan to buy, which NIST component does it implement, and which of our datasets does it depend on?
• Who is the single sponsor with authority across infrastructure, human resources, security and program offices, and which one application would make the best first pilot?

Reading the answers

Strong answers come with numbers and names. The device answer gives a percentage and a trend. The account answer gives a count of orphaned accounts and the time it takes to remove a departing user. The data answer names the labeled systems and admits which are not. The product answer maps each tool to a component. The sponsor answer names a person, not a committee.

Weak answers describe projects instead of results. They say an inventory effort is under way, a tool will provide visibility, or a working group is looking at identity. Those may be true, and they may be the right first steps. They are not evidence that the agency knows itself yet.

Who does the work, and what it costs

The dataset work needs people more than products. Each dataset owner needs analyst time to reconcile records and chase exceptions. Program offices need staff who can say what their data means. The identity team needs time from human resources and contracting officers to fix the feeds that drive joiners and leavers.

Those costs are easy to underestimate because they are spread across many budgets. A program that funds only the security office’s share will find that the other offices treat requests as unfunded mandates. The sponsor’s job includes finding the money for that distributed work, or accepting a slower schedule.

The return is broader than zero trust. A clean inventory speeds patching. Clean identities reduce audit findings. Labeled data helps records management and privacy compliance. Agencies that framed the dataset work as shared infrastructure, rather than a security project, found it easier to fund.

When to ask again

These questions are worth repeating at each budget cycle, because funding decisions are where sequence is won or lost. They are also worth asking after any reorganization, merger of offices or major contract change. Each of those events scrambles device lists and identities, and the datasets need repair before enforcement can rely on them again.

Those questions do not require a technical background. They require the willingness to treat knowing your own organization as the first and hardest security control.

With hindsight

Within a year the vocabulary turned into a mandate. The trigger was partly an intrusion. In December 2020, the compromise of SolarWinds network management software came to light. It affected several federal agencies, and the attackers moved through trusted access and abused identity systems to reach email and other data. Perimeter defenses had done little to stop them.

Executive Order 14028 in May 2021 directed agencies to plan for zero trust, and to describe within 60 days how they would adopt it. That August, OMB memorandum M-21-31 set maturity tiers for event logging, giving agencies a schedule for the telemetry that zero trust depends on.

OMB memorandum M-22-09, issued in January 2022, set specific goals to be met by the end of fiscal year 2024, including phishing-resistant multifactor authentication for agency staff. Multifactor authentication means proving your identity with more than one thing, such as a password plus a physical key; “phishing-resistant” means a fake website cannot trick a user into handing that proof over. The memo also asked each agency to name a zero trust implementation lead, and it called for a complete inventory of devices and progress on categorizing data.

The memo’s structure tracked the argument above. Its identity and device goals were dataset goals, and its data goals asked agencies to know what they held before protecting it differently. The requirement to name a single lead echoed the need for one sponsor with authority across offices.

CISA’s Zero Trust Maturity Model, revised in 2023, gave agencies a way to measure progress across identity, devices, networks, applications and data. It also includes cross-cutting capabilities for visibility and analytics, automation and orchestration, and governance. Those three cross-cutting capabilities are, in effect, the telemetry and ownership work described here. The Department of Defense published its own zero trust strategy in November 2022, with a target level of maturity by fiscal year 2027.

NIST kept building on the document. In 2023 it published SP 800-207A, applying the model to cloud-native applications that run across multiple locations. In June 2025 its National Cybersecurity Center of Excellence released the final version of SP 1800-35, a practice guide built from 19 example implementations with 24 industry collaborators. The guide gave agencies tested patterns rather than diagrams.

So a guidance document published during the pandemic became, in less than two years, the basis for deadlines that agency leaders were expected to meet and report on. Its definitions became the language of budgets, audits and contracts.

NIST’s framing of zero trust as incremental and dependent on fundamentals held up. Progress across government has been uneven, and the hardest parts have been the prerequisites: complete inventories, identity hygiene for contractors and service accounts, and legacy systems that cannot take part. Older systems were often never designed to check identity per request, and replacing them is slow and expensive.

State and local governments moved more slowly and less evenly. The State and Local Cybersecurity Grant Program, created by the 2021 infrastructure law, provided federal funds over four years for state and local cybersecurity plans. The same logic applied to those plans. A state or county that skipped inventories and identity cleanup would hit the wall federal agencies had already found, however much it spent on new architecture.

By 2026 a pressing open question is how the same model applies to automated workloads and AI agents acting on behalf of users. An AI agent might read files, send messages and call other systems on someone’s behalf, all without a human clicking each step. That makes the identity foundation more important, because those agents request access far more often than people do. SP 800-207 had already flagged non-person entities in the administration of a zero trust system as a distinct risk.

The unglamorous work came first and still does. Agencies that invested early in knowing their devices, people, data and signals have been able to absorb each new mandate and each new kind of user. Those that bought tools first have kept discovering that the tools are only as good as the knowledge underneath them.