We are evaluating Prisma Access for a warehouse environment where shared terminals are used for multiple purposes (inventory lookup, order picking, receiving). A core requirement is locking these terminals down into a secure kiosk mode, preventing users from accessing the underlying OS, browsing the web, or modifying system settings.
From a vendor-selection perspective, I'm interested in how Prisma Access integrates into this workflow beyond basic secure access. My primary questions for the community are:
* **Configuration Approach:** Is the kiosk mode configuration primarily handled on the endpoint device (via MDM/GPO) and Prisma Access simply provides the secure tunnel, or are there specific Prisma Access/GlobalProtect features (like HIP checks or explicit proxy policies) that are instrumental in enforcing the kiosk posture?
* **Policy Granularity:** For those who have implemented this, how are you structuring your Security and QoS policies in Prisma Cloud? Specifically:
* Are you creating a dedicated Service Principal for these terminals?
* How are you restricting traffic? For example, allowing access only to the specific SaaS inventory application (e.g., Oracle SCM Cloud, SAP IBP) and blocking everything else.
* Are you using URL Filtering with a strict "kiosk-relevant" custom category in addition to application policies?
* **Operational TCO Considerations:** What are the ongoing management pain points? Examples I'm analyzing include:
* Certificate management for the terminals.
* Handling terminal reboots and connection re-establishment.
* Monitoring and alerting on policy violations or unexpected traffic patterns from these devices.
The goal is a zero-trust network access model where the terminal only communicates with authorized applications. I'm looking for practical insights on whether Prisma Access is being used primarily as the secure transport layer, or if its policy engine is actively driving the lockdown.
- Mark
independent eye
You're on the right track thinking about the separation of duties. Prisma Access is fundamentally the secure tunnel; the kiosk lockdown itself is an endpoint configuration task using an MDM or Microsoft's assigned access features for Windows. However, Prisma Access can enforce the posture of that tunnel.
For your policy granularity question, a dedicated service principal is a clean approach for these static terminals. It lets you tie very specific security and QoS policies to that principal. You can restrict traffic by creating allow-list rules for only the FQDNs or IPs of your inventory SaaS, blocking everything else. The HIP check can be used to verify the kiosk application is running as the foreground process before allowing the tunnel to establish, which adds a layer of enforcement.
Have you considered how you'll handle software updates for the kiosk application or OS? That's often an overlooked policy hole, as you'll need to temporarily allow traffic to Microsoft or your patch repositories.
CloudCostHawk
Agreed, the update point is critical. That temporary policy exception creates a window where the terminal's posture deviates from the hardened, single-purpose state you've defined. The HIP check verifying the foreground application is a great pre-tunnel control, but it's often blind to what happens after connection, like an auto-updater spawning.
You might structure this by having two distinct service principals: one for the locked-down kiosk runtime with its strict allow-list, and another for update/maintenance mode with a broader policy. Switching between them would require a separate, authenticated process (like an admin password or MDM command), preventing a standard user from triggering the change. This keeps the primary kiosk policy simple and auditable.
brianh
Great question on separating the roles here. The kiosk lockdown is absolutely an endpoint configuration task, as others have said. Where Prisma Access becomes instrumental is in layering network-level enforcement on top of that device state.
For your policy granularity point, a dedicated service principal is the way to go. It creates a clean, auditable anchor for your rules. You'll want to build that explicit allow-list for your SaaS FQDNs, but don't forget about the "default deny" posture. One caveat: make sure your allow-list includes any regional or CDN endpoints your SaaS uses, or you'll get mysterious connection drops.
The HIP check for the foreground app is useful, but think of it as a gatekeeper, not a runtime monitor. It verifies posture at tunnel establishment. For true enforcement throughout the session, those strict Security policies tied to the service principal are what actually prevent a user from reaching anything outside your allowed set.
Architect first, buy later