CISA Publishes New SASE Adoption Guide for Federal Agencies
New federal SASE guidance from CISA — defender roadmaps align this week. The agency's latest “Journey to Zero Trust” release tells civilian agencies how to retire legacy internet gateways for a cloud-delivered, zero-trust edge.
Key Takeaways
|
New federal SASE guidance from CISA — defender roadmaps align this week.
WASHINGTON — The U.S. Cybersecurity and Infrastructure Security Agency on June 24, 2026 published new guidance telling federal agencies how to replace their legacy internet gateways with Secure Access Service Edge (SASE) technology as part of the broader shift to zero trust. Titled “The Journey to Zero Trust: Using Secure Access Service Edge (SASE) in a Modern TIC 3.0 Solution,” the vendor-agnostic document explains how agencies can move from the perimeter-based Trusted Internet Connections (TIC) 2.0 model to the more flexible TIC 3.0 that CISA built around zero-trust principles. CISA aimed the guidance at federal civilian executive branch (FCEB) agencies but said state and local governments, critical-infrastructure operators and other organizations may also find it useful.
The release is regulatory guidance rather than a breach or vulnerability disclosure, but it carries real operational weight: it sets the architectural direction federal agencies are expected to follow, and the same patterns increasingly shape how regulated and federal-adjacent organizations design their own networks. The guide is the latest entry in a “Journey to Zero Trust” series CISA launched in 2025, and it sits alongside the agency's continuing push to put federal cyber defense on a faster, more measurable footing — from its risk-based federal patching directive to the longer-horizon migration mandates now reshaping federal cryptography.
| At a Glance | |
|---|---|
| Field | Details |
| Publisher | Cybersecurity and Infrastructure Security Agency (CISA) |
| Document | The Journey to Zero Trust: Using SASE in a Modern TIC 3.0 Solution |
| Audience | Federal civilian executive branch (FCEB) agencies; also useful to state/local and critical infrastructure |
| Framework | TIC 3.0; CISA Zero Trust Maturity Model |
| Purpose | Guide agencies from legacy TIC 2.0 / MTIPS to a cloud-delivered SASE edge supporting zero trust |
| Status | Published June 24, 2026; TLP:CLEAR; part of the “Journey to Zero Trust” series |
What CISA Published
The new document, published on June 24, 2026, is titled “The Journey to Zero Trust: Using Secure Access Service Edge (SASE) in a Modern TIC 3.0 Solution.” It is marked TLP:CLEAR, meaning it is intended for unrestricted distribution, and it is authored by CISA as part of the agency's ongoing “Journey to Zero Trust” series — the same line of guidance that produced its earlier microsegmentation material. The guide is vendor-agnostic and pattern-based: it summarizes a reference architecture, common augmentations, and transition considerations rather than recommending specific products.
At its core, the guidance describes how agencies can use SASE to move away from the limitations of the older TIC 2.0 model. Under TIC 2.0, agencies routed essentially all of their internet traffic through a small number of central access points, an arrangement that CISA says created bottlenecks for remote and branch users and slowed the adoption of newer technologies. TIC 3.0, by contrast, lets agencies build more distributed architectures — provided they continue to give CISA the visibility it needs into their traffic. CISA said SASE can replace the Managed Trusted Internet Protocol Services (MTIPS) that agencies have long relied on.
SASE itself bundles networking and security functions into a single, mostly cloud-based service. CISA's definition combines tools such as software-defined wide area networking (SD-WAN) with security controls including secure web gateways, cloud access security brokers, next-generation firewalls and zero trust network access (ZTNA). Chris Butera, CISA's acting executive assistant director for cybersecurity, said the guide “helps agencies realize the benefits of zero trust architectures,” while the agency stressed that reaching zero trust is a sustained transformation rather than a single product rollout. The release continues a pattern of CISA issuing prescriptive, deadline-aware direction to federal defenders, as it did with its binding operational directive on risk-based patching.
Implementation Implications for Federal-Adjacent Organizations
Although the guidance is written for FCEB agencies, CISA explicitly extended its relevance to state and local governments, critical-infrastructure operators and other organizations — the broad band of “federal-adjacent” entities that contract with, report to, or model their security on the federal government. For those organizations, the document functions less as a mandate and more as a credible reference architecture for retiring centralized internet gateways in favor of a distributed, cloud-delivered edge.
Two practical shifts in the guidance stand out for anyone planning a SASE migration. First, moving off MTIPS removes the central choke points where CISA's EINSTEIN sensors historically sat, which means agencies lose the telemetry those sensors provided unless they replace it. CISA's answer is that agencies must feed equivalent data to its Comprehensive Log Aggregation Warehouse (CLAW), a cloud service that collects agency-provided telemetry. For federal-adjacent organizations, the analogous lesson is that decentralizing the perimeter does not relieve the need for centralized visibility — it relocates it, and the logging pipeline has to be designed in from the start rather than bolted on.
Second, the guidance signals a notable change in long-standing practice around encrypted traffic. CISA said breaking and inspecting encrypted TLS traffic is no longer a universally recommended approach, citing its complexity and the latency it adds; it instead pointed to analyzing encrypted traffic for suspicious patterns, including the use of machine learning, without fully decrypting it. Organizations that have built their inspection strategy around wholesale TLS break-and-inspect will find that assumption being openly reconsidered by the federal government, which is itself a meaningful planning input.
Alignment With Zero-Trust Roadmaps
The SASE guide does not stand alone; it is explicitly positioned within CISA's broader zero-trust program and is meant to be read alongside the agency's Zero Trust Maturity Model. That model organizes zero trust into five pillars — identity, devices, networks, applications and workloads, and data — with each pillar advancing through maturity stages from traditional toward optimal. SASE, in CISA's framing, is one of the architectural moves that advances several of those pillars at once by pushing controls closer to users, devices and applications rather than concentrating them at a network perimeter.
That alignment matters because it tells defenders how to slot the guidance into an existing roadmap rather than treating it as a standalone initiative. An agency or federal-adjacent organization already measuring itself against the maturity model can read the SASE guide as a concrete path for advancing the networks pillar — and, by extension, the identity and applications pillars that ZTNA and secure-edge controls touch — without restarting its planning from scratch. CISA's repeated insistence that zero trust is a journey, not a product, is the connective tissue: the SASE guide is a waypoint on a maturity path, not a finish line.
It also fits a wider federal posture in which CISA and its partners are issuing increasingly specific, time-bound direction across the cyber stack. The same period that produced this SASE guidance has seen the federal government tighten patching timelines and set long-horizon migration deadlines elsewhere — including the executive-branch push toward post-quantum cryptography — signaling that zero-trust architecture, modern cryptography and faster remediation are being treated as parts of a single modernization agenda rather than disconnected programs.
Industry-Association Responses and What to Watch For
As regulatory guidance rather than an enforcement action, the SASE document was met with the measured, largely supportive reception that typically greets CISA architecture publications. Coverage from federal-IT and security trade press framed it as a pragmatic step that codifies a direction many agencies and vendors had already been moving toward, and industry commentary emphasized the guide's vendor-agnostic, pattern-based approach as a strength — it gives integrators and association members a common reference architecture to align around without endorsing particular products.
The more consequential signals to watch are operational rather than rhetorical. The clearest is the reconsideration of TLS break-and-inspect: a federal agency openly stating that full decryption is no longer universally recommended is the kind of position that ripples into vendor roadmaps, procurement language and the secure-web-gateway market, and it is worth tracking how quickly that framing is reflected in product guidance and agency acquisitions. A second signal is CLAW adoption — whether agencies moving off MTIPS actually stand up equivalent telemetry feeds at the pace CISA expects, since visibility, not connectivity, is the federal government's core concern in the transition.
For defenders outside government, the practical watch items are simpler: how the major SASE and SD-WAN vendors map their offerings to CISA's reference architecture, whether the ZTNA and machine-learning-based traffic-analysis patterns the guide highlights become baseline expectations in regulated sectors, and whether subsequent entries in the “Journey to Zero Trust” series add the implementation specificity that this architectural overview deliberately leaves open.
Open Questions
Several aspects of the guidance remain to be filled in. The document is, by design, an architectural and pattern-based reference rather than a step-by-step implementation playbook, so it does not prescribe fixed adoption milestones or a single compliance deadline by which agencies must complete the move to SASE; how aggressively and on what timeline agencies retire MTIPS and TIC 2.0 architectures is left to be seen. The guide is one entry in an evolving series, and whether CISA follows it with more granular, control-level implementation material is an open question.
Equally open is how the encrypted-traffic shift plays out in practice. CISA's move away from universal TLS break-and-inspect toward pattern-based and machine-learning analysis is a meaningful change in stated best practice, but its real-world effect depends on tooling, telemetry quality and agency capability that the guidance describes only at a high level. For now, what is firmly established is the direction: federal agencies are being told, in CISA's own published guidance, to retire perimeter-centric internet gateways for a cloud-delivered, zero-trust edge while preserving the agency's visibility into their traffic. Organizations that take cues from federal architecture can treat that direction as a planning input today, even as the finer details continue to develop.
A federal-adjacent implementation checklist, drawn from the guidance, looks like this: (1) inventory where you still rely on centralized, perimeter-based internet gateways and identify the choke points a SASE model would replace; (2) before decentralizing, design the replacement visibility — map which telemetry your current perimeter provides and how you will preserve it (CLAW for agencies; equivalent centralized logging for everyone else); (3) align the migration to a zero-trust maturity model so SASE advances defined pillars rather than becoming a standalone project; (4) revisit any strategy built on wholesale TLS break-and-inspect and evaluate pattern-based and ML-assisted analysis of encrypted traffic; (5) keep SASE adoption coupled to the rest of the modernization agenda — faster, risk-based patching and post-quantum-ready cryptography — rather than treating it in isolation; and (6) track subsequent CISA “Journey to Zero Trust” releases for the implementation specifics this architectural overview intentionally leaves open.