Hey everyone! 👋 We're evaluating Zero Trust Network Access (ZTNA) solutions for the retail chain I consult for. We have about 30 brick-and-mortar locations, each with a handful of on-site kiosks and shared admin terminals for managers. We need to secure access to internal web apps (like inventory dashboards and HR portals) without the complexity of a traditional VPN, especially for our small, non-IT staff.
Cloudflare Access is obviously a top contender with its simple pricing per user. But I'm curious about experiences from others in similar multi-location retail or hospitality setups. Our key needs are:
* **Location-aware policies:** Can we easily set rules like "This inventory app can only be accessed from the IP range of Store #12's back office?"
* **Kiosk/device management:** Handling shared, non-user-bound devices is a must. How do competitors handle device registration and authentication for that?
* **Cost predictability:** With a mix of ~50 corporate users and 100+ shared devices, per-user pricing can get messy. We're looking at alternatives that might offer per-application or tiered models.
I've been testing a couple of options, but would love real-world feedback. Has anyone moved from Cloudflare Access to something like Zscaler Private Access, Twingate, or even a more network-focused solution like a modern SASE platform? I'm particularly interested in:
* Setup complexity for a distributed environment
* End-user experience for non-technical staff
* Any gotchas with integrating on-premise legacy apps
Sharing your pros/cons or even pricing ballparks would be incredibly helpful as we build our shortlist.
—Kate
I'm the marketing ops lead for a regional retail group with 45 stores. I've managed the rollout of our ZTNA layer for three years, securing access to our marketing, inventory, and commission dashboards for both corporate and store staff.
**Core comparison for your scenario (Cloudflare Access vs. Twingate):**
* **Price Structure & Predictability:** Cloudflare charges a flat $7/user/month for the Zero Trust platform. With 50 users and 100 shared devices, you'd need to license all 150 as "users," costing ~$1,050/month. Twingate's model counts users and service accounts separately; in my last shop, shared devices used non-user service accounts which were free, so you'd likely pay for ~50-60 users at $5/user/month, roughly $300/month.
* **Location-Aware Policy Configuration:** Both handle this, but differently. Twingate lets you define a "Remote Network" for each store's IP block and attach policies directly. I found it clearer for mapping a policy like "Inventory_App_12 → Store_12_Network." Cloudflare uses Gateway with Geolocation and IP lists; it works but required me to maintain separate IP lists for common policies, adding a configuration layer.
* **Shared Device/Kiosk Onboarding:** Twingate uses "deployments" (lightweight connectors) installed on the kiosk itself, assigning the device a static identity. We used a single, shared service account for all kiosks in a location. Cloudflare Access for kiosks typically uses service tokens or short-lived certificates, which we scripted via their API. Twingate's method felt more like a traditional device profile, which our ops team preferred for troubleshooting.
* **Operational Overhead & Visibility:** Twingate's admin console surfaces all connected resources (users and devices) in one list with connection status. When a kiosk had issues, we could filter for that device and its network path. Cloudflare's visibility is more log-driven; you'd rely on Zero Trust logs in Splunk or their dashboard, which required more clicking to isolate a single device's history.
**My pick:**
I'd recommend evaluating Twingate for your case, specifically for the mixed user/device count and the need for straightforward location-to-app policies. To make the call clean, tell us if your kiosks are on a dedicated, stable network segment per store and what your team's comfort level is with maintaining API scripts for device auth versus a centralized device manager.
Nice summary of the key needs. That per-user pricing for shared devices is the exact reason we switched to Perimeter 81 last year. For us, their network-based billing model was a lot clearer for a mixed setup of staff and kiosks.
Their geo-fencing worked well for our store-level access policies too. I set up a rule where our scheduling tool was only accessible from our district office IP. Took maybe 10 minutes in the dashboard.
How are the options you're testing handling the shared device auth? That was our biggest headache before.
cheers
Good points on the per-user pricing for shared devices. That's a common pain point I've seen with retail rollouts.
One competitor I've deployed in a similar scenario is Zscaler Private Access. Their "app connector" model can work well for static kiosks and terminals. You place a lightweight connector in each store's network; it handles the authentication for the shared devices at that location without needing a per-device user license. Policies can be tied directly to those connector locations, so you can easily lock an app to "Store 12's connector."
It gets away from per-user billing and into a more predictable traffic-based model. The trade-off is a bit more initial setup for each location's connector, but it eliminates device-level user licensing entirely. Have you looked at that approach?
Integrate or die
That "simple pricing per user" line always makes me chuckle a little. It's simple until you realize that kiosk terminal someone uses for two minutes a day counts as a full user seat, same as your full-time accountant. Suddenly your "simple" bill is scaling with your device count, not your actual workforce. That's exactly the trap you're trying to avoid.
Zscaler's app connector model, as user163 mentioned, is one way to sidestep it, but now you've got 30 little software endpoints to babysit. It trades one complexity for another, and their pricing gets opaque fast once you factor in traffic and support tiers.
You're testing options, but have you actually calculated the total three-year cost of ownership for each, including the man-hours to manage the shared device auth? I've seen teams pick the "simple" user-based model only to spend more on scripting and maintaining kiosk user lifecycle than they'd have paid for a slightly pricier but device-aware platform. Sometimes the "competitor" isn't another vendor, it's just accepting that a small fleet of static service accounts or IAM roles might be cheaper and more reliable than trying to force a user-centric product into a device-shaped hole.
Your k8s cluster is 40% idle.