# 14. Zero Trust, SASE, SSE

Let's tackle the most over-marketed, least-understood architecture shift in modern security, and the one where vendor salesmanship has done the most damage to actual outcomes.

Context: A few definitions worth pinning down before the sales pitch arrives:

• Zero Trust, a philosophy and architecture principle, not a product. Core premise: stop assuming anything inside your network is trustworthy by default. Verify identity explicitly, use least-privilege access, assume breach. You cannot buy Zero Trust. You can buy tools that help implement it.
• SASE (Secure Access Service Edge), Gartner's 2019 convergence concept: SD-WAN (networking) + security services (SWG, CASB, ZTNA, FWaaS) delivered from the cloud as a unified platform. Meant to replace the hub-and-spoke network model that breaks when users, apps, and data leave the building.
• SSE (Security Service Edge), the security-only half of SASE (without the SD-WAN networking layer). Covers SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), and ZTNA (Zero Trust Network Access). Vendors: Zscaler, Netskope, Skyhigh, Cloudflare.
• ZTNA (Zero Trust Network Access), replaces VPN. Grants access to specific applications rather than putting users on the network. One component of Zero Trust, not the whole thing.

The market reality: "Zero Trust" has been applied to products that bear no relationship to the architecture philosophy. Endpoint tools, firewalls, PAM platforms, email gateways, every vendor has rebranded with "Zero Trust" in the last four years. Most are selling point solutions while implying you're buying a program.

SASE is genuinely useful as an architectural north star, but the reality is that most vendors are either networking-first (SD-WAN companies who bolted on security) or security-first (SSE vendors who bolted on networking), and neither side does the other half as well as specialists. The seam matters.

The core question for any ZT/SASE/SSE purchase: "What specific problem does this solve in my environment today, and what does my architecture look like after I buy it, not just during the sales cycle?"

14 Questions to Ask Zero Trust / SASE / SSE Vendors

1. "Define Zero Trust in the context of your product. What specifically does it do, and what parts of a Zero Trust architecture am I still responsible for after I buy you?"
Why: Zero Trust is a journey across identity, network, endpoint, application, and data. No vendor covers all of it. Force them to be precise about their slice and explicit about the gaps you own.
Good answer: A clear architecture map, "we cover network access control and cloud app visibility; you still need PAM for privileged access and EDR for endpoint." Red flag: "Our platform delivers Zero Trust across your environment."

2. "Are you selling me SSE, SASE, ZTNA, or something else? What does the product actually do vs. what's on your roadmap?"
Why: The acronyms are used interchangeably by vendors and mean different things. A ZTNA vendor is not a SASE vendor. An SSE vendor without SD-WAN is not a full SASE vendor. Force precision before you find out post-contract.
Good answer: Clear product taxonomy, honest roadmap vs. shipping features, no conflation of terms. Red flag: "We're a comprehensive SASE platform" with no specifics on what's native vs. integrated vs. aspirational.

3. "Are you networking-first or security-first, and how mature is the half you're not famous for?"
Why: Cato Networks, Versa, and VMware started as SD-WAN vendors and added security. Zscaler, Netskope, and Cloudflare started as security vendors and added networking. Both approaches have genuine strengths and genuine weak halves. Know what you're actually buying.
Good answer: Honest origin story, transparent capability delta between the two sides, references who use both sides. Red flag: "We've always been a unified platform."

4. "If I'm migrating from a VPN-centric architecture, what's the realistic path, timeline, and disruption profile?"
Why: ZTNA/SASE migrations are not quick. Legacy apps that only understand network-level access, OT environments, thick clients, development tooling, all of these complicate the story. Vendors demo greenfield; most enterprises aren't greenfield.
Good answer: A phased migration methodology, parallel-running period, reference customers who migrated from legacy environments. Red flag: "VPN migration is straightforward" with no methodology.

