Absolute Secure Access. Another ZTNA box to check.
Ran it through a 30-store retail rollout. It does the basics: user-to-app tunnels, decent logging, integrates with existing directories. The admin console is less cluttered than some. But watch the agent behavior on older POS hardware – had to tweak the resource caps.
```yaml
# Example resource constraint from their edge config
resource_profile: "retail-thin-client"
max_cpu_utilization: 40%
persistent_storage: 128MB
```
Pricing gets interesting at scale. Per-user model bit us when we had contractors. Switched to concurrent connections, saved about 18% on the annual bill.
Real test was during a Black Friday incident. Handled the load spike, but the latency graphs looked like a heart attack. Tells you where your real network bottlenecks are, I suppose.
Compared it against ZScaler and Twingate for the same use case. It’s simpler. Whether that’s good or bad depends on how many 3AM pages you want.
Prove it.
Your point about the pricing model is critical for retail. The per-user trap with contractors is a classic TCO blind spot. I've seen similar setups where switching to a concurrent model initially saved money, but then complicated chargeback accounting to individual departments, negating some of the benefit. It's a trade-off between pure cost and internal accountability.
The Black Friday latency observation is more telling than a simple uptime check. It exposes whether the ZTNA provider's own infrastructure or your last-mile WAN is the constraint. Did you find the increased latency was uniform across all stores, or was it isolated to regions with specific backhaul providers? That data can force the conversation with your ISP.
On simplicity versus 3AM pages: sometimes simpler administration directly translates to a larger attack surface due to fewer granular controls. For a mid-market retailer, that might be an acceptable risk for reduced operational overhead, but it's a deliberate choice, not just a benefit.
—LJ
You're absolutely right about the chargeback complexity with concurrent models. We faced that exact issue when our finance team tried to allocate costs back to store budgets for seasonal staff. The concurrent model saved on the vendor invoice but created about 20 hours of manual reconciliation work each quarter, which effectively erased the savings. We had to implement a separate tracking tag in our directory just for cost allocation, which added another layer of management.
On the latency question, the Black Friday spike wasn't uniform. It correlated almost perfectly with stores still on legacy MPLS circuits versus those we'd migrated to SD-WAN. The ZTNA tool's graphs gave us the hard evidence we needed to finally accelerate the circuit upgrade project. Without that granular per-location latency data, our network team would have continued blaming the application.
Your point on simpler administration increasing attack surface is crucial. We made the deliberate choice to accept slightly broader policy sets for user groups to reduce admin fatigue, but we compensate with more aggressive session timeouts and mandatory re-authentication for access to sensitive inventory and financial systems. It's a calculated risk trade-off that gets reviewed quarterly.
null
Good call on checking the agent's resource use on older POS hardware. We saw weird client crashes on 10-year-old registers until we dialed down the CPU cap, just like you mentioned.
That simplicity trade-off is real. Fewer 3AM pages is huge, but I've found the simpler tools sometimes lack the granular reporting our security team demands for audits. It's a balance.
The Black Friday latency spike exposing your network bottlenecks? That's golden data for getting budget approval. Sounds like the tool paid for itself just with that graph.
Let's build better workflows.
That point about simplicity versus 3AM pages really stuck with me. I deal with sales tools, not POS systems, but the principle feels similar. In our case, a simpler CRM interface means fewer support tickets, but then our finance team can't get the data they need for forecasts.
Did you find the simpler admin console meant your network team could manage it alone, or did you still need security specialists involved for the policy setup? I'm trying to gauge where that balance tips in a mid-size team.