What Is SASE? A Network Engineer's Guide to Secure Access Service Edge in 2026

What is SASE? Secure Access Service Edge is an architecture that delivers SD-WAN and cloud security as one service from vendor points of presence, or PoPs. Instead of hauling branch and remote-user traffic back to a headquarters firewall, you send it to the nearest PoP for inspection. The short formula is SASE equals SD-WAN plus SSE.

Gartner coined the term in 2019 and later split out Security Service Edge, or SSE, as the security half. For a network engineer the practical change is simple. Your branch firewall stops being the main inspection point. It becomes a tunnel endpoint, a local segmentation device and a fallback path.

This guide explains the architecture without the marketing, maps the 2026 vendor field, and shows how an SRX branch connects to an SSE PoP. Junos examples are written against the Junos OS 23.4 train on the SRX300 line. Verify them in a lab, and against your SSE vendor's onboarding guide, before production use.

Still choosing branch hardware? Start with our small business firewall comparison of SRX, FortiGate and Palo Alto.

What Is SASE Made Of?

Most platforms add DLP, DNS security and sandboxing. They also integrate with an identity provider such as Entra ID or Okta. The identity link is what makes policy follow the user rather than the subnet.

Why SASE Exists: The Backhaul Problem

The classic enterprise WAN was hub-and-spoke. Branches reached the internet through a central firewall, because that was where the security stack lived. That made sense when the applications also lived in the data centre.

Once email, collaboration and CRM moved to SaaS, backhaul started working against users. A branch user could hairpin through a distant data centre to reach a SaaS service hosted near the branch. You pay for that detour twice: in WAN bandwidth and in latency on every session.

SASE moves inspection to where the traffic already goes. The trade-off is control. You give up owning the inspection box, the egress IP and the exact path, and you take on a dependency on the PoP quality and uptime of one vendor. That is a good trade for a SaaS-heavy, distributed workforce. It is a poor one for a single site whose traffic is mostly east-west to on-premises servers.

SASE vs SD-WAN vs SSE vs ZTNA

SD-WAN is connectivity. It picks the best link for each application, but on its own it does not inspect the traffic. Every SASE platform includes SD-WAN, but not every SD-WAN product is SASE.

SSE is the security half on its own: SWG, CASB, ZTNA and usually FWaaS. Organisations that do not need WAN change often buy SSE first and keep their existing branch routers or firewalls.

ZTNA is one component inside SSE. Zero trust is the principle behind it: no implicit trust based on network location. You can adopt ZTNA for remote access without buying a full SASE platform.

The SASE Vendor Field in 2026

The table uses Gartner Magic Quadrant placements for SASE Platforms, as published by the vendors and reported by SDxCentral. Placements are one analyst view, not a measure of fitness for your network.

Gartner moved Fortinet out of the Leaders quadrant after one year. It cited delayed features, customer experience and frequent patching. Palo Alto stayed a Leader but was noted for pricing. Read the full report through a vendor reprint if placement matters to your approval process.

Where Juniper fits now that it is part of HPE

HPE completed its acquisition of Juniper in July 2025, so Juniper SASE products are now HPE products. Juniper brought Juniper Secure Edge, which Juniper describes as full-stack SSE covering FWaaS, SWG, CASB with DLP and ZTNA. It also brought the Session Smart Router for SD-WAN, and Mist for AI-driven operations.

HPE already had its own SSE and EdgeConnect SD-WAN. Gartner expects HPE to integrate the SRX stack and Mist into its platform, and it flagged management complexity and a comparatively low PoP count. The DOJ settlement also required HPE to license the Mist AIOps source code to a third party by auction, so check the current outcome. If you are a Juniper shop evaluating SASE, ask HPE which SSE and SD-WAN products it will carry forward, and get the answer in writing.

How an SRX Branch Connects to an SSE PoP

Most SSE platforms accept a standards-based IKEv2 IPsec tunnel from a branch device. IKEv2 is defined in RFC 7296, which is why an SRX can talk to almost any vendor's PoP. The provider will give you the PoP address, the proposals it accepts and the IKE identity format it expects. Use those values, not ours.

The example uses 198.51.100.50 as the PoP, 203.0.113.2 as the branch WAN address and 192.0.2.0/24 as the branch LAN. Apply it with commit confirmed 5 and keep console or out-of-band access. Moving the default route into a tunnel is exactly the change that locks people out.

Step 1: build the tunnel to the PoP

set interfaces st0 unit 1 family inet
set security ike proposal SSE-IKE-P authentication-method pre-shared-keys
set security ike proposal SSE-IKE-P dh-group group19
set security ike proposal SSE-IKE-P authentication-algorithm sha-256
set security ike proposal SSE-IKE-P encryption-algorithm aes-256-cbc
set security ike policy SSE-IKE-POL proposals SSE-IKE-P
set security ike policy SSE-IKE-POL pre-shared-key ascii-text "replace-with-provider-supplied-psk"
set security ike gateway GW-SSE ike-policy SSE-IKE-POL
set security ike gateway GW-SSE address 198.51.100.50
set security ike gateway GW-SSE external-interface ge-0/0/0.0
set security ike gateway GW-SSE local-identity hostname branch01.example.net
set security ike gateway GW-SSE version v2-only
set security ike gateway GW-SSE dead-peer-detection probe-idle-tunnel
set security ipsec proposal SSE-IPSEC-P protocol esp
set security ipsec proposal SSE-IPSEC-P encryption-algorithm aes-256-gcm
set security ipsec policy SSE-IPSEC-POL perfect-forward-secrecy keys group19
set security ipsec policy SSE-IPSEC-POL proposals SSE-IPSEC-P
set security ipsec vpn VPN-SSE bind-interface st0.1
set security ipsec vpn VPN-SSE ike gateway GW-SSE
set security ipsec vpn VPN-SSE ike ipsec-policy SSE-IPSEC-POL
set security ipsec vpn VPN-SSE establish-tunnels immediately
set security zones security-zone untrust host-inbound-traffic system-services ike
set security flow tcp-mss ipsec-vpn mss 1350

