Zero Trust Executive Order Compliance Roadmap for Federal Agencies

The SolarWinds breach in 2020 exposed something federal cybersecurity had known in theory but never really had to confront in practice: perimeter defense is a fiction once an attacker gets a foothold inside the network. That single incident, which compromised systems at the Justice Department, the Department of Defense, and other agencies through a poisoned software update, is why the federal government now has a five-pillar, multi-year Zero Trust mandate on the books. This piece walks through what that mandate actually asks agencies to do, pillar by pillar, using CISA's own maturity model as the map.

What the mandate actually requires: reading M-22-09 and the CISA maturity model together

Executive Order 14028, signed May 12, 2021, was the direct policy response to SolarWinds. It told civilian agencies to build Zero Trust adoption plans. An executive order sets direction rather than technical specifications, so agencies needed something with teeth and deadlines. That came eight months later.

OMB M-22-09, issued January 26, 2022, is the document that turned the executive order into homework with a due date. Agencies had 60 days to submit implementation plans, and they had until the end of fiscal year 2024 to hit a specific set of technical benchmarks. Four things sit at the center of it: strong enterprise identity with multi-factor authentication, encryption of network traffic wherever practical, a foundation for automating access rules, and a mandate to treat every application as if it were sitting exposed on the open internet, because functionally, it is.

Underneath M-22-09 sits NIST SP 800-207, published in 2020, which is the technical bedrock for all of this. Its core move: stop trusting things because of where they sit on the network, and start trusting them based on verified identity. That single sentence rewired how federal IT is supposed to think about access.

CISA layered its Zero Trust Maturity Model 2.0 on top in 2023, giving agencies a practical ladder to climb: five pillars (identity, devices, networks, applications, data) plus three cross-cutting capabilities, and four maturity stages, Traditional, Initial, Advanced, Optimal, that mark where an agency sits on the climb. Version 2.0 added a fourth maturity stage — Optimal — to the original three, sharpened the guidance, and lined it up more tightly with M-22-09's requirements. M-22-09 sets the floor, the minimum an agency has to clear; ZTMM 2.0 works as the staircase above that floor, showing what continued progress looks like.

The September 30, 2024 deadline passed. Nobody declared victory. OMB followed up with M-24-14 in July 2024 and M-25-04 in January 2025, both making clear that Zero Trust maturity is now a permanent line item in agency budgeting and planning, not a box checked once and forgotten. And when the Trump administration issued its own cybersecurity executive order in June 2025, it kept Zero Trust architecture and advanced threat detection as explicit priorities. Whatever else changed in tone or emphasis, the core direction survived a change in administration intact, which tells you something about how settled the underlying threat model has become.

Identity: the pillar agencies tackled first and what "done" actually looks like

M-22-09 requires every federal employee, contractor, and partner to operate under an enterprise-managed identity, protected by phishing-resistant multi-factor authentication. Identity comes first in the sequence for a structural reason: NIST 800-207's whole premise is that trust decisions move from "where are you on the network" to "who, provably, are you." Nothing else in the five-pillar model works until that question has a reliable answer.

Not all MFA earns the "phishing-resistant" label, and the distinction matters more than agencies initially treated it. A one-time code sent by text message can be intercepted or phished; a FIDO2/WebAuthn credential, where a private key lives inside a hardware enclave like a YubiKey or a device's TPM chip and never leaves that hardware, resists phishing by design, because there's no code for an attacker to trick someone into typing into a fake login page. NIST SP 800-63-4, finalized in 2025, formalizes this by requiring phishing-resistant MFA for the highest assurance tier, Authenticator Assurance Level 3.

Here's a wrinkle worth tracking: the June 2025 Trump executive order actually deleted the specific section of EO 14028 that directed phishing-resistant authentication. That sounds like a rollback, though M-22-09 itself still requires it independent of that executive order language. Agencies reading the EO change as license to loosen MFA standards would be making a mistake; the technical obligation stayed put even after its original legal anchor moved.

The maturity curve here runs from Traditional (passwords and basic MFA) through Initial (an enterprise identity provider, partial phishing-resistant rollout) to Advanced (continuous, risk-based authentication) and finally Optimal, where identity assurance is automated and evaluated in real time across every user and system. CISA's January 2025 report to Congress noted meaningful headway on identity, which is encouraging but shouldn't be mistaken for a finish line; progress on this pillar is real, but it doesn't mark the end of the climb. Agencies still climbing should start by auditing every identity provider in use and killing off shadow or local accounts that never got folded into the enterprise system, then push hardware security keys to the highest-value roles first before expanding outward, and finally wire identity signals into ongoing authorization decisions rather than treating a successful login as the end of the conversation.

