So Zscaler announces ‘ZPA Inside’ for OEMs and we’re all supposed to nod along at the innovation. Forgive my skepticism, but this just looks like a masterclass in vendor lock-in repackaged as a partnership program.
The premise is simple enough: embed their zero-trust access into other vendors' hardware or software solutions. But let's follow the money. This isn't about expanding choice; it's about making ZPA the unavoidable, embedded cost in someone else's bill of materials. The OEM customer now gets a bundled solution where the networking and access costs are opaque, buried in the OEM's markup, and almost certainly harder to audit or optimize. Try peeling that apart to run your own cost analysis. I’d bet my last reserved instance that the per-unit or per-connection economics are deliberately obfuscated.
Where’s the data showing this reduces total cost versus a best-of-breed, disaggregated approach? I haven't seen a single TCO breakdown that factors in the long-term rigidity this creates. Once you’re wired in, good luck negotiating those ZPA licenses down or switching components. It’s the same old playbook: convenience today for a 30% premium and zero flexibility tomorrow.
I’ll ask the uncomfortable question: has anyone actually seen the billing implications of an embedded model like this in their own environment? Or are we just taking marketing’s word for it that it’s “cost-effective”?
- cost_observer_42
cost_observer_42
Totally agree on the cost opacity angle. We did a POC with a different embedded networking stack last year and it was a nightmare to forecast. The OEM gave us one "all-in" number, but our finance team couldn't map it to any unit (per-user, per-gigabyte, per-connection) for our long-term models. That lack of granularity makes budget forecasting a guessing game.
You're right, the negotiation leverage vanishes. Once it's baked into the hardware or solution, you're not just buying ZPA, you're buying the whole package. Good luck trying to get a discount on just the access piece in year three when you want to scale up.
I'd love to see a TCO comparison that includes the cost of *exiting* this kind of setup. The migration tax to a disaggregated model later could wipe out any initial convenience savings.
Right-size everything
Your point about the missing TCO breakdown is critical. We ran a three-year projection on a similar embedded security model from another vendor, and the lack of unit economics made it impossible to model against our actual growth. The OEM's "all-in" price became a fixed cost, while our user base and data transfer volume grew 4x. The effective cost per user plummeted for the OEM, but our bill didn't change.
The real lock-in isn't just the licensing; it's the operational data. When the service is abstracted inside an OEM solution, you lose the granular logs and metrics you'd get from a direct ZPA subscription. You can't optimize what you can't measure. Trying to prove the vendor's margins or your own inefficiencies becomes a forensic exercise.
I'd need to see a side-by-side benchmark, with full methodology, comparing the three-year cost of ZPA Inside through an OEM versus a direct integration. It would have to factor in the cost of later migration, which you rightly called a tax. Until that data exists, skepticism is the only rational position.
Yeah, that's a solid point about the cost analysis. When you can't see the per-unit breakdown, how can you even start to optimize?
It reminds me of trying to track cloud spend without good tagging. You get one big bill and no way to see which team or project caused the spike. If the OEM bundles it all, you lose that visibility completely.
Has anyone seen if these bundled solutions still give you the raw metrics? Like, can you pipe ZPA logs into your own Prometheus stack, or are you stuck with whatever dashboard the OEM gives you?