SASE and SSE Guide

Secure access service edge (SASE) and security service edge (SSE) move the web proxy, cloud access controls, remote access and firewall into a provider's cloud, which removes appliances from your edge but makes that provider's platform, policies and admin accounts part of your attack surface. Most organisations reach SASE by replacing a VPN concentrator, an on-premises proxy or branch routers, and the hard parts are steering traffic reliably, integrating identity and device posture, and deciding what happens when the service fails. This guide explains the components, SASE versus SSE, single-vendor versus dual-vendor designs, steering methods, identity integration, performance testing, operational risk and a phased migration. It is for network and security architects, and for teams evaluating or running a platform. ZTNA policy design, TLS inspection and DLP each have their own guides, linked rather than repeated.

Key takeaways

• SSE is SASE without the network. SSE covers the security services (secure web gateway, CASB, ZTNA and usually FWaaS and DLP); SASE adds SD-WAN so branch connectivity and security are delivered and managed together.
• Steering decides coverage. Traffic that never reaches the service is not inspected: agents, PAC files and branch tunnels each leave gaps, and fail-open settings quietly turn controls off.
• Identity is the policy key. Every rule depends on the identity provider, group data and device posture signals, so their quality sets the quality of enforcement.
• The provider becomes critical infrastructure. NIST SP 800-207 warns that a provider "may also accidentally take a cloud-based PE or PA offline", so plan failure modes and protect the admin console like a domain controller.
• Migrate by user population and app, not by product. Move remote users and web traffic first, private apps next, branches last, with pilot rings, monitor-only policies and a tested rollback path.

What SASE and SSE contain

NIST SP 800-215 describes SASE as "an architecture that converges networking and security functions" and "delivers them at a global scale as a cloud service" through points of presence (PoPs), with firewall, secure web gateway, anti-malware, IPS, CASB and DLP as its minimal security services and browser isolation and continuous risk assessment as advanced features. SSE is the industry term for the security subset delivered without SD-WAN. The components below are what you are actually buying.

One distinction causes confusion in evaluations: a CASB governs what users do with cloud apps and data in session; it does not decide who should hold which entitlements. That is identity governance, covered in the IGA Buyer's Guide.

Choosing the model: SASE or SSE, one vendor or two

• Policy enforcement parity: CISA's TIC 3.0 Remote User Use Case lists "Policy Enforcement Parity" as a universal capability and notes that using the same provider across campus, branch and remote users simplifies it. Whatever the model, write one policy set and measure where it differs.
• Contract on service attributes: MEF 117 (now maintained by the Mplify Alliance as 117.1) defines SASE service attributes, the security functions, policies and connectivity a subscriber and provider agree. Use that structure for the SLA schedule rather than marketing feature lists.
• Small versus large: a small organisation gains most from single-vendor SSE with the vendor agent on every managed device. A large one should decide SD-WAN separately, on contract timing and network team skills, rather than bundling it by default.

Steering traffic into the service

The TIC 3.0 Remote User Use Case says agencies can direct traffic to security-as-a-service providers "using client agents, proxy settings, or DNS". Each method has a coverage gap and a failure mode.

• PAC details matter: MDN documents that the file should be served as application/x-ns-proxy-autoconfig, that a failed proxy falls through to the next semicolon-separated entry and is retried after 30 minutes, and that isInNet() and dnsResolve() trigger DNS lookups, so put cheap string matches first. Browsers strip the path from HTTPS URLs, so PAC rules cannot depend on it.
• Tunnels: provider documentation shows the usual pattern: anycast or paired PoP endpoints, IKEv2 with Diffie-Hellman group 20 recommended, dead peer detection, a unique tunnel per endpoint pair, and MSS clamping below the 1,500-byte MTU. Prefer IPsec over GRE across the internet.
• QUIC and bypass lists: block outbound UDP 443 on managed devices where the SWG cannot inspect QUIC, so browsers fall back to TCP. Keep the bypass list (collaboration media, certificate-pinned apps, health checks) owned and reviewed, because every entry is uninspected traffic.
• Agent tamper protection: require a password or admin token to disable the agent and alert when it reports disabled.

TLS inspection and data protection

