SSE and SASE are marketing terms that promise to both simplify and modernise your security stack. But when you break them down, most MSP customers don’t actually need the full bundle of capabilities.
Unpacking what each term means can be difficult, as they intentionally package together suites of capabilities. In our MSP guide to ZTNA we looked at how different architectures fit together, and the wider Zero Trust, SASE and SSE ecosystem around ZTNA. Here we’re looking more closely at the adjacent technologies that make up SASE and SSE from a capabilities basis, focusing on what your customers need, rather than what technologies vendors bundle together.
One of the things that stands out to us is how often the buzzwords drive adoption conversations. “We need to be SASE”, or “How can we replace the VPN with SSE?”, but for most MSP customers, the actual business need is far simpler.
As we looked at in our MSP guide to Zero Trust Network Access (ZTNA), there are a range of architectures that can deliver remote, private access for the customer, and each architecture has its own strengths, weaknesses, and trade-offs. One of the strengths of ZTNA with the mesh overlay architecture is that it can be coupled with DNS-filtering to remove malware, ads and other unwanted content while also providing a compelling replacement to VPN for the remote, private access use-case, meeting the actual customer need in a much simpler package.
For many MSP customers, endpoint protection software, combined with remote private access and DNS filtering for Internet-bound traffic is enough. And when the customer has a requirement for TLS decryption and content inspection, adding an SWG to the mix still keeps the package focused and tailored to customer need, rather than deploying a full SASE and SSE bundle, where every additional feature is another thing for the service desk to administer, troubleshoot, and support.
Requirements driven ZTNA
Use the interactive tool below to explore how technologies map to customer requirements. Select technologies on the left to see which capabilities each provides.
Select technologies on the left to see which customer requirements they satisfy.
ZTNA: Mesh Overlay
Agent-based architecture with centralised policy management. Direct encrypted tunnels between peers established using outbound-only traffic, hole punching, and NAT traversal.
ZTNA: Software Defined Perimeter (SDP)
Clients connect to a gateway appliance (via SPA, an encrypted port knock). Appliance is placed onto the public internet to accept inbound connections using customer infrastructure, but remains silent until a connecting client authenticates successfully, at which point the connection is proxied into the LAN segment.
ZTNA: Cloud-Brokered
Both sides (client and resource connector) connect outbound to the vendor's cloud; traffic is brokered through, and inspected by, vendor infrastructure.
SWG: Secure Web Gateway
Inline proxy between users and the internet. TLS decryption, URL filtering, and malware scanning. Self-hosted or cloud-delivered.
CASB: Cloud Access Security Broker
Visibility and control over SaaS applications. Discovers shadow IT and enforces data security policies.
SD-WAN: Software-Defined Wide Area Network
Network optimisation, multi-ISP aggregation, and WAN-level traffic management with performance SLAs.
Internet Traffic
Remote, Private Access
Governance
Network & Reliability
Exploring SASE and SSE
Gartner analysts coined the term Secure Access Service Edge (SASE) in 2019 to describe a unified platform which combined network connectivity and cloud-delivered security into a single “stack”:
- SASE - Networking Layer
- SD-WAN: routing and traffic optimisation, branch connectivity etc.
- SASE - Security Layer
- Secure web gateway (SWG)
- Cloud access security broker (CASB)
- Zero trust network access (ZTNA)
- Firewall-as-a-service (FWaaS)
Then in 2021 Gartner introduced the term Security Service Edge (SSE) to isolate the security stack from SASE. Enterprises were adopting the cloud security components independently of the networking elements, and SSE gave analysts and vendors a way to categorise those products without requiring the full SASE architecture, which included SD-WAN.
- SSE Security Layer
- Secure web gateway (SWG)
- Cloud access security broker (CASB)
- Zero trust network access (ZTNA)
- Firewall-as-a-service (FWaaS)
Both terms describe bundles of capabilities grouped together: a single cloud-hosted platform delivering functions that were previously separate appliances or services. The classification model assumes organisations have a business requirement to consolidate existing networking and security functions into one system. That assumption is most relevant to large and enterprise organisations operating multiple security appliances such as SWG, VPN, CASB, firewalls, DLP, and proxies, running multiple network edges including branches, data centres, cloud VPCs, and remote users, and managing multiple vendors and consoles that don’t talk to each other. The terms therefore target organisations trying to collapse dozens of point products into a single cloud-delivered platform.
The market then reinforces the model. Once analyst categories like SASE and SSE are established, enterprises adopt them in procurement language, vendors position against them to remain visible, and analyst evaluations rank products within those same categories. That creates a feedback loop: analyst taxonomy shapes enterprise demand, enterprise demand shapes vendor positioning, and vendor positioning entrenches the taxonomy.
Knowing that, we propose looking at this from the other end of the telescope, starting from the business requirement and mapping back to the technologies that deliver it. In many cases that means selecting only the capabilities actually required, rather than adopting the full SASE or SSE stack, which smaller to mid-sized organisations served by MSPs rarely need in their entirety.
ZTNA
Zero Trust Network Access is the modern VPN replacement. It provides secure, private access to internal resources based on identity verification rather than network location. Some of the most common use-cases MSPs have for ZTNA are to address challenges like:
- Remote workers accessing internal applications like Sage, QuickBooks, on-prem CRM, file shares, and printers without being on the office network
- MSP technicians reaching customer infrastructure (RDP, SSH, network devices) across dozens of customer sites
- Connecting customer branch offices to head office or cloud environments
- Scoping contractor or vendor access to a single resource during a project
- Protecting remote endpoints with DNS filtering when users are off-network
Many roads lead to ZTNA
ZTNA is not a single technology. Multiple approaches, or architectures exist, each with different operational trade-offs. Common approaches include mesh overlay networks, software-defined perimeter (SDP), and cloud-brokered models. The architecture determines how connectivity is established, where enforcement occurs, and how traffic is routed. Our MSP guide to ZTNA examines these architectures in more detail.
One advantage of a mesh overlay ZTNA architecture is that it can also act as the pathway to the public internet and apply DNS filtering. This removes the need for a separate secure web gateway in environments that do not require inline inspection.
For most MSP customers, ZTNA combined with DNS filtering covers the default requirement: private access to internal resources and domain-level web protection. This is typically sufficient when there is no regulatory requirement for inline inspection, no SaaS governance requirement, and no need for WAN-level traffic engineering.
Enclave implements mesh overlay ZTNA with optional DNS filtering. It can integrate with a SaaS DNS filtering provider or use an existing one. Internet access can be routed by sending 0.0.0.0/0 through one (or more) Enclave Gateways, allowing DNS-filtered internet access while maintaining private overlay connectivity.
Where inline inspection or SaaS governance is required, Enclave complements an SSE stack. In such cases, Enclave is used exclusively for private access, while complementary components like SWG and potentially CASB tooling govern internet-bound and SaaS traffic with a richer capability set.
SWG
Secure Web Gateway upgrades DNS filtering to full inline proxy inspection. Where DNS filtering blocks or allows based on domain names at resolution time, SWG operates as an inline proxy that decrypts TLS traffic, performs deep packet inspection, applies granular URL filtering (not just domain-level), scans for malware in real-time, and enforces acceptable use policies. DNS filtering asks “should I resolve this domain?” SWG asks “what is the user actually doing, and should I allow it?”
Note that a mesh overlay ZTNA paired with a standalone SWG (separate products) may be preferable to a bundled SSE platform. In a bundled SSE platform, all traffic flows through the vendor’s centralised infrastructure. Separating the two splits traffic by purpose: private access flows peer-to-peer via the mesh overlay, while internet-bound traffic flows through the SWG for inline inspection. The customer gets TLS decryption and URL filtering where it matters, without routing internal traffic through a third party.
It’s worth highlighting that centralising all traffic through a vendor’s network introduces questions of data sovereignty, and exposes the end-customer to potential PoP locality, latency and slow capacity provisioning issues, ties operational uptime to vendor availability, may incur bandwidth overage charges depending on the vendor, and risks disruption to service as the vendor updates or changes their platform during growth. Conversely, host-based, but cloud-managed SWGs often avoid some of these concerns by performing inspection on the endpoint itself rather than routing traffic through the vendor’s cloud.
Indicators customers need this:
- Regulatory requirement for inline traffic inspection
- Need to block specific URLs, not just domains
- Acceptable use policies that require content-level enforcement
- Real-time malware scanning for web traffic
Add SWG when the customer needs TLS decryption, URL filtering beyond domain level, or inline malware scanning. This is the step up from DNS filtering to inline proxy, meaningful when the customer has regulatory requirements for content inspection or needs granular control over web activity.
CASB
Cloud Access Security Broker tooling provides visibility and control over SaaS applications. It discovers use of both sanctioned and unsanctioned (“shadow IT”) cloud applications and applies policies to control their use. CASB answers questions like “what cloud apps are employees using?”, “is anyone uploading sensitive data to unsanctioned services?”, and “what did Bob upload to Dropbox?”
Data Loss Prevention (DLP) is typically bundled with CASB. It inspects content in transit and at rest, looking for patterns that indicate sensitive information (credit card numbers, personal data, intellectual property) and blocks or alerts on policy violations.
Indicators customers need this:
- Regulatory requirement for SaaS visibility
- Need to discover unsanctioned cloud applications
- Data exfiltration controls for sensitive information
- Compliance obligations around cloud data handling
Add CASB when the customer needs SaaS visibility, shadow IT discovery, or data exfiltration controls. Often driven by compliance. For example, a regulated accountancy firm needing to audit which staff are using personal cloud storage, or a healthcare provider required to demonstrate that patient data isn’t leaving sanctioned applications.
SD-WAN
Software-Defined Wide Area Network is the networking layer that separates SASE from SSE. Where ZTNA, SWG, and CASB are security capabilities, SD-WAN is about WAN-level traffic engineering: TCP tuning, QoS, multi-ISP path selection, private backbone with SLAs, and centralised management of routers, switches, and access points at remote sites.
SD-WAN is relevant when the customer has multi-site operations with genuine WAN optimisation needs: replacing MPLS circuits, aggregating multiple ISPs for redundancy, applying forward error correction to protect real-time applications like VoIP and video, or routing traffic across a vendor-operated global backbone with contractual performance guarantees.
Note that mesh overlay ZTNA already provides multi-path resilience via ICE candidate sets and NAT traversal. The SD-WAN differentiator is centralised traffic engineering (QoS, path selection, SLA-backed backbone), not connectivity itself.
Indicators customers need this:
- Multiple ISPs at locations requiring aggregation
- Replacing MPLS with SLA-backed internet connectivity
- Packet loss affecting real-time applications (VoIP, video)
- Need for formal performance SLAs
- Multi-cloud routing requirements
- Global operations with latency-sensitive applications
- WAN optimisation needs (large file transfers, database replication)
Add SD-WAN when the customer needs WAN optimisation, private backbone, or centralised network management. Often driven by multi-site operations replacing MPLS.
Right-size your stack
SSE and SASE are useful categories, but they’re capability bundles, not customer requirements. Strip away what the customer doesn’t need and you’ll often land on ZTNA with DNS filtering: private access and web protection without the complexity and cost of the full stack.
Some customers genuinely need more. Add an SWG for inline inspection, CASB for SaaS governance, or SD-WAN for WAN optimisation. But marketing categories shouldn’t dictate the architecture. Start from the customer requirement and work backwards. An MSP partner who can explain why a customer doesn’t need something may well earn more credibility than one that sells the full bundle without question.
To dig deeper into which ZTNA architecture fits your customers, see our MSP guide to ZTNA.
A few things we’ve taken as given:
Endpoint protection matters. We’ve focused on network-delivered security here. The case for stripping back SWG and CASB assumes your customers already have EDR and host firewalls in place.
Identity is table stakes. Everything discussed here depends on a functioning identity layer (IdP, MFA, conditional access). We haven’t broken identity down because it’s required regardless of which stack you choose.
We’re writing for MSPs serving mid-market and SMB. Even so, customers of all sizes are increasingly being asked about SASE and SSE by boards, auditors, insurers, and compliance frameworks. The Zero Trust story for your customers might not need to be the same as a Fortune 500.
FWaaS isn’t listed separately. Gartner’s SASE/SSE definitions include Firewall-as-a-Service alongside ZTNA, SWG, and CASB. In practice, the capabilities unique to FWaaS (IDS/IPS and deep inspection of non-web protocols) are increasingly folded into SWG solutions or bundled products rather than sold as a separate product, so we take SWG to include FWaaS capabilities.