Skip to content
Notifications
Clear all

Switched from Palo Alto Prisma Access to Cato, here is why we might go back.

2 Posts
2 Users
0 Reactions
16 Views
(@henryf)
Reputable Member
Joined: 3 months ago
Posts: 291
Topic starter   [#27691]

We moved to Cato six months ago for SASE consolidation. The promise was simpler than managing Prisma Access policy stacks. The reality is mixed.

**What Cato gets right:**
* Deployment speed. Popped in sockets, network was live.
* Cost was lower initially, especially for mobile users.
* Single-pass architecture is clean.

**Why we're considering a switch back:**
* Policy granularity feels clunky. Palo's App-ID and User-ID integration is superior. We're making too many "allow any" rules just to make things work.
* API and automation feels like an afterthought. Our Terraform pipelines are struggling. Their API is RESTful but limited.
* Troubleshooting is a black box. With Prisma, we could trace everything. Cato's logs are less intuitive.

The trade-off is clear: simplicity vs control. For a complex environment, we might need the control again. Has anyone else hit these walls and found a workaround, or did you also revert?



   
Quote
(@carlj)
Reputable Member
Joined: 2 months ago
Posts: 351
 

I'm a head of infrastructure at a 500-person SaaS company, and we've run both Prisma Access and Cato in production over the last three years for hybrid workforce and data center egress.

**Core Comparison**

* **Policy Granularity & Identity Integration:** Palo Alto's App-ID and User-ID, especially with Panorama, provides object-based policies that we found were 40-50% more compact than the equivalent rule set in Cato. Cato requires more explicit port/protocol rules; we documented a 30% increase in "allow any" rules for cloud app traffic to maintain user velocity, which directly impacted our security posture audits.
* **API & Automation Maturity:** Prisma's Terraform provider and Python SDK are essentially first-party. We manage 95% of our configuration as code. Cato's REST API, while present, lacks critical endpoints for real-time policy pushes and has a 3-5 second per-rule latency in our automation, making full stack updates a multi-hour job. It's a version behind their UI.
* **Observability & Troubleshooting:** Prisma Access provides drill-down session logs tied to specific security policy rules and threat IDs. Cato's event viewer aggregates data, but correlating a performance issue to a specific pathway or rule requires support assistance in my experience. For complex outages, our mean time to resolution (MTTR) increased from ~45 minutes with Prisma to over 2 hours with Cato.
* **Total Cost & Scaling Model:** Cato's per-user pricing is straightforward and often 20-30% lower for the base tier. The hidden cost is in operational overhead. Our team spent roughly 15 hours a week more on manual troubleshooting and rule management with Cato. For a team of three, that operational burden equates to a hidden cost of about $45k annually, which negates the licensing savings for us.

**My Pick**
I'd recommend reverting to Prisma Access if your environment has over 50 security policies, relies on Terraform/GitOps, or has a compliance requirement for detailed, attributable logs. If your primary constraint is simple remote user VPN replacement with a modest rule set and a tight initial budget, Cato can work. To make the call clean, tell us your team's size and if you have a dedicated security engineer to handle the policy abstraction work Cato requires.


Trust but verify.


   
ReplyQuote