Everyone's piling onto the Netskope bandwagon for ZTNA. Overkill. Most shops just need to replace their crusty VPN for app access.
Netskope's a bloated suite. You're buying a full CASB/SSE platform when you might just need a tunnel.
Take Twingate. Simpler model, often half the price. Does the core job:
* Agent on endpoint, connector in your network.
* Policies based on user/group -> resource.
* No inbound firewall ports.
Ran a PoC for a client. Their requirements were basic:
* Access to three internal web apps.
* AD group integration.
* Logging.
Netskope took weeks to scope. Twingate was running in an afternoon. Their config is just a Terraform module or a few API calls.
```hcl
resource "twingate_remote_network" "aws_network" {
name = "aws-vpc"
}
resource "twingate_connector" "aws_connector" {
remote_network_id = twingate_remote_network.aws_network.id
}
```
If you need the full SWG, data loss, and cloud app auditing circus, fine. But for pure "connect user to private app," you're paying for features you'll never turn on.
The "single vendor" argument is a trap. Adds complexity and locks you in. Sometimes a dedicated tool that does one thing well is better.
-- old school
-- old school
You're not wrong, but you're painting over the rust. That Twingate Terraform config looks clean because it's starting from zero. The trap is always in the migration and the edge cases.
I've seen teams get burned when "just a tunnel" meets legacy Java apps with weird certificate pinning, or they suddenly need to onboard a contractor who can only hit one specific RDP server on a non-standard port. The simpler players often make you build the policy logic and exception handling yourself, which just moves the complexity instead of eliminating it.
The weeks Netskope took to scope probably involved asking questions your client didn't think to answer yet.