SASE and SSE platforms put a cloud provider's proxy in the path of almost every user connection you have, so a poor choice shows up as slow applications, broken inspection and an outage you cannot fix yourself. Secure service edge (SSE) bundles the security services: secure web gateway (SWG), cloud access security broker (CASB), zero trust network access (ZTNA), firewall as a service (FWaaS), data loss prevention (DLP) and often remote browser isolation (RBI). Secure access service edge (SASE) adds SD-WAN and the branch network. Every provider claims a complete platform; component depth, points of presence (PoPs), the policy model and failure behaviour decide the fit. This vendor-neutral buyer's guide is for architects, CISOs and procurement teams writing an RFP or replacing VPNs and on-premises proxies, and ends with a proof of concept you can run in four to eight weeks.
Key takeaways
- Decide the architecture before the shortlist. Single-vendor SASE, SSE plus your existing SD-WAN, and SSE only for remote users are different purchases with different exit costs.
- Test latency from where your users really are. PoP counts on a map mean little; measure application response times from your offices and home users in the proof of concept.
- Inspection capacity and exemptions decide security value. A platform that cannot decrypt at your volume, or forces broad bypass lists, leaves most web and SaaS traffic unseen.
- Identity and device posture are the policy inputs. Decisions are only as good as the IdP integration and the device signals the platform re-checks during a session.
- The provider becomes part of your control plane. Score its outage history, fail-open and fail-closed options, administrator security and log export as hard as its features.
Define requirements
NIST SP 800-215, citing the analyst firm that coined the term, describes SASE as an architecture that "converges networking and security functions" and lists a minimum service set of firewall, SWG, anti-malware, IPS, CASB and DLP, with browser isolation as an advanced service (NIST SP 800-215, section 6). Use that list as a floor, then define:
- What you are retiring: VPN concentrators, on-premises proxies, branch firewalls, MPLS circuits, standalone CASB, each with a contract end date that shapes the rollout order.
- Users and locations: headcount by country, branches and bandwidth, home workers, contractors on unmanaged devices, and countries where inspection raises legal questions.
- Traffic profile: share of SaaS, internet and private-application traffic; non-web protocols (SSH, RDP, SMB, VoIP); server-initiated flows that ZTNA agents may not handle.
- Policy outcomes: which SaaS tenants to restrict, what data must not leave, which applications need per-application access. CISA's TIC 3.0 calls the goal "Policy Enforcement Parity": "consistently applying security protections and other policies, independent of the communication mechanism" (CISA TIC 3.0 Remote User Use Case).
- Operating constraints: data residency for logs and decrypted content, required log retention, existing SIEM, and who will run the platform day to day.
| Model | Fits when | Trade-offs |
|---|---|---|
| Single-vendor SASE | Branch refresh is due; small network team; one console for network and security | Deepest lock-in; SD-WAN and security quality may not be equal; one provider outage affects both connectivity and inspection |
| Dual-vendor SASE (SSE plus separate SD-WAN) | Existing SD-WAN works and has years left on contract; strong network team; best-in-class preference per layer | Two consoles and support paths; SD-WAN to SSE tunnels must be tested; split incident responsibility |
| SSE only | Priority is remote users, SaaS control and VPN replacement; branches stay on current WAN and firewalls | Branch traffic still needs a path to the SSE (tunnels or agents); full SASE may follow later with a second migration |
A 300-person firm with no network team usually gains most from one platform; a multinational with mature SD-WAN often prefers dual-vendor. For contract schedules, the Mplify (formerly MEF) SASE service framework defines service attributes agreed "between a Service Provider and a Subscriber".
Evaluation criteria
Weight these to your requirements. An illustrative split for a VPN and proxy replacement: 25% components and inspection, 20% performance, 20% identity and policy, 15% resilience, 10% logging, 10% commercial terms.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Component completeness | SWG, CASB (inline and API modes), ZTNA, FWaaS, DLP, RBI and, for SASE, SD-WAN, all native and managed from one policy engine | Components from acquisitions with separate consoles, policy languages or agents; "roadmap" items in the RFP response |
| PoP coverage and performance | PoPs that perform full inspection in or near your user countries; published PoP list with which services each PoP runs; measured latency in the PoC | "Virtual" PoPs that backhaul to a distant inspection site; no per-PoP service list |
| Traffic steering | Endpoint agent, PAC file and explicit proxy, IPsec and GRE tunnels from branches, and agentless browser access for unmanaged devices; clear handling of UDP and QUIC | Agent-only steering; no plan for IoT, servers or guest devices; QUIC silently bypassing inspection |
| TLS inspection capacity and exemptions | Decryption at your peak volume without throttling; category-based exemptions (health, finance); pinned-application handling; customer-managed root certificate option | Large default bypass lists; inspection limited by licence tier; no report on what share of traffic was decrypted |
| Data protection | One DLP policy across web, SaaS (inline and API) and private apps; exact data match and fingerprinting; evidence stored in your chosen region | Separate DLP engines per channel; evidence stored in an unspecified country |
| Policy model | A single rule base using user, group, device posture, application, location and risk; policy-as-code or API; staged changes with audit trail and rollback | Separate rules per module; changes take effect globally with no staging |
| Logging and SIEM export | Full transaction, ZTNA session, DLP and admin logs streamed to your SIEM in near real time; documented schema; no extra fee for export | Export limited to summaries or daily batches; retention only inside the vendor console |
| Resilience | Published status history and post-incident reports; per-policy fail-open or fail-closed choice; automatic PoP failover; documented behaviour if the control plane is unreachable | No public incident history; one global setting for failure mode; no answer on control-plane loss |
| Admin security | SSO with phishing-resistant MFA for admins, granular admin roles, change approval, tenant audit log, scoped and expiring API tokens | Local admin accounts that bypass SSO; API keys with full tenant rights and no expiry |
| Commercial terms | Clear licence metric (users, bandwidth or sites), included inspection and log volume, exit assistance and data deletion terms | Core features (DLP, RBI, log streaming) sold as add-ons that double the quoted price |
Where identity fits
SASE policy consumes users and groups from your identity provider (SAML or OpenID Connect, SCIM for provisioning) and device signals from endpoint management or EDR. NIST's zero trust architecture expects the enterprise to evaluate "the security posture of the asset when evaluating a resource request" (NIST SP 800-207, tenet 5), and SP 800-215 describes ZTNA access that is "continuously reevaluated during the user session". The NCSC puts it plainly: "Each request to access data or a service should be authenticated and authorised against an access policy." Score whether posture is re-checked during the session, whether an IdP risk signal can end a live session, and how service accounts and workloads without a human user are handled. The platform's own API tokens and connector credentials (for CASB API scanning, log streaming and IdP sync) are privileged non-human identities and need owners, scopes and rotation. See the ZTNA Guide, the Device Trust and Posture Guide and the Conditional Access Guide.
Questions to ask vendors
- Which of your PoPs in our user countries run full inspection (TLS decryption, DLP, sandboxing), and which only forward traffic elsewhere? Show the list, not a map.
- What is your decryption capacity per tenant and per PoP, what happens when we exceed it, and which applications are on your default bypass list?
- Can a single rule combine user, group, device posture, application and data classification across SWG, CASB, ZTNA and FWaaS? Show the same rule enforced in two modules.
- Which device posture signals do you consume natively, how often are they re-evaluated, and what happens to an active session when posture fails?
- List your service incidents of the last 24 months with duration and root cause. What happens to user traffic if your control plane is unreachable, and can we choose fail-open or fail-closed per application?
- Which logs can we stream to our SIEM, in what format and delay, and at what cost? How long do you retain logs and decrypted content, and where?
- How is your staff's access to our tenant and data controlled, logged and disclosed to us?
- What does the licence count, which features are add-ons, and what are the exit terms, including configuration export?
Red flags
- A PoP map that does not show which sites inspect and which only relay.
- Recommendations to bypass inspection for large SaaS suites "for performance", with no data on the resulting blind spot. See the TLS Inspection Guide.
- A single global fail-open switch as the only answer to outages.
- Log export that costs extra, arrives in daily batches or omits admin and policy change events.
- A migration plan that keeps the old VPN running indefinitely "as a fallback", with its accounts and exposed gateways still live.
Proof of concept
- Scope and baseline: pick three user groups (head office, a remote region, contractors on unmanaged devices), one branch, five SaaS tenants and three private applications, one of them non-web. Record current application response times first.
- Measure performance from real locations: run the same synthetic tests through each candidate from every PoC location at busy and quiet hours. Compare median and 95th percentile latency and note which PoP each user lands on. NIST notes VPN hair-pinning "increases network latency"; a SASE that hair-pins to a distant PoP has the same problem.
- Test steering methods: agent on managed laptops, PAC file or explicit proxy for a kiosk, IPsec tunnel from the branch, browser-based access for an unmanaged contractor. Confirm QUIC is either inspected or forced to TCP. Check PAC files for a trailing
DIRECT: browsers fall through to the next entry when a proxy fails and retry it after 30 minutes (MDN), a silent fail-open. - Test inspection and DLP: decrypt at a realistic volume, confirm pinned applications fail safely, apply category exemptions for health and banking sites, then try to upload a test file of fingerprinted data to a personal cloud drive and a sanctioned tenant. See the Data Loss Prevention (DLP) Guide.
- Test identity and posture: disable a user in the IdP, mark a device non-compliant, and raise a user risk signal. Time how long each takes to cut an active ZTNA and web session.
- Test resilience: block the agent from reaching its nearest PoP, then simulate loss of the control plane. Record whether traffic fails over, fails open or fails closed, and whether the result matches your chosen policy for each application.
- Test logging and admin security: stream logs to your SIEM, then make a policy change and confirm the admin event, user transactions and DLP incidents arrive with consistent user and device identifiers. CISA's TIC 3.0 guidance asks agencies to "seek integration of CSP telemetry into centralized situational awareness tools"; treat your SASE provider the same way. Review admin roles and API token scopes. See the SIEM Guide.
- Plan the VPN exit and roll back: migrate one pilot group, keep a documented rollback to the VPN for that group only, then disable their VPN access. Exposed gateways and dormant VPN accounts are a recurring breach route, as the Colonial Pipeline attack and the Ivanti Connect Secure exploitation showed. See the VPN Security Guide.
Keep measuring after go-live: share of traffic decrypted, share of users steered through the platform, 95th percentile latency by region, time to revoke access after an IdP disable, active inspection exemptions, and remaining VPN accounts.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: ZTNA Guide · Device Trust and Posture Guide · Enterprise Browser and Browser Security Guide · Zero Trust Identity Guide