OMB M-23-22, Memorandum for the heads of Executive Departments and Agencies on Enhancing the Security of Federal Information and Information Systems, dropped in September 2023 as a follow-on to the Biden administration's zero-trust push. What it actually requires is not what most agencies think it requires. The vendor narrative around zero trust is still largely about products: identity and access management solutions, network segmentation tools, microsegmentation appliances. The memo is about architecture and operational discipline.
We have been in three dozen federal agencies over the past eighteen months helping them read that memo. The friction happens in two places. First, between what compliance says the memo requires and what security teams say it requires. Second, between what the memo says and what FITARA scorecards actually measure. Understanding both gaps is what makes a zero-trust program work instead of becoming a compliance tax.
The memo has five pillars: identity and access management, data security, device management, infrastructure, and operations. Most agencies focus on the first four. Operations is where the real work lives, and where most zero-trust programs fail.
The memo requires phased implementation of multi-factor authentication across all federal information systems. That is not new. What changed in M-23-22 is the requirement that MFA must protect not just human users but also service accounts, application-to-application connections, and API consumers. Many agencies have solved the human MFA problem. Almost none have solved it for service-to-service traffic, which is where federal systems actually spend most of their time.
The practical requirement is that every service account, every cross-agency API call, every cloud-to-on-premises tunnel needs cryptographic proof of identity. This is not about more password policies. It is about rearchitecting how systems authorize each other, which is a larger problem in federal agencies because legacy systems often don't support certificate-based service identity at all.
M-23-22 requires encryption of data at rest and in transit. Most agencies are already compliant with the transit part. The at-rest requirement is where the compliance-to-operations gap shows up. Agencies often have encryption enabled on their cloud infrastructure. The encryption keys are managed by the cloud provider. The memo, read by security teams, requires that agencies control the keys. Which is operationally harder and often not what the compliance team is actually checking.
The memo requires that agencies know the state of every device that connects to a federal system. That includes employee laptops, partner desktops, servers, IoT devices, and cloud instances. Mobile device management and endpoint detection tools handle the first two. The requirement for servers and cloud instances is different. The memo essentially requires a software bill of materials and asset inventory that most agencies do not have at the scope the memo implies.
Zero-trust infrastructure means no implicit trust based on network location. Every resource, from a cloud storage bucket to a database table, requires explicit authorization. Most federal cloud deployments use identity and role-based access control, which is the right direction. The gap is usually in observability. Without logging and alerting on who accessed what and when, the infrastructure is zero-trust in principle but not in practice.
"Zero trust isn't a product purchase. It's an operational posture you have to defend."Federal Practice
This is the pillar that separates zero-trust programs that work from ones that generate compliance evidence. The memo requires continuous monitoring, logging that survives six months of tampering attempts, security incident response procedures, and regular testing of security controls. Operations means: your team is actively looking for anomalies. Your logging is designed for forensics, not for dashboards. Your incident response is tested quarterly. Your SIEM actually has tuning rules that catch real attacks, not just technical controls that look good in an audit.
Most federal agencies have the first four pillars at seventy percent compliance. The operations pillar is where they are at twenty percent. That is where the vulnerability lives.
FITARA scorecards are OMB's mechanism for tracking agency IT modernization. They measure cloud adoption, IT portfolio rationalization, CIO authorities, and IT security posture. M-23-22 doesn't show up explicitly in FITARA, but it does show up implicitly in the security category. Agencies that move on zero trust early get credit in three ways.
The most successful zero-trust programs we have seen at federal agencies follow a pattern. It is not the pattern the memo describes. It is the pattern that works when you have legacy infrastructure, limited budget, and delivery pressure.
Start with logging and visibility. Before you invest in access control tools, make sure you can see what is actually happening. Deploy SIEM capability for your most sensitive systems first. The goal is not to have a perfect SIEM for the whole environment. It is to have one system where you know you can detect an intruder, and you know you can prove it. That gives you a confidence signal that the rest of the program is built on.
Implement service identity next. Once you have visibility, move to cryptographic identity for service-to-service traffic. This is a rearchitecture effort, not a procurement effort. Start with the most critical data paths: inter-agency API calls, cloud-to-on-premises connections, data pipeline authentication. Build mutual TLS and certificate management. Get it working for three systems. Then expand.
Then tackle network segmentation. After you have logging and service identity working, implement network-level zero trust. You can use microsegmentation tools, or you can use VPCs and security groups properly. The tool matters less than whether your team understands the policy and can defend it. Most agencies should start with application-layer enforcement before buying a microsegmentation product.
Finally, optimize for operations. Once you have the technical controls in place, invest in operational discipline. Tune your SIEM to reduce false positives. Build a runbook for responding to zero-trust alerts. Get your team comfortable with the tooling. The last mile of a zero-trust program is the hardest because it requires cultural change, not just technical change.
If you are reading this from inside a federal agency, here is a priority sequence for implementing M-23-22 that actually works.
Audit your logging posture. Do you have SIEM deployed? Does it cover your most critical systems? If not, deploy a SIEM for at least your cloud infrastructure, your identity system, and your most sensitive data stores. The vendors all claim to be easy to install. None of them are. Plan for three months and budget accordingly.
Map your service accounts. Every system that authenticates to another system needs to be documented. How many service accounts do you have? How do they currently authenticate? What would it take to move them to certificate-based authentication? The answer is usually harder than you think, but you need to know it before you commit to a timeline.
Pick a pilot for service identity. Choose one high-value data path that crosses trust boundaries. Cloud to on-premises, inter-agency API, or internal service mesh. Implement mutual TLS and certificate management for that one path. Get it working. Document it. Use it as a template for the rest.
Establish the governance baseline. Get your CIO, your agency head of security, and your program office leads in a room. Define what M-23-22 compliance looks like for your agency. Be specific about which pillars you are hitting by which dates. Make it visible to the FITARA scorecard team. Agencies that have explicit zero-trust commitments in their FITARA roadmap move faster than ones that treat it as a compliance afterthought.
Zero trust is not a product. It is a posture. The memo is real. The pressure is real. The agencies that will be ahead on FITARA in two years are the ones that are treating M-23-22 as an operational program, not a compliance checkbox. That means logging first, then identity, then access control, then operations. Not the other way around.
Bring the problem. We'll come back with a written brief: what to build, what to defer, and where AI actually moves the number. No deck pitches.