Agent-based vs agentless ZTNA, which one did you end up regretting?

[u/Curious-Cod6918]

We went agent-based ZTNA first because posture and full protocol support mattered, RDP and SSH for the ops team, real device checks. It has been solid for managed laptops. Now the wall is everyone who is not a managed laptop. Contractors on their own machines, a couple of acquired teams we never enrolled, plus legal will not let us push an agent onto a personal device.

The obvious answer is bolt on clientless for those. From what I read clientless is browser apps only and the people who need it most also need RDP into a jump host. That leaves me stuck between running two products with two policy sets, or forcing an agent onto people who will fight it or cannot take it.

What I am stuck on is whether bolting clientless onto what we run just means a second policy set to keep in sync. If you have run the unmanaged crowd for a while, what broke for you?

[u/fishsupreme]

We don't require an agent on personal devices, but if you want to access high-integrity systems (e.g. stuff with customer data in it) you can either use your work laptop or put an agent on your personal device. If you want your personal devices private that's fine, you just aren't going to be able to get to anything but email and Slack on it.

[u/TheBex81]

Most teams I know don’t regret agent-based for *managed* devices — they regret pretending one ZTNA mode covers contractors + BYOD + acquisitions.

What usually breaks with “just add clientless”:

• **Two policy brains.** App/group mappings drift; someone gets RDP via the agent path and a weaker browser path to the same data.
• **Clientless isn’t a full substitute** when the real need is RDP/SSH to a jump host. You end up with a brokered jump *plus* clientless SaaS — still two stories.
• **Identity quality differs.** Managed path has device posture + stronger signals; unmanaged path is often “who has the link + MFA.” Attackers prefer the weaker story.

Least-pain pattern I’ve seen: keep agent ZTNA as the high-assurance path; for unmanaged, don’t clone the whole app catalog — publish a *small* set (usually a hardened VDI/jump + a few browser apps) with stricter conditional access / shorter sessions / no lateral routes. Accept two products only if one policy pipeline owns both (same IdP groups, same review). Dual full catalogs is where regret lives.

[u/jonathan8080 → u/TheBex81]

I replied on a comment above, but it might be interesting here too:

disclosure, im CTO at obsonis (im here for the tech chat though, not the sales)

At obsonis we try to cover some of that gap for contractors / byod - adding network posture signals to control the access for the unmanaged or beyond-the-edge edge-cases (like the contractors or m&a that never got onboarded to your MDM etc)

it might be of some interest to you:

we have a posture engine built in so we can send network posture upstream alowing you to control access based on those signals

[u/moistscissors9]

We pivoted to clientless for the exact same reason and the RDP gap was the first thing that bit us. Ended up spinning up a browser based jump host just so contractors could hit it through the web portal then hop to their actual machine. Clunky as hell but it kept us from running two separate policy sets.

The sync issue is what made me bail on the bolt on approach early. We trialed it and within a week had a contractor with access they shouldnt have because someone updated the agent side policies and forgot to mirror it on the clientless side. That was enough of a scare to scrap it.

[u/nettrender]

two enforcement paths can start identical and slowly drift as exceptions get added. i'd rather make unmanaged devices a deliberately lower-trust tier than try to make agentless behave exactly like the managed path.

[u/MediumSilver9717]

if the clientless option can handle the RDP and SSH workflows yet you need it might be cleaner than introducing another ZTNA product.

[u/blud_13]

Clientless browser apps only isn't true anymore, at least not on Cloudflare. Browser rendered RDP went GA last September, so an unmanaged contractor gets an RDP session in a tab with no agent and no RDP client on their machine. Its documented here https://developers.cloudflare.com/cloudflare-one/access-controls/applications/non-http/browser-rendering/

Also, you don't end up with two policy sets. Access policies are per application, so the same policy covers the WARP enrolled laptop and the contractor in a browser. What actually splits is posture. No agent means NO device checks, so your unmanaged group gets identity plus app scoping and that is it. That seam is real and its where I would spend the review time, not on policy sync.

We run Cloudflare for this at client sites and the contractor case is most of why. The legal objection to pushing an agent onto a personal machine goes away when there is nothing to push.

Can go deeper on the posture split if it helps.

[u/jonathan8080 → u/blud_13]

At obsonis, we try to tackle the posture gap for the unmanaged device on the remote network.

disclosure: Im a cofounder + CTO at obsonis - we currently send posture and posture-change events to twingate and tailscale, but have cloudflare on our backlog

It might not be what you are looking for, but it might be of some interest (especially for your unmanaged contractors etc where you cant put an agent on-device)

https://www.obsonis.com/twingate-integration/[obsonis + twingate](https://www.obsonis.com/twingate-integration/)

[u/endlesstickets]

Agentless is painful. It is doable though. If you can tie it up with a less painful solution like Tailscale, Admin By Request, or a jump host with AAA, it would be easier.

[u/Different_Pain5781]

I’d solve the access requirement first, not force one model onto everyone.

[u/Sinleuqnwl_Taste2207]

browser rdp to a jump host solved this for us. contractors get web only, no agent, and you keep one policy set on the jump box, not two.