Okay, I'm going to throw a grenade into the room here, but hear me out. This comes from wrangling remote users and contractor access across three major migration projects.
We've spent decades installing clients, managing versions, fighting with local firewall conflicts, and troubleshooting OS-specific quirks. It's a huge tax on IT and a friction point for users. The promise of SASE/SSE is seamless, identity-centric security *wherever the user is*. So why are we still pushing a fat client as the primary gatekeeper?
The modern stack—a secure browser with embedded micro-tunnels, clientless VPN for specific apps, and inline CASB via reverse proxy—gets you 95% of the way there for most users. It's instantly updated, has zero local attack surface, and works on any device, managed or BYOD. The heavy lifting moves to the cloud edge and the browser becomes the universal, secure workspace.
I see the client model hanging on for:
* Legacy L3 VPN needs for very specific on-prem systems.
* Performance-intensive data transfer workflows (think big data ETL jobs).
* Deep endpoint posture checks that a browser can't provide.
But for Jane in Accounting logging in from her iPad, or Devin the contractor needing Salesforce and a few internal web apps? Agentless is cleaner, faster to deploy, and reduces support tickets.
My hot take: The future is browser-centric, with the "client" becoming an optional, on-demand component for edge cases, not the default.
What's everyone seeing in the field? Are you still rolling out clients to everyone, or moving to a tiered model?
- Kev
You're not wrong about the friction, but moving everything to the browser just swaps one gatekeeper for another. Now your entire security model hinges on the user's browser instance, the cloud provider's edge network, and the assumption that every app can be neatly reverse-proxied.
That "zero local attack surface" claim is a bit rosy. You've just shifted the attack surface to the browser's runtime and the millions of lines of JS in that "secure workspace." And good luck debugging network issues when the micro-tunnels fail. You'll be staring at DevTools console while Jane in Accounting can't print.
The client model persists because it grants deterministic control, even if it's messy. Handing that off to a browser feels like outsourcing the problem to a different, more opaque vendor stack.
null
You've nailed the core frustration - the client lifecycle tax is real, and it's a massive, hidden line item on the IT budget. Everyone focuses on the per-seat license cost for the SSE vendor, but the hours burned on packaging, GPO deployments, version-compatibility tickets, and offboarding cleanup? That's where the real bloodletting happens.
I'd add one more critical point to your 95% use case: *clientless is a dream for temporary/contractor access*. Spinning up a secure browser session for a third-party dev or a merger team for six months, then burning it down with zero local residue, is a security and admin win you can't put a price on. Well, you can, because I have scripts that compare it to the support tickets from their corrupted client profiles.
But I'll push back on the "zero local attack surface" bit, echoing the next reply. You're trading a known, manageable attack surface (a vendor client you can lock down) for a sprawling, constantly shifting one (the browser's rendering engine and its extensions). It's not about which is safer, it's about which set of vulnerabilities you're paid to understand. For most orgs, managing browser risk is already a full-time job.
Totally feel that contractor use case. We just onboarded a bunch of freelancers for a project, and the idea of pushing a client to their personal laptops was a non-starter from a privacy standpoint. The browser session was a lifesaver.
But you hit on my big worry too: swapping one managed surface for another, less predictable one. We already have a nightmare keeping Chrome/Edge secure and extension-approved. Adding critical network tunnels into that same runtime makes me nervous. Like, is my security team now also on the hook for every Chromium zero-day? Feels like the risk profile changes but the workload might not actually go down.
Where do you land on that? Is it just accepting a different kind of fire drill?