After 8 years selling Zero Trust solutions, here's what I learned about what makes deployments succeed or fail. Hint: it's rarely the product.
I spent eight years selling Zero Trust solutions. I've seen large enterprise deals close with high expectations of transformation. Some delivered. Many didn't. The difference was rarely the product.
Zero Trust is an architecture philosophy. It's a set of principles: verify explicitly, assume breach, least privilege access. You can't buy principles. You can only buy tools that help you implement them, if you're ready to do the work.
The problem starts when vendors (and I've been guilty of this) position their product as the Zero Trust solution. ZPA gets you Zero Trust for applications. ZTNA gets you Zero Trust for networks. But you can deploy these tools and still not have Zero Trust.
I've seen organizations with full SASE stacks that still:
They bought Zero Trust. They don't have Zero Trust.
The organizations that succeeded didn't just buy a product. They went on a journey. And they didn't go alone.
The best outcomes I've seen happened when customers partnered with vendor teams, Solution Architects, Field CxOs, Senior SEs, to build something together. Not because we had all the answers. We didn't. We had no real visibility into their internal politics, their legacy debt, their capacity constraints. But we could help with the high-level design. We could think through the operating model. We could share patterns from other deployments.
Customers who engaged in that kind of strategic conversation, who built a transformation roadmap instead of just a deployment plan, were the ones who could carry the work forward internally.
The customers who expected the product to do the transformation for them, struggled.
Something that surprised me was that successful Zero Trust deployments often didn't start with individual user access decisions.
For most of our ZPA projects, we looked at groups, not individuals. What does this team need access to? What does this department require? You can't realistically define policies for thousands of individual users. You define them for roles, for functions, for business units.
The granular, per-user policies? Those were reserved for crown jewels, the systems where you genuinely need to know exactly who touches what. For everything else, group-based policies were the only way to scale.
This seems obvious in hindsight, but I've seen plenty of projects stall because someone insisted on defining individual access for everyone. That's not Zero Trust. That's a spreadsheet that will never be finished.
This is the single most impactful thing you can do, and it can happen fast.
A user who needs access to five cloud apps, two SaaS platforms and a legacy application does not need an IP address in your corporate network. They don't need a VPN tunnel. They don't need to be "inside."
With a Zero Trust approach, an authenticated user connects to a broker that gives them access to a defined set of applications. No network access. No lateral movement. No attack surface.
I've seen this reduce external exposure within days. No more reverse proxies. No more VPN gateways. No more enterprise applications exposed to the internet. The user authenticates, gets access to their apps, and that's it. During a learning phase you can start broad and tighten over time. But even on day one, the user has no IP in your network.
That's not a theoretical benefit. That's a concrete security improvement you can measure: count your externally exposed services before and after. The difference is dramatic.
I want to be clear: Zero Trust products can deliver fast, meaningful security improvements.
I've seen ZPA deployments that, within days, made it dramatically harder for a simple attacker, ransomware, opportunistic threats, to move laterally through an organization. Applications that were previously exposed to the entire network suddenly weren't. That's real value, and it can happen fast.
But that's the starting point, not the finish line. The quick wins buy you time and credibility. The long-term transformation, identity hygiene, least privilege enforcement, continuous verification, that takes years.
The product became 20% of the discussion. The other 80% was everything the product can't solve.
When I had real conversations with customers, the ones after the sales pitch, when we were actually planning deployment, the product became 20% of the discussion. The other 80% was:
The customers who asked these questions early succeeded. The ones who wanted the product to answer these questions for them didn't.
One factor that consistently predicted success: strong post-sales engagement, starting during the sales process.
When implementation teams, whether from the vendor or a partner, were involved before the deal closed, projects had a head start. The customer felt supported, not sold to. Trust was already there. The transition from "buying" to "building" was seamless.
When post-sales was an afterthought, brought in only after signatures, projects struggled to find their footing. The relationship had to be rebuilt from scratch.
If you're evaluating vendors, ask about this. Who will help you implement? When do they get involved? How much continuity is there between the sales team and the delivery team?
Zero Trust, done right, is hard. It requires changing how people work. It surfaces problems that were easier to ignore.
A product can make this easier. A product cannot make this unnecessary.
The best deployments I've seen weren't the biggest deals. They were the ones where the customer was ready to do the work. Where the product was a tool, not a magic wand. Where there was a genuine partnership between customer and vendor.
Zero Trust is not a product. It's a commitment.