Devices: building the complete inventory M-22-09 demands before anything else can be enforced

M-22-09 asks for something that sounds almost embarrassingly basic: a complete inventory of every device the government operates or has authorized, plus the ability to detect and respond to incidents on those devices. Basic, yes, but at federal scale, brutally hard.

The logic underneath it, in ZTMM terms, is that a device with unverified status is functionally an unknown quantity, and an unknown cannot be trusted, monitored, or granted access safely. That reframes inventory work from paperwork into an actual security control, which is a mental shift some agencies took longer to make than others.

There's a real number attached to this pillar: as of the end of fiscal year 2024, 92% of federal endpoints carried coverage from at least one endpoint detection and response tool, per the 2024 Report on the Cybersecurity Posture of the United States. That's a solid floor. But it's worth sitting with what the remaining gap actually represents, since coverage isn't spread evenly across agency types, and legacy or air-gapped systems, the hardest devices to secure in the first place, are disproportionately the ones sitting in that uncovered slice. The easy 92% got covered first precisely because it was easy; the last stretch is where the actual risk concentrates.

Maturing this pillar means building continuous asset discovery rather than relying on point-in-time inventories that go stale the moment someone plugs in a new laptop, and treating device health, patch level, EDR status, disk encryption, as a live condition for granting access rather than a fact reported after the fact. Contractor laptops and shared workstations that are authorized but not fully managed should sit in restricted network zones until they meet posture standards. The Advanced and Optimal maturity stages both require this posture check to run automatically, in real time, and to be evaluated alongside identity at the moment of every access request, not as a separate report generated once a quarter.

Networks: why encrypting traffic and micro-segmenting are the hardest operational lifts in the framework

M-22-09 wants all DNS requests and HTTP traffic encrypted, turning the federal network into hostile territory for anyone trying to eavesdrop. CISA's January 2025 report to Congress didn't soften this one: networks, alongside data, were named directly as the two pillars where full operationalization at scale had stalled.

Three structural reasons explain why. Federal networks were built over decades under the old assumption that anything inside the perimeter could be implicitly trusted, so encryption has to be layered onto architecture that was never designed to expect it. Scale compounds the problem: encrypting DNS and HTTP traffic across 24 CFO Act agencies and their many sub-components isn't a settings change, it's an operational campaign involving hundreds of distinct environments. And micro-segmentation, breaking a flat network into granular, policy-controlled zones, requires mapping every single traffic flow before anyone can safely enforce a boundary around it. You cannot fence off what you haven't first walked the borders of.

This is NIST 800-207's core principle showing up as an engineering headache rather than a policy statement: if network location stops being a basis for trust, the network itself stops functioning as a trust boundary, and that's an architectural overhaul, not a firewall rule update. Agencies making real progress here started with DNS-over-HTTPS and encrypted DNS, since those are well-supported and satisfy a specific line item in M-22-09 without requiring a total network redesign. From there, the sequence matters: map east-west traffic flows before attempting segmentation, pilot micro-segmentation on one bounded environment, a single application stack or a single facility, before trying to scale policy enforcement agency-wide. CISA's own Protective DNS service gives agencies a foundational layer here too, supporting encrypted DNS while feeding CISA shared visibility, which is itself one of the model's cross-cutting capabilities. Optimal maturity on this pillar means every bit of traffic is encrypted and access decisions run off identity and device posture rather than VLAN membership or IP range, which for most agencies is still a distant target rather than a near-term one.

Applications and workloads: treating every application as internet-accessible and what that forces agencies to change

The mandate here is almost provocatively blunt: treat every application as if it's sitting exposed on the internet. That erases the old comfort blanket of the "internal" application, the one nobody hardened properly because it lived safely behind the firewall and only trusted users could reach it anyway.

In practice this means access controlled by identity and device posture rather than firewall rules or VPN presence, authentication enforced at the application layer instead of the network edge, and every application built to check who's asking and how healthy their device is, regardless of where the request physically originates.

There's a concrete, trackable milestone tied to this pillar: as of the start of the fourth quarter of fiscal year 2024, 51 agencies had onboarded with CISA's Vulnerability Disclosure Program platform. That number matters beyond being a checkbox, because onboarding with a VDP is an admission, in operational terms, that an agency's application surface is exposed and needs active, ongoing hardening rather than passive faith in the perimeter. It's the application pillar's principle made literal.

