I've been evaluating Netskope's ZTNA offering as part of a broader SASE architecture refresh for a manufacturing client. The primary use case involves providing secure, granular access to on-premise MQTT brokers and historian databases (like OSIsoft PI) for a fleet of heterogeneous industrial IoT devices (PLCs, sensors, HMIs). While the general ZTNA proposition for user-to-application traffic is well-documented, the applicability for machine-to-application (M2A) or device-to-application scenarios remains conspicuously under-specified in their published materials.
My core concern revolves around the agent requirement. The vast majority of our IoT assets are "unmanaged" in the traditional IT sense—they run proprietary or stripped-down OSes where installing the Netskope Client is fundamentally impossible. The documentation alludes to "clientless" access, but this appears heavily oriented towards web applications via browser. For industrial protocols that operate on TCP (or even UDP in some cases), the architecture is unclear. I have several specific questions the community might have explored:
* **Protocol Support:** Has anyone successfully configured Netskope ZTNA to proxy or gate non-HTTP/S protocols like MQTT (port 1883/8883), OPC UA (port 4840), or even raw SQL for database historians? Or is the expectation to encapsulate everything in TLS tunnels, effectively treating the device as a "user"?
* **Authentication Mechanisms:** For devices, certificate-based authentication is the norm. Does Netskope's Private Access (their ZTNA product) cleanly integrate with a private PKI for device identity, moving beyond user-centric IdP integrations like Okta? We need to authenticate the *device* first, then potentially apply application-level credentials.
* **Scalability and Session Handling:** IoT devices maintain persistent, long-lived connections. How does the service handle thousands of simultaneous, persistent TCP sessions from a single gateway? Are there observed limitations in their cloud edge nodes compared to a dedicated on-prem ZTNA appliance from a competitor?
* **Observability & Logging:** Can we extract detailed connection logs (source device, target application, protocol, bytes transferred) that are essential for operational troubleshooting and security audits? The console screenshots typically show user-centric activity.
A basic conceptual configuration I'm trying to validate would look like this, but I'm uncertain if the components support it:
```
Device (PLC with Client Certificate) --> Netskope POP (with TLS inspection?) --> Private Access Gateway (logical) --> On-prem MQTT Broker
```
The alternative, of course, is deploying a lightweight forwarder or "edge connector" on a local server, which then becomes a single point of failure and adds complexity. I am seeking concrete implementation experiences, performance benchmarks in similar scenarios, or explicit confirmation of limitations. The cost model for high-volume, persistent device connections is another opaque area.
Data over dogma
Yeah, that client requirement is the killer for OT environments, isn't it? I ran into a similar wall a couple years back trying to get a different ZTNA vendor to work with some legacy SCADA gear. The "clientless" option almost always means HTTP/S and sometimes a few specific TCP ports, but good luck with MQTT or proprietary industrial protocols.
My gut says you're going to be forced into a network-level tunnel or gateway model for those unmanaged devices. Something like a lightweight connector deployed on a secure, locked-down host within the OT network that can broker the connections outbound, so the devices themselves don't need an agent. It adds a hop, but it's often the only way. Have you asked their sales engineers directly about a connector/gateway deployment pattern? Sometimes the docs are vague because the fit just isn't there.
it worked on my machine
Great point about the clientless option being mostly for web traffic, that's exactly what I found. I got pulled into a similar evaluation for a water treatment plant last year. We had some success using their "Private Application" model, but it required setting up a lightweight connector VM inside the OT network acting as a protocol-aware proxy.
So for your MQTT broker access, the connector essentially establishes the ZTNA tunnel outbound and then listens locally. Your PLCs talk MQTT to the connector's local IP, and it handles the secure leg to the broker. It's an extra piece to manage and secure, but it does work. Granularity gets tricky, though, you're often controlling access at the connector level, not per individual sensor.
Have you looked at how they handle the tunnel authentication for that connector? In our case, it used a certificate, which was okay, but the rotation process felt like an afterthought for OT where you can't just bounce things whenever.
Happy testing!