5. "How deeply do you integrate with my identity provider, Okta, Entra ID, Ping, and what happens when identity data is stale, wrong, or unavailable?"
Why: Zero Trust is identity-dependent. If your IdP has stale joiner/mover/leaver data, your access decisions will be wrong. If the IdP is down, your users may not be able to work. The failure mode matters as much as the happy path.
Good answer: Real-time sync with IdP, graceful degradation during outages, conditional access policy integration, documented break-glass process. Red flag: "We integrate with all major IdPs via SAML."

6. "How do you handle non-human identities, service accounts, machine-to-machine traffic, APIs, IoT, and OT devices?"
Why: ZT/SASE products are almost all designed for human users and managed devices. The non-human identity problem, service accounts, APIs, unmanaged devices, legacy OT, is where most implementations hit a wall.
Good answer: Honest discussion of non-human coverage and gaps, partner ecosystem for OT/IoT, API traffic inspection capabilities. Red flag: "Zero Trust applies to all traffic" without addressing non-human specifics.

7. "Walk me through your inspection capabilities, SWG, CASB, DLP. What traffic do you actually see, and what do you miss?"
Why: Traffic inspection is the core value proposition of SSE. But encrypted traffic at scale requires TLS inspection, which has performance, privacy, and compatibility implications. Pinned certificates, certificate errors, applications that break under inspection, all real problems.
Good answer: Specific inspection architecture, TLS interception methodology, what's excluded from inspection and why, performance data under load. Red flag: "We inspect all traffic at line rate."

8. "What's the user experience impact, latency, application compatibility, offline behavior, and the support burden when something breaks?"
Why: Zero Trust implementations fail most often because of user experience problems, not security failures. A 200ms latency increase on every web request, apps that break under TLS inspection, VDI environments that don't work with agents, these drive shadow IT and workarounds.
Good answer: Latency benchmarks from real customer environments, offline capabilities, application compatibility testing, helpdesk ticket volume in year one. Red flag: "Users won't notice the difference."

9. "How do you handle applications that can't be proxied, legacy apps, thick clients, OT systems, applications with certificate pinning?"
Why: No SSE or ZTNA platform handles 100% of application types cleanly. Legacy apps built on proprietary protocols, certificate-pinned mobile apps, OT control systems, all create exceptions that erode the Zero Trust model. How exceptions are handled matters.
Good answer: Honest capability limits, documented exception management, partner ecosystem for coverage gaps, risk acceptance workflows. Red flag: "We support all application types."

10. "What's your logging, visibility, and SIEM integration story? Does all traffic metadata flow into my tools, or is it locked in your platform?"
Why: You're putting significant traffic through a vendor platform. The logs, metadata, and behavioral analytics generated should be yours, portable, exportable, and available in your SIEM for correlation. Vendors who lock this in their own dashboards are creating a dependency.
Good answer: Full log export, SIEM connectors included, OCSF or common schema support, no additional charges for log access. Red flag: "Our platform provides the visibility you need" (your data, viewed through their lens only).

11. "How do you handle multi-cloud, hybrid cloud, and on-premises traffic, not just internet-bound access?"
Why: Early SASE was designed primarily for internet-bound traffic. East-west traffic between data centers, on-prem-to-cloud, and multi-cloud doesn't fit that model cleanly. Vendors have extended to cover it, with varying maturity.
Good answer: Specific architecture for private app access, cloud-to-cloud traffic, on-prem connector options, performance under non-internet traffic patterns. Red flag: Demos focused exclusively on internet-bound SaaS access.

12. "What's your resilience story, what happens if your PoPs (Points of Presence) have an outage?"
Why: SASE/SSE vendors route your traffic through their cloud infrastructure. When that infrastructure has a problem, and every cloud provider has problems, your users may not be able to work. Concentration risk applies here as much as anywhere.
Good answer: PoP redundancy, automatic failover, published SLA with financial consequences, post-incident reports from prior outages. Red flag: "We have 99.999% uptime" without a failover architecture discussion.

