DHS zero trust framework: what federal agencies actually owe and where implementation fails
Sienna VanceApril 29, 2026
Key takeaways
OMB M-22-09 required federal agencies to achieve specific zero trust milestones by end of FY2024, including phishing-resistant MFA — defined as hardware keys or PIV credentials, not authenticator apps — for all agency staff.
The CISA Zero Trust Maturity Model defines four stages per pillar. Most federal agencies self-report at initial maturity while operating with capability gaps that place them functionally between traditional and initial.
The most common implementation failure is not the identity pillar — MFA is widely deployed — it is the network pillar, where micro-segmentation requires mapping undocumented application dependencies before enforcement is possible.
Federal zero trust compliance requires integrating telemetry from identity, device, and network sources into a unified policy engine. Agencies that have deployed separate tools per pillar without integration have components, not architecture.
The data pillar is the most consistently underdeveloped. Data classification schemas exist in most agency documentation. Automated classification enforcement and data-access audit trails sufficient for incident investigation do not.
TL;DR
The DHS zero trust framework is a specific maturity model with defined capability requirements per pillar and compliance deadlines tied to OMB mandates. Most agencies have satisfied the initial maturity requirements — conditional access, basic MFA, perimeter encryption. Most have not completed the architectural changes that advanced maturity requires: micro-segmentation based on documented application dependencies, integrated telemetry feeding automated policy enforcement, and data classification enforcement beyond manual labeling. The gap between self-reported maturity and operational control state is where the framework is currently failing.
The maturity report and the network it described
A civilian federal agency submitted its FY2024 zero trust progress report to OMB. Identity pillar: advanced. Network pillar: initial, progressing toward advanced. Applications: initial. Data: traditional. During a Vulnox compliance assessment conducted shortly after the report period, we reviewed the network pillar claim. The agency had deployed next-generation firewalls with application-aware inspection and enabled encrypted DNS. Both are initial maturity capabilities. Their self-assessment toward advanced cited micro-segmentation planning documents and a vendor proof-of-concept that had not been deployed to production. East-west traffic within the agency's data center operated on flat network architecture with no zone enforcement. Lateral movement between systems was unrestricted once an attacker reached any internal endpoint.
The planning documents were real. The vendor engagement was real. The micro-segmentation was not deployed. The OMB report reflected intended state, not current state. That is not unique to this agency — the reporting mechanism creates pressure to show progress, and progress in planning is easier to document than progress in deployment. The compliance record and the network architecture were describing different things.
How the DHS framework is structured and what each pillar actually requires
The DHS zero trust framework is operationalized through the CISA Zero Trust Maturity Model, first published in 2021 and updated in 2023. It defines five pillars — identity, devices, networks, applications and workloads, and data — each with four maturity stages: traditional, initial, advanced, and optimal. OMB M-22-09 established specific capability targets per pillar with an FY2024 deadline. The framework is not a checkbox compliance document. It is a capability maturity model: each stage describes what capabilities must be operational, not what plans must exist. An agency at initial maturity for the network pillar has deployed perimeter encryption and basic segmentation. An agency at advanced maturity has implemented micro-segmentation with documented, enforced traffic flows between application workloads. The difference is operational, not documentational.
Example
The identity pillar requirements under M-22-09 are the most specific and the most frequently misunderstood. The mandate for phishing-resistant MFA does not mean any MFA. FIDO2/WebAuthn and PIV/CAC credentials satisfy the definition because they bind authentication to a specific relying party origin — a phishing site cannot capture and replay the credential because the authentication is cryptographically tied to the legitimate domain. Standard TOTP authenticator apps do not satisfy this definition. An attacker who sets up a phishing proxy can capture a TOTP code in real time and replay it before it expires. Agencies that deployed Duo or Microsoft Authenticator and reported phishing-resistant MFA compliance have a gap between their report and the M-22-09 definition.
The network pillar micro-segmentation requirement is architecturally the most demanding. Defining authorized traffic flows between application workloads requires knowing what those flows are. Most federal agencies have application inventories that describe applications but not their network dependencies. Before segmentation can be enforced, the dependency map must be built — typically through network traffic analysis across a baseline period, not through documentation review. That discovery phase takes months for complex environments and must precede any enforcement configuration. Agencies that jump to enforcement without completing discovery break applications and then roll back, which is the primary reason micro-segmentation projects stall.
What assessments of federal zero trust programs find
Assessment base: Vulnox federal agency and federal contractor compliance assessments, 2024-2025
Self-reported maturity ahead of operational capability across the network pillar
In assessments of agencies that reported initial-to-advanced network pillar progression, the most consistent finding is that micro-segmentation exists in planning artifacts and proof-of-concept environments but has not been deployed to production networks. Production data center environments retain flat network architecture with unrestricted east-west traffic. The segmentation controls visible in architecture diagrams are either not deployed or deployed only for a subset of systems that do not include the highest-value targets.
A flat internal network means that an attacker who compromises any internal endpoint — a developer workstation, a support system, a monitoring server — has unrestricted network access to systems that a segmented architecture would have isolated. The zero trust framework's protection against lateral movement does not exist in the production environment regardless of what the maturity report documents.
Identity pillar compliance that satisfies the MFA requirement but not the phishing-resistant definition
Agencies that deployed enterprise authenticator apps — Duo Push, Microsoft Authenticator, Google Prompt — report MFA compliance. The M-22-09 phishing-resistant MFA requirement specifies FIDO2/WebAuthn or PIV/CAC. In assessed agency environments, phishing-resistant authentication is enforced for access to specific high-value systems but not for general workforce authentication. The broad workforce population authenticates with push notifications, which are susceptible to push fatigue attacks and real-time phishing relay. Both attack types have been used successfully against federal agency credentials.
The phishing-resistant MFA mandate exists because credential phishing is the most common initial access vector in federal network intrusions. An agency that deploys push-based MFA for the majority of workforce authentication and reports phishing-resistant MFA compliance has created a documented record that will be reviewed in any post-incident investigation where a credential was phished.
Data pillar with classification schemas and no enforcement
Data classification policies exist in virtually every assessed federal agency. They define sensitivity tiers, label requirements, and handling rules. The gap is consistently between policy and automated enforcement: classification is applied manually, inconsistently, or only to a subset of data types. Data loss prevention tooling, where deployed, is configured to alert rather than block. Audit trails for data access events do not cover unstructured data stores — file shares, collaboration platforms, email attachments — at the granularity needed to reconstruct what data was accessed during an incident.
The data pillar at optimal maturity requires that access controls derive from data classification, not from network location. That is the core zero trust principle applied to data: verify the request against the data's classification, not against whether the requester is inside the network. Most agencies are enforcing location-based access to classified data while believing they have implemented classification-based access control.
What the maturity model does not surface on its own
The telemetry integration gap between pillar deployments
Agencies deploy identity controls, endpoint detection, and network monitoring as separate programs under separate budgets managed by separate teams. The CISA maturity model evaluates each pillar independently. What it does not evaluate is whether the telemetry from each pillar feeds a common policy engine that can make access decisions based on real-time signals across all five pillars. An agency can reach advanced maturity in identity, devices, and networks independently while having no integration between those streams. The zero trust architecture that advanced maturity is supposed to represent — where access decisions factor in identity, device health, and network behavior simultaneously — does not exist without that integration.
Legacy system accommodation and what it costs the architecture
Federal agencies accommodate legacy systems that cannot satisfy zero trust requirements through network exceptions, isolated segments, or compensating controls. Those accommodations are reasonable. What they create is a documented list of systems where the zero trust architecture does not apply. Attackers who enumerate federal network infrastructure — a well-documented reconnaissance activity — look for those legacy segments because they represent the boundary of the zero trust perimeter. The exceptions are necessary. They are also a map to the gaps.
Service accounts and non-human identity
The identity pillar requirements focus on workforce authentication. Service accounts — automated processes, application integrations, monitoring systems — authenticate using credentials that are often long-lived, broadly privileged, and not subject to the same lifecycle management as user accounts. In zero trust terms, non-human identities are a separate and underaddressed attack surface. Compromising a service account that has been granted broad application access bypasses the phishing-resistant MFA requirement entirely because service accounts do not authenticate with MFA.
Contractor system access to agency environments
Federal agency networks are accessed by contractor workforces using contractor-managed devices. The zero trust architecture applies agency-side controls to agency systems, but the device posture of contractor endpoints is governed by contractor device management programs that may not satisfy the device pillar requirements. An agency employee authenticating from a compliant, agency-managed device satisfies the device pillar requirement. A contractor employee authenticating from a personal laptop with no endpoint detection satisfies the identity requirement if they have the right credentials and fails the device requirement that zero trust is supposed to enforce.
Enterprise-wide architecture versus pillar-by-pillar implementation
Pillar-by-pillar sequential implementation
Agencies advance one pillar at a time, typically starting with identity because it has the clearest procurement path and the most established vendor solutions. Network and data pillars follow. Each pillar is managed by a different team with different tools and different reporting chains. Progress per pillar is measurable and reportable against the maturity model. Integration between pillars is deferred.
Most federal agencies are on this path by default because it aligns with how federal IT programs are funded and governed. The risk is that advanced maturity in individual pillars without telemetry integration does not produce the adaptive access control capability that zero trust architecture requires. An agency can reach advanced identity and initial network while having no mechanism to deny access to a high-privilege user whose device has been compromised, because the device signal never reaches the identity policy engine.
Architecture-first integrated implementation
Agencies define the target policy engine and telemetry integration architecture first, then deploy pillar capabilities to feed that architecture. Identity, device, and network signals are integrated from the beginning of deployment rather than after individual pillar maturity is reached. Progress is harder to report against the pillar-based maturity model. The architecture produces more operational capability earlier in the program.
This approach is harder to fund because it requires cross-bureau coordination and a shared infrastructure investment before individual pillar capabilities are visible. It is also harder to report on because the maturity model measures pillar capabilities, not integration. Agencies that have taken this path tend to be newer organizations or those that have undergone significant infrastructure modernization. They are a minority.
Where the DHS zero trust program is heading
By end of 2026, OMB will revise the zero trust progress reporting requirements to include verified capability demonstrations rather than self-attestation for at least the identity and network pillars, following documented discrepancies between agency self-reports and CISA assessment findings.
CISA conducts assessments of agency zero trust implementations under its CISA Cybersecurity Advisory services. Those assessments have found consistent gaps between self-reported maturity and operational control state. The self-reporting mechanism that M-22-09 established was designed for a first-generation compliance cycle. As the program matures and the gap between reported and actual state becomes more apparent, the oversight mechanism will tighten. The pattern follows CMMC: self-attestation preceded third-party assessment requirements as the program matured.
Confidence: mediumNo OMB revision to M-22-09 reporting requirements requiring verified capability evidence by end of 2026Service account and non-human identity compromise will be identified as the primary initial access vector in at least one publicly attributed federal agency breach in 2026, directly exploiting the identity pillar gap between workforce MFA requirements and unmanaged service account credentials.
The phishing-resistant MFA mandate has raised the cost of credential phishing for human workforce accounts at agencies that have implemented it correctly. Attackers follow the path of least resistance. Service accounts — which cannot satisfy MFA requirements, are often over-privileged, and have credentials that are rarely rotated — are the logical alternative target. The technical conditions for this shift are present. An attributed breach that makes the service account vector explicit will drive the identity pillar requirements to explicitly address non-human identity.
Confidence: highNo publicly attributed federal agency breach citing service account compromise as primary initial access vector by end of 2026
What agencies say about zero trust implementation — and what is underneath it
We have deployed zero trust tools across all five pillars. Our architecture is zero trust.
Root cause:Deploying tools that address each pillar is not the same as implementing zero trust architecture. The architecture requires that access decisions are made dynamically based on real-time signals from identity, device, and network sources evaluated together. An agency with separate identity governance, separate endpoint detection, and separate network monitoring that do not share telemetry has the components of zero trust without the architecture. The test is not whether the tools exist — it is whether an access request from a compromised device is denied because the device signal reached the policy engine. In most federal environments, it is not.
We met the OMB M-22-09 deadline. Zero trust compliance is complete.
Root cause:M-22-09 established specific maturity goals for FY2024. Meeting those goals means reaching the defined capability threshold for that deadline — which for most pillars is initial to advanced maturity, not optimal. The mandate was for a maturity stage, not for a completed program. Zero trust is a continuous architecture, not a destination. Agencies that treated the FY2024 deadline as a completion milestone have stopped advancing while the threat environment has not.
Our contractors are responsible for their own device security. That is outside our zero trust boundary.
Root cause:Contractor devices that access agency systems are within the zero trust risk surface regardless of who manages them. The zero trust architecture is designed to evaluate device posture at the point of access, not to exclude devices based on who owns them. An agency that enforces device posture checks for agency-managed endpoints and exempts contractor devices has defined a boundary that attackers can cross by targeting contractor access paths. This is not a contractor management failure — it is an architecture decision that creates a documented bypass.
What the maturity model gets right and what it hides
The CISA Zero Trust Maturity Model is a good framework for organizing capability investments and communicating progress to non-technical stakeholders. It is a poor framework for measuring actual security improvement, because it measures capability presence rather than capability integration. An agency at advanced maturity in identity and initial maturity in networks has done significant work. What it has not necessarily done is close the lateral movement risk that zero trust architecture is supposed to address, because lateral movement protection requires the network pillar micro-segmentation that is the hardest part of the program. The maturity model lets agencies show substantial progress while the most operationally significant capability — the one that actually changes the outcome when an attacker gets inside — remains incomplete. The reporting looks good. The dwell time does not change.
Counterargument
The counterargument is that any structured maturity model produces this dynamic, and the alternative — requiring full architecture integration before agencies can report progress — would produce no reportable progress for years. Incremental milestones with imperfect metrics are better than no milestones. That is true. The problem is not the maturity model. The problem is treating the maturity model report as a security posture assessment rather than a capability inventory. They are not the same thing.
One thing to do this week
Map your service accounts — every automated process, application integration, and monitoring credential in your environment — against your identity pillar maturity claim. Check which ones have credentials that have not been rotated in the past 90 days. Check which ones have privileges that exceed what their function requires. Check which ones are excluded from your phishing-resistant MFA reporting because they cannot satisfy that requirement. That list is your identity pillar gap. It is almost certainly not in your OMB progress report.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisUS federal cybersecurity frameworks: the complete guide to all 37 mandates
DHS zero trust framework requirementsNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkCISA Risk and Vulnerability Assessments
CISA vulnerability assessmentsDigital Footprint and Monitoring - ThreatNG
digital footprint monitoring
Frequently Asked Questions
What is the DHS zero trust framework and how does it differ from general zero trust guidance?
The DHS zero trust framework, formalized through CISA's Zero Trust Maturity Model and mandated via OMB M-22-09, is the specific federal implementation roadmap for the zero trust architecture principles in EO 14028. It defines five pillars — identity, devices, networks, applications and workloads, and data — and four maturity stages: traditional, initial, advanced, and optimal. Where general zero trust guidance is architectural and vendor-neutral, the DHS framework is operationally specific: it names required capabilities per pillar, sets deadlines tied to fiscal year appropriations, and designates CISA as the coordinating authority. Agencies are not just adopting a security philosophy — they are progressing through a defined maturity model against a compliance deadline.
What did OMB M-22-09 require federal agencies to achieve and by when?
OMB M-22-09, issued January 2022, required federal agencies to meet specific zero trust architecture goals by the end of fiscal year 2024. The identity pillar requirement included phishing-resistant MFA for all federal staff — defined as FIDO2/WebAuthn hardware keys or PIV/CAC credentials, not SMS or authenticator apps. The network pillar required encrypted DNS and HTTPS traffic and progress toward network segmentation. The application pillar required treating applications as internet-accessible regardless of network location. These were not aspirational targets — they were baseline requirements with agency self-reporting obligations to OMB.
What is the CISA Zero Trust Maturity Model and how do agencies use it?
The CISA Zero Trust Maturity Model defines four stages for each of the five pillars: traditional, initial, advanced, and optimal. Traditional represents perimeter-based defenses with manual controls. Initial introduces conditional access and basic automation. Advanced integrates continuous diagnostics, automated enforcement, and real-time analytics. Optimal achieves full automation, adaptive access policies, and enterprise-wide visibility. Agencies use the model to self-assess their current stage per pillar, identify the specific capability gaps between their current stage and the next, and build roadmaps tied to budget cycles. The model is published by CISA and is the primary evaluation instrument for OMB reporting.
Where do federal agencies most commonly stall in zero trust implementation?
The most consistent stall point is the gap between initial and advanced maturity. Agencies reach initial by enabling conditional access policies and deploying MFA, which are straightforward procurement decisions. Advancing to the next stage requires integrating telemetry across identity, device, and network sources into a unified policy engine, implementing automated enforcement that responds to real-time risk signals, and completing micro-segmentation that limits lateral movement within agency networks. These are architectural changes that touch legacy systems, require cross-bureau coordination, and cannot be completed by deploying a single product. They stall because they are operational transformation projects, not compliance checkboxes.
What does phishing-resistant MFA mean under the DHS zero trust framework and why does it matter?
Phishing-resistant MFA under M-22-09 means authentication methods that cannot be intercepted and replayed by an attacker in real time. FIDO2/WebAuthn hardware security keys and PIV/CAC smart cards satisfy this definition because authentication is bound to a specific origin and cannot be captured by a phishing proxy. SMS one-time codes, voice call verification, and standard TOTP authenticator apps do not satisfy the definition because all three can be intercepted through real-time phishing relay attacks. Agencies that deployed authenticator apps to satisfy the MFA requirement and reported compliance have a documented gap between what they reported and what M-22-09 requires.
What does micro-segmentation require in a federal network context and why is it hard to implement?
Micro-segmentation requires dividing a network into isolated zones where traffic between zones is explicitly authorized and monitored, rather than implicitly trusted because both systems are inside the perimeter. In a federal context, this means defining authorized communication paths between application workloads, enforcing those paths through host-based or network-based controls, and having visibility into east-west traffic — traffic between internal systems — not just north-south traffic entering and leaving the perimeter. The implementation challenge is that legacy federal systems were not designed with micro-segmentation in mind. Applications have undocumented dependencies on network adjacency. Mapping those dependencies, defining the authorized paths, and enforcing segmentation without breaking operational systems requires a level of application inventory that most agencies have not completed.
How does the data pillar of the DHS zero trust framework work and what does it require?
The data pillar requires agencies to classify, label, and apply protections to data based on sensitivity, then enforce access controls derived from that classification rather than from network location. At initial maturity, this means having a data classification schema and manually labeling sensitive data categories. At advanced maturity, it means automated classification tools, data loss prevention enforcement, and access policies that restrict what authenticated users can do with data based on classification. At optimal maturity, it means automated discovery and classification of new data, continuous enforcement of data access policies, and audit trails sufficient to reconstruct data access events. Most agencies are at traditional or initial for the data pillar — classification schemas exist on paper, automated enforcement does not.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.