So you've been tasked with scoping a ZPA pilot. Welcome to the wonderful world of vendor acronyms and the inevitable realization that "zero trust" is less about security and more about re-architecting your entire network access philosophy on the fly. How fun.
Let's be brutally honest: most pilots fail because they're scoped like a simple feature test. You throw it on a few servers and a handful of users and call it a day. With ZPA, that's a fantastic way to get a "successful" pilot that collapses the moment you try to scale. The devil isn't just in the details; he's holding the blueprint hostage.
First, abandon the notion that this is just a VPN replacement. If you scope it that way, you'll miss the entire point and end up with a glorified, overpriced tunnel. The real scoping begins with a deeply unsexy, politically fraught internal audit. You need to map, and I mean *really* map, your applications. Not just the official ones in the CMDB (which is probably 40% accurate on a good day), but the shadow IT, the legacy junk on forgotten IPs, the SaaS apps with ten different integration points. ZPA’s value—or its terrifying complexity—comes from defining your "app segments" and "connectors." Get this wrong and your pilot will be a festival of access denials and help desk tickets.
Here's my sardonic, contrarian starter pack for you:
Forget the sales engineer's happy-path demo. Your pilot scope must intentionally include the ugly. Pick at least one of each: a crusty on-premise legacy app (think AS/400, or some ancient Oracle database), a modern cloud-native microservice mess, and a SaaS app you need to lock down to specific identities. This will force you to confront the real configuration hell of provisioning, identity integration, and policy granularity. Also, deliberately include a subset of "problem" users—the road warriors, the contractors with weird devices, the developers who need CLI access. If it works for them, it might work for anyone.
And for the love of all that is holy, build your success criteria around operational pain, not just uptime. Measure the time it takes your team to onboard a *new* app segment after the initial setup. Track the performance quirks versus the old VPN. Most importantly, run a parallel cost analysis that includes the hidden labor of your network and security teams re-skilling, because ZPA shifts management burden in ways the sales deck never quite illustrates. If you don't, you'll pilot your way right into a shocking true-up and a team that hates you.
The goal isn't to prove it works in a lab. It's to prove your organization can stomach the operational model shift without regurgitating it in six months. Happy scoping. You'll need it.
—Bella
Price ≠ value.
You're 100% right about the application mapping being the unsexy, brutal foundation. I've seen teams burn weeks because they trusted the CMDB, only to find half their critical financial reporting tools were living on some dev's personal Azure tenant that wasn't documented anywhere.
That "shadow IT, the legacy junk on forgotten IPs" bit is so real. It's not just about finding them, though, it's about the political nightmare of actually getting them categorized and owned. You'll have department heads suddenly claiming that random, unpatched app is "business critical" when you flag it for retirement, just to avoid the work of migrating. That conversation, not the tech, often becomes the true scope of the pilot.
My caveat would be to also map the *users* alongside the apps, but in terms of business roles, not just AD groups. Who actually *needs* the legacy junk? Often you'll find you can shrink the attack surface dramatically before you even touch ZPA policy, just by cleaning up access no one actually uses.
don't spam bro
Absolutely. Mapping applications is the critical first step, but the methodology matters. Using automated discovery tools alongside manual interviews often reveals dependencies the CMDB misses, like an application's reliance on a specific backend database service that isn't considered an "app" itself. This creates an incomplete app segment.
I'd add that you should classify the discovered applications by their *update frequency* and *authentication method*. A legacy app with static IPs and no modern auth protocol will require a completely different connector and policy approach than a cloud-native SaaS application. This technical categorization directly impacts your pilot scope, as you'll need to validate ZPA's performance across these distinct archetypes.
prove it with data
That "deeply unsexy, politically fraught internal audit" part really hits home. I'm coming from a data background, so my instinct is to just query the CMDB database and call it a day. The idea that it's not a data quality problem but a political one is... daunting, to be honest.
You mention mapping *all* the applications. Is there a process you'd recommend for just getting started with that discovery without immediately getting bogged down in departmental arguments? Like, do you build the initial list first and then go get it validated, or do you involve the stakeholders from day one?
The authentication method point is gold. We had a legacy timekeeping app that only spoke LDAP, no SAML in sight. ZPA handled it, but the policy setup felt like trying to teach your grandpa to use a smartphone. It worked, but nobody was happy.
That update frequency angle is also critical for picking pilot apps. Don't start with the quarterly-updated, bespoke monster. Pick something updated weekly or monthly. You'll actually see if your connector automation and policy updates hold, instead of just getting a false sense of security from a static test. If it can't handle a simple patch cycle, it won't handle your real workload.
That point about mapping *everything* really resonates. Coming from a support tools background, I've seen how incomplete catalogs break new processes.
I'm curious, when you say it's not a VPN replacement, is part of the scoping about defining the new user experience? You're moving from a simple "on/off" tunnel to this app-by-app access model. If you don't scope for that change management, even a perfect technical pilot will get rejected by users who just find it confusing.
Oh, absolutely it is. You've nailed the hidden pilot-killer. The user experience shift from a dumb tunnel to an app catalog is massive, and if you don't scope for that training and feedback loop, you'll win the technical battle but lose the war.
We scoped a "change champion" program into our pilot budget - basically bribing a few key users in each department with extra support and swag to be the first to test it. Their feedback on the connector install, the browser experience, and just plain confusion like "why can't I see the file server anymore?" was more valuable than any of our monitoring graphs. It showed us where our policies were too restrictive and where we needed better, simpler documentation.
Forget the VPN comparison in your training materials. Frame it as a "personalized access list" or you'll spend the whole pilot hearing, "But with the VPN I just clicked connect!"