Step 2: steer internet-bound traffic into the tunnel

set routing-options static route 198.51.100.50/32 next-hop 203.0.113.1
set routing-options static route 0.0.0.0/0 next-hop st0.1
set security zones security-zone sse interfaces st0.1
set security policies from-zone trust to-zone sse policy TO-SSE match source-address any
set security policies from-zone trust to-zone sse policy TO-SSE match destination-address any
set security policies from-zone trust to-zone sse policy TO-SSE match application any
set security policies from-zone trust to-zone sse policy TO-SSE then permit
commit confirmed 5

The /32 route keeps IKE and ESP to the PoP on the ISP path. Without it, the default route would try to send the tunnel inside itself. Traffic entering zone sse does not match a trust-to-untrust source NAT rule. The PoP therefore sees your LAN addresses and performs egress NAT itself, so confirm your provider expects that.

Fail-open or fail-closed: a decision, not a default

If the tunnel drops, what should users get? Adding set routing-options static route 0.0.0.0/0 qualified-next-hop 203.0.113.1 preference 10 creates a floating default via the ISP. That keeps users online but sends them out uninspected. It only works if your trust-to-untrust policy and source NAT still exist.

Leaving it out fails closed: no inspection, no internet. Regulated sites often want fail-closed, while retail sites often want fail-open. Either way, test that st0.1 actually goes down when the SA drops on your release and platform, because the floating route depends on it.

Verification

With the tunnel healthy, the default route points at st0.1 and the IPsec SA is up. The output below is abridged and illustrative, and column layout varies by release.

user@srx-branch> show route 0.0.0.0/0 exact

inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 01:12:44
                    >  via st0.1
                    [Static/10] 01:12:44
                    >  to 203.0.113.1 via ge-0/0/0.0

user@srx-branch> show security ipsec security-associations
  Total active tunnels: 1     Total Ipsec sas: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131074 ESP:aes-gcm-256/None 7c1d2e3f 3290/ unlim - root 500 198.51.100.50
  >131074 ESP:aes-gcm-256/None 9a8b7c6d 3290/ unlim - root 500 198.51.100.50

The broken state to recognise is the floating route active with no IPsec SA listed. Users are online, the helpdesk is quiet, and nothing is being inspected. Alert on the SA, not on user complaints. If the SA never forms, work through the phase checks in our SRX site to site VPN guide, which apply unchanged to an SSE peer.

A Realistic Migration Order

1. Replace remote-access VPN with ZTNA. It is low risk because branch perimeters stay unchanged, and users notice the improvement.
2. Move web and SaaS inspection to SWG and CASB. Plan TLS inspection early, because certificate distribution and exemptions take longer than the tunnel work.
3. Tunnel branches to the PoP. Start with one site, and decide fail-open or fail-closed before the second.
4. Replace WAN circuits with SD-WAN as contracts expire. Tie this to contract dates rather than a big-bang cutover.
5. Shrink branch firewalls to local segmentation. Keep on-premises enforcement where east-west traffic or local servers need it.

Mistakes We See Most Often

The first is skipping the TLS inspection conversation. Most web traffic is encrypted, and an SWG that does not decrypt sees little more than hostnames. Decryption needs a trusted certificate on every managed device and an exemption list for pinned or sensitive categories.

The second is ignoring egress IPs. Many SaaS tenants and partner APIs allowlist source addresses. SSE PoPs egress from shared pools by default, and dedicated egress addresses are usually an extra. Inventory your allowlists before cutover.

The third is assuming PoP coverage. Ask for PoP locations near your actual users and test latency from those sites during the trial. Engineers debating SASE versus traditional network design raise the same point repeatedly: a well-run on-premises stack can beat a distant PoP.

More branch and SRX design material is in the Security and Firewalls hub.

Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc. Other product names are trademarks of their respective owners. juniperclient.com is independent and unaffiliated.

Frequently Asked Questions

What is SASE, actually?

It is SD-WAN and cloud-delivered security (SSE) sold as one service and enforced in vendor PoPs near your users. The practical effect is that inspection moves from your headquarters firewall to the PoP. Everything else is packaging.

SASE vs traditional network design: when is it worth it?

It pays off when users are distributed and most applications are SaaS or public cloud. It pays off less for a single site with mostly on-premises servers and an experienced security team. Model latency and egress IP requirements before deciding.

Is anyone actually happy with their SASE setup?

Many teams are, but in our experience satisfaction tracks PoP proximity, TLS inspection planning and support quality more than brand. Run a pilot with real users at your most remote site before signing. Measure latency to the PoP and helpdesk tickets, not just features.

What is the difference between SASE and SSE?

SSE is the security half: SWG, CASB, ZTNA and usually FWaaS. SASE is SSE plus SD-WAN from the same platform. You can buy SSE alone and keep your existing WAN.

Can a Juniper SRX connect to a SASE or SSE provider?

Yes, as long as the provider accepts IKEv2 IPsec site tunnels, which most do. Build a route-based tunnel on an st0 unit, route internet-bound traffic into it, and verify with show security ipsec security-associations. Use the proposals and identity format the provider specifies.