An SWG or inline CASB without decryption sees little beyond domain names. Decide which categories you decrypt, which you exempt (health, banking, pinned applications) and who approves exemptions, and distribute the inspection CA to every trust store. TIC 3.0 lists "Break and Inspect" among web capabilities. The design decisions, CA protection and privacy issues are in the TLS Inspection Guide. DLP policies in SASE reuse the classification and rules of your wider programme; see the Data Loss Prevention (DLP) Guide. For exfiltration, ATT&CK T1567.002 (Exfiltration to Cloud Storage) lists M1021 Restrict Web-Based Content, noting web proxies can block unauthorised external services: CASB tenant restrictions that allow only your corporate instance of a storage service are the practical control.

Where identity fits

NIST SP 800-215 says identity must be verified with "robust, phishing-resistant multi-factor authentication" and that context about user, device, time, service and environment feeds a risk-based decision. The NCSC's zero trust principles add: "Each request for data or services should be authorised against a policy."

• Identity provider federation: authenticate users to the service with SAML or OpenID Connect from your IdP, and provision users and groups with SCIM so policy follows joiners, movers and leavers. A stale group membership is a policy error. See the SCIM Provisioning Guide.
• Device posture: pass managed-device signals (compliance state, EDR health, disk encryption, OS version) into policy, and give unmanaged devices browser-only or isolated access. The NCSC lists "service or device health" among the important indicators. See the Device Trust and Posture Guide.
• Conditional access tie-in: some IdPs can require that sign-ins come through the SASE service, closing the path where a stolen token is replayed from elsewhere. See the Conditional Access Guide.
• Non-human identities in the platform: ZTNA app connectors enrol with tokens and hold outbound trust; CASB API mode uses OAuth grants with broad read access to SaaS tenants; SIEM and SOAR integrations use API keys; branch tunnels use pre-shared keys or certificates. Inventory each with an owner, scope it, and rotate it. See the SaaS and OAuth App Governance Guide and the API Key Management Guide.
• Workload traffic: servers and service accounts that call SaaS APIs rarely run an agent; steer them through branch or data centre tunnels and write policy on source and destination rather than user.

Performance and PoP coverage

• Measure from your locations: test latency, throughput and page load from each office and representative home connections to the nearest PoP, during business hours, before signing. Published PoP counts mix full-service sites with edge or partner locations.
• Check which services each PoP runs: some locations offer SWG but not DLP, isolation or ZTNA brokering, so traffic hairpins to a distant PoP for those functions.
• Egress IP and geolocation: SaaS and banking sites see the PoP's IP address. Confirm country-correct egress, dedicated egress IPs for allow-listed partners, and how content localisation behaves.
• Data residency: find where logs, decrypted content samples and DLP incidents are stored and processed, and whether you can pin them to a region.
• Capacity and SLA: ask for availability per service, not per platform, plus maintenance windows and status page commitments.

Operational risk of the cloud proxy

NIST SP 800-207 is candid about cloud enforcement points: placing them in a properly secured cloud "mitigates the risk but does not eliminate it", and "An operational error could prevent an entire enterprise from functioning." It also warns that "a compromised PA could allow access to resources that would otherwise not be approved."

• Decide fail-open or fail-closed per traffic type: web browsing may fail open to direct internet with endpoint controls; private application access through ZTNA should fail closed. Document it and test it quarterly by blocking the PoP from a pilot device.
• Keep an emergency path: a small, monitored fallback (for example a retained VPN for administrators, or a secondary PoP region) with its own break-glass accounts. See the Break-Glass Account Guide.
• Treat the admin console as tier 0: an administrator can disable inspection, add bypasses or open private apps to everyone. Use phishing-resistant MFA, separate admin identities, role separation between policy authors and approvers, and alert on bypass and policy changes. The Stryker Cyberattack 2026 shows what one hijacked admin account can do with a cloud management console. See the Privileged Access Management Guide.
• Back up configuration: export policy through the API on a schedule, version it and diff changes, because SP 800-207 says configuration changes "must be logged and subject to audit".
• Watch the provider: subscribe to status and security advisories, and include the provider in incident response exercises.

Migrating from VPN and on-premises proxies

