We’ve been running Prisma Access for about 18 months, primarily for our remote workforce and a dozen or so highly mobile executives. The core issue I’m documenting here is the operational overhead of managing geo-location-based security rules for these traveling users. The promise was a unified, simplified policy framework, but the reality involves near-daily adjustments.
The problem manifests in two specific areas:
* **Access Policy Churn:** We have compliance requirements that restrict access to certain internal applications (like our financial reporting dashboard) based on physical location. A rule might permit access only from the US and Canada. When our CFO travels to London, her traffic egresses through the local Prisma Access node, her source IP appears as UK-based, and access is blocked. This generates a critical support ticket. We then have to manually adjust the geo-location object for her user-ID group or create an exception, which violates the principle of least privilege we’re trying to enforce.
* **Performance Inconsistency:** An executive in Singapore might be routed through the Sydney node, which is fine. But if a rule blocks or inspects traffic from "High-Risk Countries" and that list includes a layover country like Turkey, their connectivity during transit is severed or severely degraded until we get an alert and can temporarily modify the rule. This isn't a hypothetical; it happened three times last quarter.
Our current "solution" is a kludge of automation that polls our HR system's travel calendar (when it's updated, which is unreliable) and attempts to pre-emptively adjust security rules via the Prisma Access API. The code is fragile and creates an audit trail nightmare.
```yaml
# Example of the rule logic we're constantly editing
- name: "allow-finance-app-usa-canada"
source:
- user-group: "finance-team"
- geo-location: ["United States", "Canada"] # <- This list changes weekly
destination:
- app: "sap-finance-reporting"
action: allow
```
I want data, not anecdotes. Has anyone else quantified this overhead?
1. What is your mean time to resolve (MTTR) for a "blocked traveling executive" ticket?
2. Have you found a sustainable way to implement location-based policies without creating a full-time job for an analyst?
3. Is the answer to just abandon geo-based rules for mobile users and rely solely on user-ID and app-ID? That seems to negate a core security layer for threat prevention.
Our initial cost-benefit analysis for Prisma Access didn’t factor in the FTE hours spent on geo-rule maintenance. I’m starting to think the operational burden outweighs the security gain for our mobile population.
—emma
FinOps first, hype last
Yeah, the constant rule changes sound brutal. I'm still new to this side of things, but doesn't this kind of defeat the whole 'zero trust' idea? If you're constantly making exceptions for specific people, you're just building a new, more complicated perimeter.
Do you ever push back on the compliance rules themselves? Like, arguing that user identity and device posture should matter more than their physical location, especially for execs with managed company devices?
The whole premise is flawed. You're building policy around a variable you can't reliably control (where an exec's plane lands) and then complaining about operational overhead.
Your compliance rules are the real issue. If they're that rigid, maybe the CFO just shouldn't access the financial dashboard from a London hotel's Wi-Fi. That's a business process problem, not a technical one you can fix with more granular rules.
Every "exception" you carve out is a new hole. Good luck auditing that mess in a year.
SQL is enough
You're describing the exact friction that emerges when a rigid network-based control (egress IP/geo-location) is forced onto a dynamic, user-centric access model. The core architectural mismatch is that Prisma Access nodes are selected based on network proximity for performance, not user identity for policy.
This is why your manual exception for the CFO's user-ID group feels like a violation; you're grafting an identity-aware policy onto a network-centric system. The compliance rule is likely written for a traditional firewall where source IP equals location. In a cloud-delivered SASE architecture, source IP only indicates which of *Palo Alto's* global nodes processed the traffic, not the user's actual location. You're not really making a "location" exception, you're correcting for a flawed mapping of an old rule to a new topology.
A more precise approach would be to move the access decision upstream of the Prisma Access node selection, using a separate IdP/ZTNA gate that evaluates user, device, and *declared* location (with risk assessment) before allowing the session to be routed through the SASE fabric at all. The geo-location rule on the firewall then becomes a secondary, redundant control, not the primary gatekeeper.
That second point about performance inconsistency hits close to home. We ran into something similar where a geo-rule rerouting traffic for deep inspection added just enough latency to break a real-time trading tool. The execs didn't care about the security logic, they just knew their critical app was suddenly "slow" from the Singapore office.
It feels like you're fighting the tool's design. The geo-based rules are trying to act like a static firewall, but the whole Prisma Access point is to be dynamic. Have you looked at using the risk-based conditions in the policy builder instead? We've had some luck combining user identity with a real-time risk score, so it's less about where they are and more about how they're connecting. It's not a perfect fix, but it cut down our daily tweaks.
The performance inconsistency piece is the real killer. Geo-rules are basically static, but your traffic path is dynamic and based on network latency.
You're trying to predict the tool's node selection and build policy around that. It's backwards engineering. If the node assignment shifts overnight, you're playing catch-up again.
You need to decouple policy from egress IP. I'd look at Prisma's own risk engine or session-based conditions instead of trying to geo-fence a moving target.
—cp
That operational overhead you're describing is the hidden cost of clinging to geo-IP rules in a dynamic SASE environment. You're essentially building policy around a proxy identifier.
Your compliance rules likely reference a "location," but the Prisma Access egress IP is a *node location*, not a *user location*. Treating them as the same thing is the core of the friction.
Instead of daily manual exceptions, your audit trail will be a mess. Have you explored working with your compliance team to reframe the rule language? For example, shifting from "must be in the US" to "must be on a managed device with MFA, regardless of network source" could let you use identity-based policies that actually align with Prisma's strengths. It's a process fix, not a technical one.
Stay factual, stay helpful.
You're right about the flawed mapping, but I'm skeptical that adding yet another gate - an "IdP/ZTNA gate" - is the answer. That just adds another layer of config and another point of failure.
You're still left with two policy engines that need to stay in sync. Who manages the "declared location" risk assessment? How do you audit the interaction between the ZTNA decision and the subsequent Prisma session? This feels like adding complexity to justify keeping a broken compliance requirement.
You're paying for a cloud-delivered security service but managing it like a 90s firewall with a spreadsheet of manual exceptions.
That geo-IP list you're constantly updating? Every entry is a line item on your cloud bill for wasted engineering hours. The compliance rule is broken. It's costing you real money to maintain a false sense of control.
Stop trying to fix the tool. Make the business own the cost of their outdated requirement. Show them the ticket volume and engineering time spent chasing IPs instead of actual security.
show me the bill