Zero Trust Architecture Implementation in the Public Sector
What Zero Trust Architecture Actually Means, and What It Doesn't. Zero Trust Architecture is a data-centric security model that …

What Zero Trust Architecture Actually Means, and What It Doesn't
Zero Trust Architecture is a data-centric security model that treats every network, every user, and every device as a potential threat vector, regardless of location relative to a network boundary. No entity receives trust by virtue of where it sits. Access decisions happen continuously, not once at login. Verify explicitly, enforce least-privilege access, assume breach at all times.
John Kindervag coined the term at Forrester in 2009. NIST SP 800-207, published in August 2020, became the definitive federal technical reference because it gave agencies a common vocabulary and a set of vendor-neutral architectural tenets that are actually adjudicable. That last part matters more than people acknowledge.
Here is where agencies consistently go wrong: they hear "zero trust" and think firewall upgrade. VPN replacement. MFA rollout. Any of those framings will generate activity without generating protection, which is genuinely worse than acknowledging the gap honestly and sitting with it. The enabling technologies, MFA, endpoint detection and response, secure access service edge, identity provisioning platforms, are means to an architectural end. They serve the pillars. The pillars are not built around the tools. Get that backwards and you will spend real money on a security posture that looks complete on paper and crumbles under actual adversarial pressure.
Most agencies get it backwards.
The Federal Mandates That Turned ZTA from Best Practice into Requirement
Executive Order 14028, signed in May 2021, required federal civilian agencies to develop Zero Trust adoption plans. SolarWinds was the proximate catalyst: adversaries moved laterally through trusted federal networks for months, undetected, while perimeter defenses functioned exactly as designed. The perimeter didn't fail because agencies were negligent. It failed because the threat had simply evolved past what perimeter architecture was ever built to handle.
The operational weight came from OMB Memorandum M-22-09 in January 2022, which set specific cybersecurity standards aligned to CISA's five pillars and established end of fiscal year 2024 as the compliance target. The FY 2024 federal civilian cybersecurity budget request reached $12.7 billion, a 13 percent increase, with zero trust adoption as the stated top priority. That number reflects genuine institutional seriousness.
The Department of Defense operates under a separate, parallel mandate requiring full ZTA implementation across all DoD components by end of FY 2027, overseen by the Zero Trust Portfolio Management Office. DoD Directive-Type Memorandum DTM-25-003, effective July 2025, adds a Chief Zero Trust Officer position to coordinate DoD-wide execution. That structural addition is an acknowledgment, explicit and somewhat overdue, that this effort requires dedicated governance rather than distributed ownership across components that each have their own priorities and timelines.
State and local agencies sit in a materially different posture. No equivalent federal mandate governs them, and the absence creates a measurable drag on progress. The incentive architecture is simply not the same, and pretending otherwise doesn't help anyone plan.
One thing worth naming clearly: the mandates define the destination. They do not prescribe the path. That is precisely what CISA's maturity model exists to provide.
CISA's Zero Trust Maturity Model as the Practical Roadmap Structure
CISA's Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Each pillar can be matured independently. For agencies that cannot transform everything simultaneously, which is every agency, that modularity is not a minor convenience. It is the only reason a phased implementation is coherent rather than arbitrary.
Three cross-cutting capabilities reinforce all five pillars: Visibility and Analytics, Automation and Orchestration, and Governance. These are not a sixth pillar. They are the connective tissue that makes pillar controls measurable and coherent as a system rather than as a collection of independently deployed tools that technically share a network.
Version 2.0 of the ZTMM, released in April 2023, added an "Initial" maturity stage to the existing spectrum running from Traditional through Advanced to Optimal. That addition was deliberate and practically significant. It acknowledged that many agencies needed a recognized starting position rather than being measured solely against an aspirational endpoint. Telling an agency they are "pre-Traditional" is demoralizing and not operationally useful. Giving them a waypoint is.
The pillar structure provides a mechanism for prioritizing investments and sequencing actions based on what enables what. Identity typically comes first, not because CISA prescribes a universal sequence, but because identity verification is the foundation everything else sits on. You cannot enforce device trust if you haven't established who is asking. The model describes maturity states. Agencies must make the sequencing judgment themselves, informed by their own risk profile and existing capabilities. No vendor will make that judgment correctly on their behalf.
Where Most Agencies Actually Start: Identity and Access as the First Pillar
Identity is the nearly universal starting point, and the reasoning is empirical. It delivers the most immediate risk reduction, it aligns with IAM investments most agencies already have in some form, and it creates the verified-user foundation that device and network controls subsequently build on. The concentration of early effort in the identity pillar is not accidental. It tracks with where measurable progress was achievable in the near term.
The core actions are well-established: enforce phishing-resistant MFA across the workforce, establish federated identity and credential access management under the ICAM framework, move toward device-bound credentials that cannot be replayed or stolen independently of the authenticated endpoint. Each of these is tractable. None of them is trivial at federal scale.
The DoD illustrates the scale problem without softening it. Achieving federated ICAM across 58 components, each carrying different legacy systems and different identity infrastructures, is one of the two areas DoD's Zero Trust Portfolio Management Office identified as most behind schedule as of early 2025. The concept is well understood. The implementation surface is enormous. Those two facts coexist and neither cancels the other.
The most common early mistake is treating MFA deployment as completing the identity pillar. MFA is the entry point, necessary but not sufficient. An agency that stops there has conflated one step with a finished state. That mistake is prevalent enough, and consequential enough, to say directly.
The Legacy Infrastructure Problem That Slows Every Subsequent Phase
More than 80 percent of organizations encounter significant implementation friction when legacy infrastructure is involved, according to Gartner. In government, the problem is structurally more severe because infrastructure replacement cycles are measured in decades. This is not an exaggeration. It is a description of how federal computing actually works in a large portion of agencies.
The government-specific legacy profile is distinctive in ways that commercial frameworks tend to underestimate. Mainframes processing benefits and tax records. SCADA and operational technology systems embedded in defense and utility environments. Applications that predate modern API architectures and cannot be patched to support continuous authentication without full architectural intervention. These are not edge cases. They are often the core.
Three realistic options exist for legacy systems that cannot be modernized quickly. First, wrap them with a ZTA-compatible proxy layer that enforces access controls at the perimeter of the legacy component without requiring the underlying system to change. Second, isolate them through micro-segmentation so a breach of the legacy system cannot propagate laterally into the broader environment. Third, plan their decommission with a defined timeline and explicit interim risk containment measures. The worst outcome, the one that occurs more frequently than it should, is treating legacy systems as exceptions to be addressed later and never defining what "later" actually means in operational terms.
Federated agency structures compound this in a distinct way. When ZTA tools are deployed in siloed fashion across bureaus or components without coordination, the architecture protects disconnected fragments rather than the organization as a whole. Federal reporting on the FY 2024 deadline identified this directly as a systemic challenge.
The DoD context adds another layer. Air-gapped networks, coalition environments, and edge deployments mean "continuous verification" requires technical solutions that look materially different from what a cloud-native commercial environment demands. Agencies that import DoD guidance without accounting for that context will misapply it in ways that create more risk than they resolve.
The honest planning question for any legacy system is not "can we apply ZTA to this." It is: what is the risk if we cannot, and how do we contain it while we decide.
Phasing the Implementation: How to Sequence the Five Pillars Given Real Constraints
No universally correct sequence exists. The evidence does point to a defensible logic. Identity first, because it is the verification foundation. Devices next, extending trust decisions to endpoints on the basis of the verified identities now established. Networks third, applying micro-segmentation and least-privilege routing informed by what you now know about users and devices. Applications and Workloads fourth, enforcing granular access controls at the application layer. Data last, because classification and tagging at scale is the most technically and organizationally complex undertaking in the entire model, and rushing it produces false confidence in data controls that aren't actually functioning.
The DoD's approach provides a useful reference for understanding what explicit sequencing looks like at scale. The DoD mapped 152 discrete activities across its ZTA pillars, with 91 target-level activities due by FY 2027 and 61 advanced activities due by FY 2032. Even a well-resourced, mandated program requires sequencing across years. That is not a failure of ambition. It is an accurate accounting of what this actually takes.
The data pillar's position at the end of the sequence is consistent across implementations, and the DoD's own PMO identified data tagging standards and implementation as one of the two most lagging areas across its 58 components as of early 2025. Classification at scale requires organizational consensus on what data means, not just technical tooling to apply labels.
The cross-cutting capabilities, Visibility and Analytics, Automation and Orchestration, and Governance, must be built in parallel with the pillars, not deferred as a later phase. They are what enables agencies to know whether the pillar controls are functioning. Building pillars without building visibility is like installing locks and never checking whether they close.
Two programs illustrate the value of bounded initial scope. The Navy's Flank Speed program and DISA's Thunderdome both demonstrated effective ZTA implementation when the initial deployment was scoped to a defined environment with clear boundaries. The lesson is consistent across every implementation that worked: bounded initial deployments succeed, enterprise-wide simultaneous rollouts do not.
What Honest Progress Looks Like, and What the Deadline Data Reveals
Gartner predicted in 2024 that 75 percent of U.S. federal agencies would fail to implement zero trust security policies through 2026, citing funding and expertise shortfalls and noting that Congressional budget timing meant funds likely wouldn't be available until the second quarter of FY 2024, leaving a partial year to achieve targets that required years of sustained effort. That prediction was not pessimistic. It was observational.
A GDIT survey from 2022 found that only 49 percent of federal IT leaders expected their agency to meet all OMB requirements by the 2024 deadline, with another 21 percent expecting to meet most but not all. The majority already knew two years out. They knew and kept working anyway, which is actually the correct response.
DoD's internal data as of early 2025 showed only 14 percent of target-level ZTA activities completed across all 58 components, against a 2027 deadline. That figure is stark. It is also not primarily a motivation problem. It reflects genuine structural constraints: funding timelines, procurement cycles, workforce expertise gaps, and technical debt embedded in legacy systems that no amount of urgency dissolves.
Concrete early milestones do exist. By the fourth quarter of FY 2024, 51 agencies had onboarded with CISA's Vulnerability Disclosure Program platform. Measurable, verifiable, real.
The reframe that agency leadership most needs: "meeting the deadline" and "achieving zero trust" are not the same thing. Agencies that pursue checklist compliance without architectural coherence will accumulate activity without accumulating protection. The deadline is an accountability mechanism. The architecture is the actual objective. One of these matters in five years; the other matters in five minutes when something breaches.
Procurement, Tooling, and the FedRAMP Constraint Agencies Work Within
Federal agencies procure ZTA-enabling tools within a constrained environment. FedRAMP authorization is the threshold requirement for cloud services, and GSA maintains contract vehicles for ZTA-related acquisitions. These structures exist for legitimate security reasons. They also introduce a meaningful gap between "a tool is technically capable" and "an agency is authorized to deploy it," and that gap must be incorporated into any realistic implementation timeline. An agency that identifies the right tool in January and assumes production deployment by March has misunderstood the authorization timeline, probably by six to twelve months.
State and local agencies face structurally similar constraints with different specifics. Limited internal expertise and constrained capital budgets push many toward managed security services and FedRAMP-authorized cloud solutions as practical paths to ZTA capabilities. That path is legitimate, but it shifts the dependency to the vendor's roadmap and the managed service's scope rather than eliminating the underlying challenge.
Tool selection should follow pillar and maturity stage, not precede them. Agencies that select tools first and then attempt to map them backward to architectural pillars reliably create gaps, because no single tool spans a full pillar, and adjacent tools rarely integrate without meaningful engineering effort. The NIST National Cybersecurity Center of Excellence's Implementing Zero Trust Architecture project provides vendor-agnostic implementation guidance and reference architectures. It helps agencies evaluate tooling against architectural requirements rather than vendor marketing claims. It is underutilized, which is a shame given that it is free and authoritative.
Governance, Visibility, and the Controls That Tell Agencies Whether ZTA Is Working
The three CISA cross-cutting capabilities are what separate ZTA as a live, operational security posture from a point-in-time configuration that decays the moment the environment changes. Visibility and Analytics tells you what is happening. Automation and Orchestration makes continuous verification operationally feasible at scale. Governance ensures access policies are coherent, consistently enforced, and regularly reviewed. Remove any one of them and the other two degrade.
Continuous monitoring is not optional within ZTA. It is the mechanism that makes "continuous verification" substantive rather than rhetorical. Without it, agencies revert to periodic-audit thinking operating inside a zero-trust label. That combination is genuinely dangerous: the organizational belief that controls are working, without the telemetry to confirm it.
The Federal Zero Trust Data Security Guide, published in October 2024 and developed collaboratively by more than 70 people from over 30 agencies, is the most current cross-agency consensus on governing data risk within a ZTA context. Its collaborative provenance means it reflects implementation realities. That is not a small thing when most guidance in this space reflects what implementers wish were true.
Governance in a ZTA environment requires redesigning the mechanisms built for a perimeter model. Policy enforcement points, access review cycles, incident response procedures: all of these need to operate under the assumption that access is continuously re-evaluated, not granted once and checked again at the next audit cycle. That is a genuine operational transformation, and organizations that treat it as a configuration change will discover the difference the hard way.
Automation is the scaling mechanism. An agency relying on manual controls at the Identity or Device pillar cannot advance toward Advanced or Optimal maturity across all five pillars. The volume of access decisions in any large agency environment exceeds what human review can sustain, full stop.
The actual measure of ZTA maturity is not the number of tools deployed, the number of policies written, or the number of compliance checkboxes marked. It is whether access decisions across the environment are being made on the basis of continuously verified identity, device health, and least-privilege rules. That is the only measurement that matters. Everything else is infrastructure in service of it.