1. Inventory flows: list private applications with owners, ports and user groups from VPN and firewall logs; export proxy categories, exceptions and authentication rules.
2. Integrate identity first: federate the IdP, provision groups with SCIM, define posture signals and admin roles before any user traffic moves.
3. Pilot ring: IT and security staff on the agent with web policies in monitor or log-only mode for two to four weeks; compare blocks against the old proxy.
4. Remote web traffic: move remote users' internet traffic to the SWG, then enforce. Roll back by switching the agent forwarding profile or PAC file back to the old proxy, which stays live until cut-over is signed off.
5. Private applications: publish apps through ZTNA in waves, starting with web apps, then SSH, RDP and thick clients; remove each from the VPN as it moves. Detail is in the ZTNA Guide.
6. Branches: build primary and secondary tunnels per site, test failover, then move default routes; keep the local breakout path disabled but configured for rollback.
7. Decommission: retire the VPN concentrator and proxies once usage logs show zero non-emergency use for 30 days, and remove their accounts and certificates.

Carry nothing stale across. The Colonial Pipeline Ransomware Attack 2021 began with an unused VPN account; migration is the moment to remove dormant users rather than import them. The appliance risk you are leaving behind is described in the VPN Security Guide.

Detection and measurement

Stream SWG, CASB, ZTNA, FWaaS, DLP and admin audit logs to your SIEM. TIC 3.0 lists "Central Log Management with Analysis" as a universal capability and recommends taking timestamps from services, where clocks are reliable. The NCSC asks that monitoring "link back to the policies you have set". Alert on agent disabled or uninstalled, policy and bypass list changes, new admin accounts, ZTNA access to sensitive apps from non-compliant devices, and large uploads to unsanctioned storage. See the SIEM Guide.

• Percentage of managed devices with a healthy, enforcing agent (target: above 98 percent).
• Percentage of web traffic decrypted, and bypass list size over time.
• Private applications still reachable only through VPN, trending to zero.
• Unsanctioned SaaS applications with corporate data uploads per month.
• Service availability and median added latency per site, measured independently of the provider.
• Admin policy changes without an approved change record (target: zero).

Common failure patterns

• Silent fail-open: a PAC file ending in DIRECT or an agent set to fail open turns inspection off during every outage without anyone noticing.
• Bypass sprawl: exemptions added to fix tickets accumulate until large parts of traffic are uninspected.
• Lift-and-shift VPN access: publishing whole subnets through ZTNA recreates the flat network the migration was meant to remove.
• Posture by name only: device checks that pass on a registry key or certificate presence rather than health from the management platform.
• Unprotected console: shared admin accounts or password-only access to a platform that controls all traffic.
• Old access left running: the VPN stays up with stale accounts long after cut-over. VPN credentials remain a target, as the SonicWall SSL VPN Account Compromises 2025 showed when valid credentials opened more than 100 accounts.

Framework mapping

Practitioner checklist

• Write down which components you need (SWG, CASB, ZTNA, FWaaS, DLP, SD-WAN) and which existing products each retires.
• Choose single or dual vendor on operational capacity and concentration risk, and contract on service attributes and per-service SLAs.
• Steer managed devices with the agent, branches with IPsec tunnels, and document every fail-open and bypass decision.
• Federate the IdP, provision groups with SCIM and require phishing-resistant MFA and device posture for policy.
• Inventory platform non-human identities: connector tokens, CASB OAuth grants, API keys, tunnel keys.
• Protect the admin console with separate admin identities, role separation and alerts on policy and bypass changes.
• Test PoP latency and services from every site before signing, and test outage behaviour quarterly.
• Migrate in rings with monitor-only policies and a live rollback path, and retire VPN and proxy accounts at cut-over.
• Send all service and admin logs to the SIEM and report the metrics above monthly.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST NCCoE: SP 1800-35 Implementing a Zero Trust Architecture
• NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape
• CISA: TIC 3.0 Remote User Use Case
• CISA: Trusted Internet Connections (TIC) 3.0
• NCSC: Zero trust architecture design principles
• Mplify (MEF): MEF 117 SASE Service Attributes and Service Framework
• MITRE ATT&CK: T1567.002 Exfiltration to Cloud Storage

Related NHI Mgmt Group resources: ZTNA Guide · TLS Inspection Guide · Data Loss Prevention (DLP) Guide · Zero Trust Identity Guide · Enterprise Browser and Browser Security Guide