The catch is legacy software. A lot of federal applications were built before API-level authentication and modern authorization models existed as standard practice, and retrofitting them is slow, expensive, and often requires the original vendor to get involved, assuming that vendor is still around. Agencies working through this pillar are best served by inventorying every application by its access model, sorting which ones still lean on network location for trust versus which already enforce authentication at the app layer, then prioritizing high-value and high-impact systems first, which is exactly what M-24-14 directed. Onboarding with CISA's VDP platform, for agencies that haven't, functions as both a compliance milestone and a forcing mechanism that pushes hardening work that might otherwise sit on a backlog forever. Piloting a zero trust access proxy for internal applications is a reasonable middle step, buying time before every legacy app needs a full rewrite.

Data: the pillar that requires classification before it can be protected, and why that sequencing tripped agencies up

CISA's January 2025 report named data as the other pillar, alongside networks, that stalled at scale. The reason isn't a lack of effort. It's sequencing, and it's worth sitting with why, because the logic explains a lot of the frustration agencies have voiced about this pillar specifically.

You cannot enforce access control around data you haven't classified, and you cannot classify data you haven't located, and locating and classifying data at any real scale depends on already having solid identity and device inventories in place, since those tell you who's touching what and from where. Data sits at the end of a dependency chain, which means agencies that treated the five pillars as parallel tracks rather than a partially sequential one ran into trouble here first.

Maturity on this pillar means data categorized by sensitivity, at minimum against FISMA categories, ideally through some ongoing classification process rather than a one-time sweep. It means access governed by policy that weighs identity, device posture, and data sensitivity together, with old-fashioned folder permissions or file-share ACLs long overdue for retirement. The 2024 Report on the Cybersecurity Posture of the United States did flag one genuine bright spot heading into the FY 2024 deadline: agencies made measurable progress encrypting data both at rest and in transit, which counts as real forward motion even while the broader pillar lagged.

Legacy systems hit hardest here. Mainframes and older platforms were built on the assumption that being on the network was permission enough to touch the data, and CISA's 2025 report to Congress is direct about the consequence: continuous authorization cannot simply be bolted onto systems that never had API-level access control to begin with. Layer onto that a budget reality that isn't a motivation problem so much as an arithmetic one: agencies spend the large majority of their IT budgets keeping existing systems running, which leaves comparatively little left over for modernization work. So what's the actual move here? Start with discovery and classification on the highest-value data first rather than trying to classify an entire enterprise at once. Put data loss prevention controls around the most sensitive categories before attempting to solve classification everywhere simultaneously. Where a legacy system genuinely can't support modern access control yet, compensating controls, tighter network segmentation, heavier monitoring, buy time while modernization gets planned and funded. And none of this works without the cross-cutting Visibility and Analytics capability, since policy enforcement is impossible without logs showing who's accessing what in the first place.

The three cross-cutting capabilities that tie all five pillars together operationally

ZTMM 2.0 doesn't stop at five pillars. It names three capabilities that run underneath and across all of them: Visibility and Analytics, Automation and Orchestration, and Governance. Skip these and the five pillars turn into five disconnected projects instead of one coherent architecture.

Visibility and Analytics is the precondition for everything else on this list. Least-privilege enforcement and anomaly detection both depend on telemetry pulled from identity events, device posture, network flows, application access logs, and data movement, all stitched together rather than sitting in five separate dashboards nobody cross-references. The practical starting point most agencies land on is centralized logging paired with SIEM integration, pulling signals from identity providers, EDR tools, and network sensors into one place before attempting anything as ambitious as automated response.

Automation and Orchestration is where M-22-09's language gets specific: it names "building a foundation to automate security access rules" directly as a technical requirement, not a nice-to-have. That's the mechanism that turns a pile of telemetry into actual enforcement rather than a very expensive log file nobody reads until after an incident. Governance, the third leg, is what keeps the other two honest over time: the policies, standards, and oversight that make sure automated rules stay current and identity requirements don't quietly drift as systems change hands, staff turn over, and new applications get added to the environment.

None of the five pillars function as a closed loop without these three running underneath them, which is probably the clearest way to understand where most agencies still sit relative to the FY 2024 deadline that's already come and gone. The deadline passed; the climb up CISA's maturity model did not stop when it did. Agencies clearly started, moving fastest on the pillar that was easiest to move. The open question now is whether the harder pillars, networks and data, get the same sustained attention that identity got first, or whether they keep sitting exactly where CISA's own report to Congress said they were sitting in January 2025.