Let's dispense with the hopeful premise in your title. The short answer is no, you cannot evaluate or use Netskope's ZTNA without installing their client software. This is fundamental to how any real Zero Trust Network Access works.
The "without installing anything" dream usually leads you to legacy VPNs or clunky bastion hosts, which is what ZTNA aims to replace. Netskope's model, like its competitors (Zscaler, CrowdStrike), requires an agent—the Netskope Client. This client is the entity that:
* Authenticates the user and device against your IdP.
* Establishes the secure, app-specific tunnel to the Netskope POP.
* Enforces continuous posture checks (e.g., disk encryption status, OS version).
You can, however, test the *admin experience* without widespread deployment. The typical path is:
1. Deploy the client to a small pilot group (maybe just your own machine).
2. Configure a test application in the Netskope tenant with a permissive policy.
3. Validate the access flow and inspect logs.
A bare-bones, illustrative policy for a test web app might look like this in their UI (paraphrased, not actual API JSON):
```json
{
"rule_name": "Test_WebApp_Allow",
"subjects": [{"type": "user_group", "value": "pilot_users"}],
"resources": [{"type": "host", "value": "testapp.internal.example.com"}],
"actions": ["allow"],
"conditions": [{"type": "client_version", "op": "gte", "value": "101"}]
}
```
The point is, you're testing policy creation, not agent-less access. If your requirement is truly "no software on endpoints," you're shopping in the wrong category. You'd be looking at reverse proxy solutions cloudflare tunnels or something, which come with their own set of trade-offs (no device posture, different traffic routing).
So, get the client. Deploy it to a few test machines. That's the only way to see if their implementation of ZTNA meets your benchmarks for latency, user experience, and admin overhead. Anything else is just reading the brochure.
- cr
Your fancy demo doesn't scale.
Agreed. That pilot group deployment is the right starting point. Key metric to watch during the test is the connection establishment latency from the client to the Netskope POP. You'll see it in the client logs. If that spikes under load, it negates the user experience benefit over a legacy VPN.
The policy example is good, but I'd stress testing the 'deny' scenarios first. Set up a policy for your test app that blocks based on a failed posture check, like an out-of-date OS. Verify the logs show the correct block reason. That's the enforcement piece you're actually buying.
Data over opinions
Right, and the "test the admin experience" point is key. I'd take that a step further and say you can also test a surprising amount of the *observability* piece before any user gets the client.
While you wait for that pilot group to sign off, you can set up a dashboard in Grafana pulling from the Netskope tenant's API or syslog feeds. You can template it for the metrics you'll care about:
- Client version distribution (you'll get fragmentation)
- Connection success/fail rate by POP
- Latency percentiles for policy evaluation
That way, when the first pilot user connects, you're already watching the right signals instead of scrambling to build views. You can see a latency spike or an auth error in real time, not from a support ticket.
Sleep is for the weak
Oh that's a smart idea about setting up the dashboard in advance. I'd never have thought to prep the monitoring side before anyone was even using it.
Is the Grafana setup you mentioned pretty straightforward, or does it require a lot of custom work to pull from the Netskope API? I'm picturing our team trying to do that and maybe getting stuck for a while.
It can be straightforward if your team is already ingesting logs into a Grafana stack, but that's a big if. The Netskope API itself isn't the complicated part, it's pretty standard REST. The custom work is in building and maintaining the data connector, parsing the JSON, and mapping it to useful dashboard variables.
Most teams I've seen get stuck because they underestimate the operational toil of yet another custom integration. If you're not already doing this for other SaaS tools, you'll spend more time babysitting the data pipeline than actually looking at the dashboards. Might be better off just using the built-in reporting until you prove the product's value.
Just my 2 cents