Key Takeaways
- Federal Zero Trust programs must align with applicable OMB requirements, CISA guidance, and agency-specific timelines.
- Strong identity controls, least privilege, device posture, and network segmentation help limit unauthorized access.
- Legacy systems, hybrid environments, and operational technology require phased implementation and compensating controls.
- Asset inventories, documented data flows, and measurable outcomes help agencies prioritize security improvements.
- Security operations strengthen Zero Trust through continuous monitoring, threat detection, and timely incident response.
- Fidelis Elevate and CloudPassage Halo support visibility, threat detection, and cloud security within a broader agency-led architecture.
September 30, 2024 was the date agencies subject to OMB M-22-09 had to meet its goals. It came and went, and nobody stood up to say the work was done. The Defense Department has longer: target-level Zero Trust by the end of fiscal 2027, a year that started on October 1.
Where does that leave a security lead right now? With a payroll system older than the CISO, for one. With a contractor whose session has to die at 2 a.m., and a SOC that struggles to separate a stolen credential from a tired employee. Those are the actual problems behind Zero Trust for federal agencies in 2026, and they set the agenda here: what current guidance demands, where projects get stuck, how to order the work, and where we fit in.
What Zero Trust Means for Federal Agencies
Start with NIST SP 800-207, which boils the idea down to one rule. Network position earns no trust, and ownership of the device earns none either. Each request to a resource is authenticated and authorized on its own merits.
People use three words for what are really three different things. Zero Trust is the philosophy. A Zero Trust architecture (ZTA) is the thing you build, with a policy engine and policy administrator making the calls and enforcement points standing in front of resources. The strategy is what you can’t purchase: which systems first, who owns each piece, what “done” looks like.
The network perimeter stopped working in government well before anyone admitted it. Contractors bring their own laptops. Workloads live in more than one cloud. Partner agencies pull shared datasets. A stolen password, meanwhile, looks to a firewall exactly like a legitimate employee.
Federal Zero Trust Requirements and Guidance
Some of this binds you and some of it only suggests. Planning documents routinely lump the two together, so separate them early.
Executive Order 14028 and OMB M-22-09 are the binding pair for the agencies they cover. The memo arranges its goals under five pillars (identity, devices, networks, applications and workloads, data) and doesn’t stay abstract. It asks for enterprise-managed identities protected by phishing-resistant multifactor authentication, a complete device inventory paired with endpoint detection and response, and encrypted DNS and HTTP traffic. M-22-09 remains the baseline, and the 2026 documents below add to it.
On May 22, OMB issued M-26-14, rescinding the old logging memo (M-21-31) and replacing it with a risk-based approach that covers IoT and OT and links future logging guidance to the Visibility and Analytics capability in CISA’s maturity model. M-22-09’s data pillar pointed to M-21-31 for logging, so M-26-14 now fills that role. CISA followed on August 20 with its Logging Reference Architecture, which started a 90-day clock. Agency logging plans go to OMB and CISA by November 18, and the first maturity level is due December 18.
Two other documents matter for architecture. CISA’s June 24 guidance on Secure Access Service Edge (SASE) under Trusted Internet Connections 3.0 is aimed at agencies leaving older managed gateway connectivity behind, and telemetry sharing with CISA carries on. Earlier, on April 29, CISA and federal partners released Zero Trust guidance for operational technology, which acknowledges that IT-style controls can’t be applied to OT wholesale.
The rest is advisory. NIST SP 800-207A addresses cloud-native, multi-cloud setups. CISA’s Zero Trust Maturity Model defines four stages (traditional, initial, advanced, optimal) across the pillars, with visibility and analytics, automation and orchestration, and governance running underneath. DoD follows its own strategy and calendar, and national security systems have separate direction altogether, so keep those timelines off the civilian slide.
A caution worth repeating to leadership: satisfying a memo is regulatory compliance and nothing more. It says very little about whether a particular system holds up when an administrator account gets compromised.
- Dynamic threat monitoring
- Proactive Cyber Defense
- Zero Trust in Action
Core Zero Trust Principles for Mission-Critical Systems
Identity management and least privilege access
Identity goes first, by a wide margin. Federal staff anchor on PIV credentials, yet service accounts and API keys frequently outnumber people and get much less attention.
Least privilege access usually dies at the privileged accounts. Standing admin rights, shared logins, vendor accounts with root. They hang around because taking them away is annoying. Privileged access management works when it means separate admin identities, elevation that times out, and recorded sessions on anything sensitive.
Device posture and user context
One user, two laptops, one patched and managed, one neither. Treating them alike would be silly. Device posture (patch level, whether endpoint tooling is running, configuration baseline) should sit in the decision next to role, location, and data sensitivity. Fresh signals are the catch. An out-of-date inventory breaks this layer without a sound.
Network segmentation and data flows
M-22-09 puts it bluntly: reaching an application from the internal network can’t count as safer than reaching it from the internet, so users authenticate to applications, not networks. Segmentation follows from that idea. It limits an intruder’s reach after entry, but only when it follows documented data flows: which applications talk to which databases, along what paths, and why. Segments sketched from assumptions break something important, and the fix is usually a broad exception that undoes the work. Mapping flows has a side benefit, since it shows where sensitive data really travels, and that is seldom where the diagram claims.
Continuous verification and continuous authentication
Login is a starting point. After that, verification shows up as step-up authentication before sensitive actions, sessions cut when device posture changes, and tighter limits when behavior turns strange. It does not mean badgering users with prompts all day.
Where Federal Zero Trust Implementation Gets Difficult
Legacy systems cause the most grief. A lot of mission applications run older protocols or depend on hard-coded service accounts, so they can’t present modern identity assertions. End-of-life systems make it worse, because nothing is patched and there’s nothing to fix when a flaw turns up. M-22-09 even admits that mainframes and connected devices may have no compatible EDR tool, which leaves them to other controls. Typical coping moves: a gateway or proxy up front, tight segmentation, extra monitoring, and a retirement date that a named person owns. Privileged access management can help here, but M-22-09 draws a line: PAM-issued temporary credentials are no substitute for MFA, though the memo calls them useful for high-privilege systems that can’t be modernized soon.
Hybrid environments bring their own mess. On-premises systems and each cloud service provider come with separate identity stores, log formats, and policy tools, and a single policy across all of them takes real effort to hold together. SP 800-207A exists largely because of that.
OT and IoT add uptime requirements, poor visibility, and devices that can’t host an agent. April’s guidance admits as much, and M-26-14 now pulls those assets into logging scope.
Privileged and third-party access moves slowly. Database administrators, integrators, and partner agencies connect through arrangements that predate the program, with break-glass procedures written into runbooks nobody wants to open.
Existing tools deserve more attention than they get. Agencies hold overlapping products bought for earlier mandates, and wiring their signals into one decision process is often harder than buying a new product.
Finally, operations. Cutting access to a system behind a live mission is a risk of its own, and authorization and change-control cycles slow everything down.
Building a Federal Zero Trust Strategy
Order beats ambition. Begin by naming an owner for every pillar. The M-22-09 implementation lead coordinates, but identity, endpoint, network, application, and data work each need someone who can actually change the tools.
Next comes the inventory: identities including service accounts, devices, applications, data flows. Rank systems by mission impact and exposure. The new logging approach assumes you know your assets, so the effort pays off twice.
Then fix identity and privileged access, because nearly everything after it leans on them. Pick a handful of high-value systems whose flows you understand and segment around them, so any failure stays contained. Run policy in monitor mode before enforcing it, fix the legitimate paths it would have broken, and only then switch it on.
Measure outcomes, not purchases: applications behind enterprise authentication, privileged accounts under controlled elevation, segmented systems with documented flows, and time from detection to containment. Tie those to maturity model stages so the year-over-year picture means something.
Using Security Operations to Support Zero Trust
A ZTA is only as good as its inputs. NIST SP 800-207 names them: continuous diagnostics data, threat intelligence, system and network activity logs, SIEM output. If the SOC can’t see much, the policy engine is deciding blind.
Assume breach makes this concrete. Credentials get stolen, insider threats exist, and so detection has to catch misuse by accounts that are technically allowed in. Access at odd hours. Bulk reads of sensitive data. Movement between segments. Baselines of user behavior and user activity are what make those deviations show up.
M-26-14 organizes logging around the same aim. Its first objective is continuous monitoring: real-time ingestion, anomaly detection, SOC-driven response. Having the logs is no longer the goal, using them is, and that’s why the logging plan matters even to teams who see Zero Trust as strictly an access project.
Detection reduces harm only when it sets something off. Pre-approved responses (revoke a session, quarantine a device, disable an account) let analysts contain a security incident without a ticket queue in the middle, and that is what shortens dwell time. The analyst acts on the signal rather than waiting on a handoff.
How Federal Agencies Can Strengthen Zero Trust Implementation
Before adding a capability, ask whether it works with the identity provider, CDM tooling, and SIEM already in place, or whether it becomes one more silo. Ask whether it covers legacy, cloud, and OT assets or only modern endpoints, and whether it can observe and report before it starts enforcing. Ask what records it produces for authorizing officials and assessors. And ask who will tune its policies a year from now, and whether that staffing is realistic.
Whatever you add joins the existing security posture instead of replacing it. Gaps surface faster when the program is described as decisions (who gets access, from which devices, to which data, under what conditions) and not as a product list.
Where Fidelis Can Support a Federal Zero Trust Strategy
Fidelis Elevate®, our Active XDR platform, aligns with NIST SP 800-207 and helps move infrastructure toward Zero Trust principles. A few of its capabilities map onto the problems above.
For visibility, Fidelis Elevate® maps cyber terrain to show where data lives and how it moves, and it maintains a real-time inventory of IT resources, configuration and patch levels included. That is the groundwork segmentation depends on.
For verification, it inspects and decodes user access requests, a “watch the watchers” approach, to confirm Zero Trust controls work as designed and haven’t been undone by misconfiguration, exploits, or insiders. It complements IAM solutions rather than replacing them. It also monitors all ports and protocols up to the application level and can filter or block transactions that violate policy. An email whose contents break data loss prevention policy, for example, can be stopped.
For detection, Fidelis Elevate® integrates intelligence feeds, anomaly detection, and deception across network, endpoint, and cloud. It applies machine-learning analytics to network and endpoint metadata, supports analysts who use MITRE ATT&CK to place events in context, and can run newly identified threat intelligence against historical metadata to flag a past compromise.
Fidelis CloudPassage Halo® handles cloud administrative accounts. It watches for weak passwords, disabled multi-factor authentication, overly permissive administrators, and stale accounts, alerts on violations of ZTA configuration standards, and can automatically disable accounts until the SOC secures them. Log-based intrusion detection, file integrity monitoring, configuration monitoring, and vulnerability management come with it.
No single product delivers a complete Zero Trust architecture, guarantees compliance, or prevents every breach, and we don’t claim otherwise. These capabilities support the program. Architecture, policy, and ownership stay with the agency, and the work usually builds on existing architectures and rolls out in phases with trusted partners.
- Identify and neutralize threats faster
- Gain full visibility across your attack surface
- Automate security operations for efficiency
From Plan to Practice
Choose one mission system and answer five questions about it. Who can reach it? From which devices? With what privileges? Over which paths? And how would you find out if any of that were being abused? Wherever the answer gets fuzzy, you’ve found the next project. The agencies making headway on Zero Trust for federal agencies run it as an operating discipline with owners and measures, and they don’t shelve the architecture diagram once it’s signed.
Frequently Asked Questions
Can Zero Trust apply to systems that can’t support modern authentication?
Yes, through compensating controls. Put a gateway or proxy in front, restrict network paths to documented flows, watch the system more closely than its neighbors, and write down a replacement date so the exception doesn’t turn permanent.
How should agencies handle contractor and interagency access?
Decide first whether the agency issues the identity or trusts a federated one. Scope access to specific applications and data, set it to expire, and log it to the same standard as internal users. Contract language should make the partner’s identity and device practices verifiable.
Who should own the Zero Trust program?
No one person. M-22-09 calls for an implementation lead, but that role rarely controls every tool. Pillar owners run identity, endpoint, network, application, and data work, system owners approve access changes, and security operations owns the monitoring signals and response actions.
How do we test that controls actually work?
Run scenarios. Try a stolen credential from an unmanaged device, move laterally between segments, or use a dormant privileged account. Check that policy denies or limits each attempt and that the SOC sees it, then repeat after major changes to catch drift.
Should access fail open or closed when a policy service is down?
Depends on the system. Where an outage creates operational risk, many teams pick a defined degraded mode with extra logging and a time limit. Decide per system, document it, and test it.
Do these requirements cover classified and national security systems?
Not directly. National security systems follow their own direction, and DoD follows its own strategy and timeline. The civilian guidance here doesn’t set their requirements.
