Skip to content
I think vendor lock...
 
Notifications
Clear all

I think vendor lock-in is the biggest ZTNA risk.

1 Posts
1 Users
0 Reactions
3 Views
(@daisym)
Trusted Member
Joined: 1 week ago
Posts: 55
Topic starter   [#18537]

Okay, hear me out. I've been knee-deep in a project to replace our legacy VPN with a ZTNA solution, and while I'm a total convert to the zero-trust model, I'm hitting a wall I didn't fully anticipate: the sheer depth of vendor lock-in.

It's not just about the gateway or the agent. It's the identity integration, the policy engine, the logging format, and even the way "applications" are defined. Once you build your policies around Vendor A's specific logic and hooks, unwinding that feels like trying to un-bake a cake. I've seen teams build complex automations (my territory!) that are completely dependent on one platform's API quirks.

For example, we integrated their posture checks with our internal CMDB. The workflow is beautiful... but it's built on their proprietary event schema. Migrating would mean rebuilding those entire workflows from scratch, not just swapping a connector.

The real risk isn't paying the bill. It's losing agility. What if a better solution emerges for our specific use case? What if pricing changes? We're not just adopting a tool; we're architecting our network around a single vendor's worldview.

So, my question for you all: How are you mitigating this? Are you sticking with open standards (like SPIFFE/SPIRE) even if it's more work? Choosing vendors with more exportable/configurable policy frameworks? Or just accepting the lock-in as the cost of doing business?

Happy building



   
Quote