So the prevailing wisdom from every "thought leader" on LinkedIn is that you pick one Zero Trust vendor, declare it a pillar of your "cybersecurity fabric," and never look back. Fascinating. Because I've yet to meet a real-world sales or revops team whose access patterns are that monolithic, or whose tolerance for vendor lock-in is that absolute.
I've been running Perimeter 81 and Cloudflare Zero Trust in parallel for about six months now. Not for redundancy, but because each handles fundamentally different use cases in our sales stack, and forcing one to do the other's job is an exercise in frustration and wasted cycles.
My setup, for context:
* **Perimeter 81** is the dedicated conduit for the sales team to reach the CRM (a heavily customized Salesforce instance), the CPQ tool, and the legacy deal desk portal. It's about securing access to specific, internal *applications*. The team gets the client, it's relatively set-and-forget for them, and I get detailed, user-level access logs that map cleanly to Salesforce user IDs for compliance.
* **Cloudflare Zero Trust** handles everything else: securing access to our internal wiki (Notion), the sales enablement hub, GitHub for the few sales engineers, and a handful of internal web tools. It's our gateway for *browsing* to internal resources. The policies are simpler, the DNS filtering is useful, and it's laughably cheaper for this type of diffuse, web-based access.
The friction points of running both are, predictably, in the overlaps and the user experience:
* You now have two agents on endpoints. This is a non-starter for some security purists, but the resource footprint is minimal. The real cost is in user education: "Use P81 for Salesforce, use Cloudflare for the wiki" is a mantra that takes a few weeks to stick.
* The dream of a single pane of glass for access visibility is dead. I'm correlating logs from two places, which means my data stack (BigQuery) is doing the heavy lifting. If your security team demands a unified, real-time view out-of-the-box, this will give them hives.
* Onboarding/offboarding now has two checkboxes. It's automated, of course, but it's another integration point to maintain between your IDP (we use Okta) and both platforms.
The upside, however, is that each tool is being used for what it's genuinely good at, rather than being brutally hammered into a role it's ill-suited for. I'm not paying P81's premium per-user price for someone to just browse internal docs, and I'm not trying to make Cloudflare mimic P81's granular, app-specific tunneling and access controls for our core revenue systems.
I'm curious if anyone else has abandoned the dogma of a single vendor for a more pragmatic, tool-for-the-job approach. Or am I just architecting a beautiful nightmare for my eventual successor? The total cost is lower and the performance is better, but I'm sure there's a consultancy out there that would call this "operational immaturity."
It's refreshing to see someone admit this. The "one vendor to rule them all" narrative is pure marketing fantasy, usually pushed by whichever analyst firm got the biggest check that quarter.
Your split makes perfect sense. Where I'd push back is on the "set-and-forget" bit with P81 for the sales team. Maybe it's just my experience, but the minute you add a new custom object or integrate a fresh lead enrichment tool into that Salesforce instance, you're back in the dashboard reconfiguring access rules. It's never truly static.
The real cost isn't the licenses, it's the mental overhead of managing two policy engines and hoping your audit trails line up. I'd be curious to know if you've hit any snags correlating an incident across both platforms, or if they remain neatly in their lanes.
cg
It works because you're splitting by use case, not by user. That's the key. Most teams try to make one tool cover every access pattern for a single person, which is where it breaks.
You're right about the "set-and-forget" point for P81 being optimistic. It's static until the CRM isn't. But that's still less overhead than trying to model custom object permissions in a general-purpose ZTNA proxy not built for app-specific tunnels.
Your point about mapping logs to Salesforce user IDs is the critical detail that gets glossed over in these discussions. Cloudflare's access logs are excellent, but they speak in terms of identity provider IDs, email addresses, and device posture. For a deeply integrated SaaS app like Salesforce, having a ZTNA layer that can natively map sessions to the actual application-level user ID in its audit trail is a huge compliance win.
The split you've described mirrors what we landed on, though for a different set of apps. We use Cloudflare for general web property and SSH access, but we kept a dedicated SDP for our legacy ERP because its internal authorization model is a black box. Trying to force Cloudflare Access to understand its internal roles would have been impossible without a proxy that could translate those sessions.
The mental overhead of two policy engines is real, but it's a trade-off for precision. How are you handling the cost attribution between the two platforms? We found that separating the bills actually made our FinOps tagging cleaner.
CPU cycles matter
This approach makes absolute sense from an operational perspective, but I'm always looking at it through the lens of TCO. Running two Zero Trust platforms side by side introduces a specific cost dimension beyond the base licenses that many teams overlook: the network egress and data processing fees incurred by the traffic patterns.
For your setup, the cost of P81's dedicated tunnels to Salesforce, CPQ, and the deal desk portal is relatively fixed and predictable. However, the Cloudflare side securing Notion, GitHub, and web properties is subject to the variable costs of Cloudflare's data transfer rules and any advanced security features you've layered on. When you analyze the monthly bill, you're paying for two distinct egress models. P81's cost is embedded in the per-user license, while Cloudflare charges you per gigabyte once you exceed the bundled amounts, which can happen quickly with media-heavy sales enablement hubs.
Have you quantified the crossover point where managing two separate policy engines becomes cheaper than trying to force one platform to handle all traffic types, given the potential for misconfigured rules and wasted bandwidth in a one-size-fits-all model? The mental overhead user980 mentioned has a direct translation to engineering hours, which has a price.
Always check the data transfer costs.
That user-level access log mapping you mentioned is really interesting. How do you handle pulling those P81 logs into your data warehouse for audit reports? I'm setting up something similar and trying to avoid a ton of manual CSV exports 😅
We use BigQuery, and I'm wondering if there's a direct API connector or if I'm stuck building a custom pipeline for it.
Exactly. Forcing a single vendor to cover every use case just creates friction and half-baked solutions. Your split is logical.
I run a similar dual setup, but I use Cloudflare for the high-volume, public-facing app proxy work and keep a dedicated SDP for legacy internal apps that speak weird protocols or have terrible auth built in. Trying to make Cloudflare Access understand a 20-year-old procurement system's internal "roles" was a non-starter.
The key is admitting no single product excels at everything, no matter what the sales deck says.
Couldn't agree more. That legacy app scenario you described hits home for me too. We had a similar situation with an old JIRA server that used a bizarre mix of LDAP groups and internal project roles. Trying to model that in a general-purpose proxy like Cloudflare was like trying to fit a square peg in a round hole, and the admin overhead became insane.
It reminds me that sometimes the "best tool for the job" is the one that speaks the app's native language, even if it means managing another console. The friction cost of a forced, single-vendor solution often outweighs the license savings.
hugo
Great point about mapping cleanly to Salesforce user IDs. That's the kind of practical detail that gets lost in high-level strategy talks.
The vendor lock-in fear is so real. I've seen teams forced into painful, expensive migrations because they bought the "single pillar" story and then their primary use case outgrew that vendor's strengths. Your split by *access pattern* rather than just user or department is smart.
How's the experience been onboarding a new sales rep? Do you find you're configuring both dashboards in parallel, or is it pretty streamlined once the initial patterns are set?
Onboarding a new rep is pretty straightforward once the patterns are locked in. For us, it's all about group memberships in our identity provider. Adding them to the "Sales" group auto-provisions access in P81 for the Salesforce suite, and the same group sync gives them the right Cloudflare policies for Notion and GitHub. So it's one change in one place, really.
Your question makes me wonder about offboarding though, especially when someone changes roles. Do you have any issues with access "ghosting" or lag in one system when you remove someone from a central group? I've seen some delays in policy propagation that made me nervous.
Amen to that. The "one true vendor" mantra drives me nuts. It usually comes from people who aren't the ones trying to stitch compliance reports together from half-fitting logs.
> each handles fundamentally different use cases in our sales stack
This is the core of it. We do something similar, but for engineering. Cloudflare secures the dev portals and internal tools, while we use a different SDP for secure database access. The protocols and session handling are just different beasts.
Your split by internal applications vs. everything else is super clean. Makes me wonder if more teams will start architecting their zero trust this way, by access pattern first.
data over opinions
"Mapping cleanly to Salesforce user IDs" is the kind of feature you only appreciate after you've spent a week trying to stitch together Cloudflare logs with internal audit trails. That native mapping is the entire justification for paying the P81 tax, especially when the compliance team comes knocking.
But I'm curious about the operational overhead you hinted at with "frustration and wasted cycles." Even with clean group syncing, you're still maintaining two distinct policy engines and watching two dashboards for anomalies. How often do you find a policy drift between them, say when an app gets deprecated but the cleanup only happens in one console? The management cost of two systems is rarely zero, even when the split makes perfect sense.
Your k8s cluster is 40% idle.
Oh, the policy drift you mentioned is so real. We're only in our first year with a split setup and I've already caught two deprecated apps that were still "live" in one console because the cleanup ticket only listed the primary tool.
It makes me wonder if there's a simple way to flag this, like a shared spreadsheet for the core access patterns that both admins check. But that feels like creating another thing to maintain.
How do you even start auditing for that kind of drift without it becoming a full time job?
So you're using P81 specifically for those internal, business-critical sales applications? That makes sense.
How do you justify the cost for that specific use case when management asks why you're paying for two overlapping security services? I'm looking at a similar split and that's the first question I always get.
Overlapping? Only if you squint and ignore what each product actually does. The cost justification is simple: what's the price of your sales team being locked out of Salesforce for half a day because a "general purpose" proxy choked on a metadata update?
You're not paying for two firewalls. You're paying for a specialized translator (P81) that speaks Salesforce natively, and a bulk freight carrier (Cloudflare) for everything else. Trying to make Cloudflare do the first job creates hidden costs in support tickets and lost revenue.
The real question for management is whether they want their security architecture built around a sales deck or around how the business actually works.
trust but verify