Zero Trust Has a Reachability Problem, and Nobody Owns It
Most federal zero trust programs today are scored on what they’ve deployed versus what an attacker can reach once inside the environment, but the latter determines just how bad an incident might be. Before AI, this was survivable because finding an open path took an attacker weeks. But today, AI-assisted attack tooling has collapsed that window and streamlined the process.
Two new papers from the Cloud Security Alliance (CSA) Zero Trust Working Group highlight that gap:
Zero Trust Program Management Guidance: written for the people running the program (CxOs, GRC leads, ZT program managers).
Zero Trust Microsegmentation Guidance: written for the people wiring the enforcement (architects and the network, cloud, and OT engineers who own the actual rules).
Read separately, they’re a governance guide and a segmentation guide. Read together, they describe the same failure from opposite ends. Programs are graded on maturity, which describes what has been deployed, and the thing that decides how bad an incident gets is reachability, which almost no program measures or assigns to anyone.
A federal zero trust program can have a green maturity scorecard, a Zero Trust Native Access (ZTNA) broker in production, an approved target architecture, and no one in the building who can tell you how many systems can reach the domain controllers today compared to last quarter. We have watched that gap sit inside otherwise healthy programs for years, and until recently the guidance did not give anyone a clean way to name it.
The microsegmentation paper puts the diagnosis in one sentence we wish we had written: "Most organizations do not lack segmentation mechanisms, they suffer from fragmented segmentation intent."
What the two papers actually are
The program management paper is the more familiar document; it makes the case for a formally chartered zero trust PMO, hands you a RACI, and puts real entry and exit criteria on the five-step implementation process with named gate approvers at each transition. CSA anchors maturity assessments to the National Security Telecommunications Advisory Committee (NSTAC) five-step model with cross-walks to the CISA Zero Trust Maturity Model (ZTMM) and the DoD reference architecture. It also spends seven pages on supply chain and shared responsibility that are better than anything we have seen in a maturity model. If you run a program office, most of it will feel like a tidy version of what you are already doing.
We keep going back to the microsegmentation paper. It is the cleanest vendor-neutral treatment of enforcement placement published this year. It introduces vocabulary the industry has needed for a long time, catalogs the ways segmentation fails in production, and treats agentic AI as a segmentation problem instead of bolting it on as a closing paragraph.
Two Kinds of Segmentation, and Most Programs Bought One
The microsegmentation paper splits segmentation into two models:
Topology-defined segmentation asks where traffic may flow once it is inside. Zones, Virtual Local Area Networks (VLANs), security groups, Kubernetes network policies, firewalls between cells. It is what most of us grew up calling segmentation, and its job is to contain movement after something has already been compromised.
Connection-defined segmentation asks who or what may open a session to a specific resource, and it decides before reachability is granted. Items like identity, device posture, entitlement, and service intent are all evaluated up front. This is where ZTNA and Software Defined Perimeter (SDP) live. Its job is to reduce exposure before a session exists at all.
CSA is explicit that mature architectures layer both: "In mature architectures, these models are not mutually exclusive. Connection-defined controls reduce exposure before a session exists, while topology-defined controls constrain movement if a system, credential, or session is compromised." Connection-defined controls shrink what is discoverable. Topology-defined controls limit blast radius when a credential or a workload goes bad anyway. Neither one substitutes for the other, and the paper walks through the failure that follows when you pretend it does: a broker that admits a valid session into a flat enclave, or a beautifully zoned network where a stolen service account walks straight through the zone boundary because the zone never asked who was calling.
The paper goes further than most vendors would like. "Microsegmentation should not be treated as synonymous with asset discovery, traffic visibility, ZTNA, SDP, Secure Access Service Edge (SASE), firewalling, mutual transport layer security (mTLS), service mesh, or application authorization. These capabilities may support segmentation outcomes, but none of them is sufficient by itself unless it results in explicit, enforceable communication constraints." Read that list again and count how many line items in your current Network pillar evidence are on it.
A lot of agencies bought the connection-defined half, wrote "ZTNA deployed" into the Network pillar of their data call, and moved on. The east-west traffic inside the enclave looks the way it did in 2019. If your Network pillar evidence is a broker, you have solved the front door and reported that the whole building is secure.
The Gap Survives in the Seam Between Two Teams
Put the two papers side by side, and the seam is visible in the documents themselves.
The program management paper knows that east-west traffic matters. It says so plainly: "lateral movement controls, east-west traffic inspection, and identity-based segmentation must be designed assuming the initial access vector has already succeeded." Then look at its sample RACI, which is a good one. It assigns accountability for strategy and vision, governance and policy oversight, access control and least privilege design, continuous verification, automation and tooling, training, and stakeholder communication. There is no row for east-west enforcement. Segmentation intent lives under "access control design," which security owns. The enforcement plane that turns that intent into rules on a hypervisor firewall or a cloud security group belongs to whoever runs the network, and they are not in the accountable column for anything.
The microsegmentation paper names the consequence directly. Without governance, it says, "microsegmentation often suffers from 'no one owns east-west,' where responsibility for lateral traffic is split among networking, security, and operations teams." And it describes the mechanism: "Security may define policy intent, but NetOps or CloudOps may control the enforcement plane, leading to conflicts or inaction." When they disagree, the default is inaction, and inaction in segmentation means the permissive rule stays.
Together, the papers catalog what that seam produces over time: Exceptions with no expiry date that became permanent trust paths because the ticket closed and no one owned the follow-up. There is also coverage drift, where new workloads, containers, and serverless functions ship without segmentation because the pipeline that deploys them never talked to the team that writes policy. CSA's instruction here is one we would frame and hang in every program office: "Missing enforcement should be tracked as a coverage gap rather than hidden by architectural diagrams." Shared services (DNS, CI/CD, backup, secrets stores, patching infrastructure) are reachable from every segment because nobody scoped them as protected surfaces in their own right. Policy was codified but never carried its rationale, which the program management paper describes better than we can: policy "that lives only in vendor consoles or as exported configuration files cannot be reviewed at scale, drifts silently between environments, and produces audit findings that the program cannot remediate without manual archaeology."
No question on a maturity questionnaire surfaces any of this, which is the whole problem.
We watched a version of this seam surface during the compliance framework comment period at one large federal agency. Two of the new controls added in 2026 required mutual authentication for device-to-device communication, and the question that came back most often was some version of "does this apply to my internal API calls and database queries inside my own boundary?" It was a fair question, and the discussion language had to be updated to answer it. What the question revealed was that a lot of system teams had never had to state in writing which internal flows were theirs to secure and which belonged to the platform. Nobody had been asked before. The control forced the ownership conversation that the architecture diagram had let everyone skip.
AI Closes the Window
For most of the last decade, the ownership seam was survivable because finding an unnecessary path took an attacker time: discovery, enumeration, pivoting, credential harvesting, more enumeration. Weeks of dwell, usually. The gap between "this path exists" and "this path got used" was the margin that let programs report green and get away with it.
The microsegmentation paper is blunt about what changed: "any service, API, tool, management plane, identity system, model endpoint, data store, or orchestration service that is unnecessarily reachable becomes a more urgent risk." The paper's framing of what segmentation is now for is worth quoting in full, because it is the thesis of this post stated by someone else: "As AI-assisted attack techniques reduce the time required to discover, weaponize, and exploit reachable services, microsegmentation helps shift defense from 'detect and respond after exposure' toward preventing unnecessary reachability in the first place." We made the detection-side version of this argument in May when OMB issued M-26-14 and we said adversaries were moving at machine speed. This is the enforcement-side corollary.
Agentic systems add a second problem the architecture review never saw coming. Agents select tools, invoke APIs, retrieve data, and open egress paths at runtime, and they cross trust domains by design. CSA's framing here is sharper than most of what we have read on the subject: "For agentic workloads, valid identity and posture are not sufficient if behavior is compromised by prompt injection, poisoned memory, malicious tool output, or model/tool supply-chain compromise." The agent is who it says it is. It is just doing what someone else told it to. That is a reachability control problem, and the paper treats it as one, with risk tiers by autonomy and action reversibility, an approved inventory of what each agent may reach, and deny-by-default on unapproved egress.
Every unnecessary path that stayed open was tolerable because someone, consciously or not, priced it against human dwell time, and that assumption no longer holds.
What to Measure Instead
(Program leads can skim this one. Engineers, this is your section.)
If maturity tiers are the wrong unit, reachability evidence is the right one, and the microsegmentation paper supplies better metrics than the program management paper does. Pull these into whatever you already report:
Percentage of workloads under identity-based policy rather than IP-based rules
Count of permitted east-west paths, tracked quarter over quarter and expected to go down
Exception half-life, meaning how fast exceptions actually expire, which is a different number from how many exist
Mean time to isolate a compromised workload
Coverage drift, expressed as discovered assets against assets under policy
For agentic workloads: the approved tool inventory, denied egress attempts, and newly observed dependencies since the last review
Then add documented failure behavior, which both papers demand and which we have rarely seen a program produce. The microsegmentation paper's reasoning is the operational truth every SOC lead already knows: a policy fabric "must state 'what happens when things go wrong,' because outages drive bypasses." What does enforcement do when the control plane is unreachable, when identity signals are missing, when telemetry goes dark? Fail-open, fail-closed, or fail-safe, specified per environment and per flow type. IT admin paths usually fail closed. OT control loops often have to fail safe with compensating monitoring. If your program cannot produce that document, your segmentation design is a hypothesis you have not tested yet.
A word on the program management paper's numbers: It offers reference targets like 200% ROI inside 24 months, a 60% reduction in security incidents, and a sub-2% false positive rate. The paper itself says these are reference points to adapt, and none are sourced. Treat them as a reason to measure reachability, where the numbers are yours, rather than as goals to write into a charter.
One last thing for anyone evaluating tools this cycle. The microsegmentation paper closes with a vendor checklist built around evidence to ask for and red flags to watch. Our favorite red flag, quoted exactly: "'We do identity' but only for users; workloads, services, processes, and non-human identities remain IP/port-based."
Where This Leaves a Program Office
The zero trust work our team runs across FedCiv exists because self-attested maturity data has predictable failure modes, and the pilot we are running with automated zero trust maturity insights is an attempt to back those answers with telemetry from tooling agencies already operate. Reachability is the next thing that evidence has to cover, and it is harder than pulling a Security Hub finding, because it lives in the seam between two teams. The microsegmentation paper draws the line we are trying to cross: "visibility alone is not segmentation; it becomes a zero trust control only when observed dependencies are translated into an explicit, enforceable, continuously governed communication policy."
We have one of these numbers, though it is on the identity plane rather than the network. Before rolling out a Privileged Access Management (PAM) solution at a federal agency, over 95% of internal system users held an application-admin role. After it, every human user was on a least-privileged team role, planned use of the admin role was virtually eliminated, and every emergency use of it raised an alert. That is a reachability reduction. It just measures who can reach what through Identity Access Management (IAM) instead of through a security group, and the seam we had to cross to get it was the same one.
For the program leads reading this: name an owner for reachability. One person or one team, in the accountable column, for the count of permitted paths inside your enclaves. Give them a monthly artifact to produce, built from the protect-surface register, the coverage dashboard, exception aging, and a drift report. Then tie your five-step gate approvals to that artifact instead of to tool deployment milestones.
You cannot govern a path you have never counted, and most programs have not counted.
Aquia supports several large federal agencies with their zero trust maturity. Read our case study to learn how we’ve replaced manual, spreadsheet-based zero trust maturity tracking with a custom-built scoring application, giving security teams in-depth, system-level visibility into their zero trust posture.