13. "When you're processing my traffic, what data do you see, retain, use, and share? And what's your own security posture, what's your blast radius if you're breached?"
Why: You're routing significant corporate traffic through a vendor. They see URLs, filenames, email metadata, application behavior, a comprehensive picture of your business. A breach of your SASE/SSE vendor is a significant event. Their security posture is your problem.
Good answer: Transparent data processing documentation, retention policies, no use of customer traffic for model training, own security attestations (SOC 2 Type II, ISO 27001), incident disclosure history. Red flag: "Your data is encrypted" with no further detail.

14. "Show me a real enterprise migration case study, legacy-heavy, not a greenfield startup, with the difficult parts included."
Why: Every SASE vendor has spectacular greenfield demos. The hard evidence is organizations that migrated from complex legacy environments, with legacy apps, OT systems, remote offices, non-Windows devices, and the inevitable complications. That story reveals maturity.
Good answer: Named (or sanitized with permission) reference, realistic timeline, complications encountered and how they were resolved, ongoing challenges. Red flag: All references are recent cloud-native companies.

The Meta-Test

• Q1 and Q2 are the precision test. A vendor who can't clearly define what they are and what you still own is selling a philosophy, not a product.
• Q6 and Q9 are the reality test. Non-human identities and non-proxiable apps are where Zero Trust architectures fracture in practice. These questions reveal whether the vendor has been deployed in complex environments or clean ones.
• Q13 is the trust test. You're handing them your traffic. Their security is your risk.

Honest Observations

1. "Zero Trust" is not a project with an end date, and vendors who imply otherwise are setting you up for disappointment.

Zero Trust is an ongoing architectural posture. There's no moment where you achieve it and move on. What vendors can sell you are components that move you toward it, ZTNA replaces VPN, CASB gives you visibility into SaaS, SWG controls internet access. But the program is organizational, not technological.

The trap: declaring "we're Zero Trust" after buying a ZTNA tool. You've replaced VPN access with app-specific access, that's meaningful, but it's one pillar. Identity governance, endpoint security, data classification, privileged access, lateral movement controls, all still matter.

2. SASE is the right direction for most organizations eventually, but the migration is harder than the pitch implies.

The architecture makes sense: put security where the users and data actually are (the cloud edge), not where they used to be (the corporate perimeter). For most organizations with distributed workforces and SaaS-heavy environments, this is the right direction.

But "right direction" and "easy transition" are different things. Most SASE migrations take 18-36 months in complex environments, not the 90-day cycles vendors imply. The complications are predictable: legacy apps, OT, certificate pinning, branch office networking, and the hardest one, getting users to accept the agent.

3. The networking vs. security split matters more than vendors admit.

If your primary problem is replacing VPN and getting visibility into SaaS usage, SSE-first vendors (Zscaler, Netskope, Cloudflare) are typically stronger. If your primary problem is SD-WAN modernization with security as a requirement, networking-first vendors (Cato, Versa, Fortinet) may fit better.

The "fully converged SASE platform" pitch almost always means one side is noticeably stronger than the other. Know which problem you're actually solving before you buy.

4. For "regular" mid-market companies, the practical sequence is usually:

1. ZTNA first, replace VPN for remote access. This is the highest-ROI, lowest-disruption starting point. Most organizations can do this in 60-90 days for well-understood application sets.
2. SWG/CASB, internet access control and SaaS visibility, especially if you're heavily SaaS-dependent with limited visibility into what employees are doing in cloud apps.
3. Full SASE/SSE convergence, once the fundamentals are stable and you have organizational adoption, consolidate into a platform. This is a 2-3 year horizon, not a first-year project.

Trying to do it all at once is how organizations end up with a half-deployed platform, user experience complaints, and a project that quietly stalls.

5. The most important Zero Trust investment isn't a network tool, it's identity.

Every Zero Trust framework agrees: identity is the control plane. If your IAM isn't mature (see Topic 6), your Zero Trust architecture has a fragile foundation. ZTNA tools that rely on weak identity signals are enforcing weak policies at machine speed.

Before buying any ZT/SASE tool, ask honestly: is our identity hygiene good enough to trust the signals we're using to make access decisions? If the answer is no, fix identity first.