In May 2021, Executive Order 14028 mandated a federal shift to Zero Trust Architecture (ZTA). In September 2022, OMB M-22-09 gave agencies a deadline: reach specific ZTA maturity targets by the end of fiscal year 2024. We are past that deadline. Most agencies have not met it.
I have spent the last several years implementing Zero Trust inside one of the federal government’s most complex identity environments – the Department of Education’s Federal Student Aid ICAM system – which serves over 186 million users. What I have learned is that the gap between federal ZTA policy and federal ZTA reality is not a technology problem. It is a legacy identity problem that no framework adequately addresses.
The framework assumes you’re starting with clean identity infrastructure. Almost no federal agency is.
What the NIST Playbook Doesn’t Tell You
NIST SP 800-207 is a solid conceptual framework. It correctly identifies the five pillars – identity, device, network, application and data – and the principle that no implicit trust should be granted based on network location. What it does not tell you is what happens when your identity pillar is built on legacy systems with entrenched access patterns that predate modern IAM by a decade or more.
In a federal ICAM environment, you are not dealing with clean directory structures. You are dealing with role assignments that accumulated over years of organizational change, privileged access that was granted for a project and never revoked, and federated identity relationships with external systems built before modern federation standards existed. Migrating this environment to AWS GovCloud does not reset any of that complexity. It moves it to the cloud, and then you have to untangle it there, under active ATO requirements, with zero tolerance for access disruption to mission-critical systems.
This is the implementation gap that rarely surfaces in ZTA discussions: the difference between designing a Zero Trust architecture and retrofitting Zero Trust principles onto a living federal system that cannot go offline.
Three Specific Places Where Agencies Get Stuck
- Treating ZTA as a perimeter replacement rather than an identity transformation. Most agencies begin their Zero Trust journey by focusing on network segmentation and micro-segmentation. These are necessary but insufficient. The harder, slower work is identity governance – ensuring that every access decision is based on verified, current, least-privilege identity claims. In legacy federal environments, this requires rearchitecting how roles are defined, how access is provisioned, and how continuous verification is enforced without creating operational friction that system owners will route around.
- Underestimating the POA&M burden during migration. When you migrate a federal system to GovCloud and simultaneously advance its ZTA maturity, you are generating security findings faster than most teams can remediate them. The NIST CSF scorecard does not pause during migration. ATO requirements do not pause. The POA&M backlog can become existential if remediation is not structured correctly from the start: with clear ownership, realistic timelines and executive visibility into risk exposure, not just finding counts.
- Failing to govern the data pillar alongside identity. OMB M-22-09 explicitly includes data as a ZTA pillar, but in practice it is the most underdeveloped. Federal agencies handling sensitive PII – student financial data, tax records, benefits information – need DLP controls integrated with their ZTA identity decisions. Access to sensitive data should be continuously evaluated, not just granted at login. Most agencies have not connected their DLP posture to their ZTA roadmap. These workstreams remain separate when they should be unified.
What Actually Works
The agencies making real ZTA progress share one characteristic: they treat authorization artifacts – System Security Plans (SSP), continuous monitoring reports, POA&Ms – not as compliance overhead but as the actual management tool for ZTA maturity. When the SSP reflects real system behavior and real control implementation, it becomes a living instrument for identifying where implicit trust still exists. When it is written once for ATO and never updated, it is useless for ZTA governance.
The second factor that drives progress is cross-functional ownership. ZTA cannot be owned solely by the ISSO or the GRC team. It requires active partnership between security, engineering and architecture – with clear escalation paths to the CISO when remediation timelines conflict with system availability requirements. The agencies that treat ZTA as a security-only problem stall. The ones that treat it as an enterprise architecture challenge make progress.
The Honest Assessment
Federal Zero Trust is behind schedule not because agencies lack commitment, but because the implementation complexity of legacy identity environments was systematically underestimated in the policy frameworks that set the deadlines. OMB M-22-09 was ambitious and necessary. The on-the-ground reality of executing it inside a system serving 186 million users, with continuous ATO obligations and zero tolerance for access disruption, is significantly harder than the framework suggests.
Practitioners who have done this work on a scale need to be more vocal about what the implementation actually looks like – not to undermine the ZTA mandate, but to help the next wave of agencies approach it with realistic preparation. The gaps described here are solvable. They just require honesty about where the frameworks end and the hard work begins.
About the Author: Charu Arya, CISM, CISA, is a Senior Cybersecurity GRC Lead with 14+ years of progressive experience in federal cybersecurity compliance, identity management, and risk governance. She holds an active Public Trust Security Clearance and AWS Security Specialty certification and has led GRC programs for federal systems at the Department of Education supporting over 186 million users. Her expertise spans NIST 800-53, FedRAMP, FISMA, Zero Trust Architecture, and ICAM compliance. She is a member of ISACA and (ISC)².
