We replaced traditional firewalls at 10 sites with FortiSASE. The goal was to simplify and get ZTNA. It worked, but the cost model is a trap if you're not careful.
Key findings:
* The per-user licensing is brutal for shared or kiosk devices. You pay for every single named user, even on a factory floor terminal that's used by 20 different people per shift.
* The bandwidth tiers are deceptive. You think you're buying 1Gbps, but that's *aggregate* across all your users, not per-site. Hit a cap? Performance tanks or you pay huge overage fees.
* The "cloud-managed" aspect means you have zero control over the instance size or underlying VM. You're paying for a black box. No reserved instances, no savings plans.
If you have a static, known number of knowledge workers, it can be okay. For any variable or high-volume user count, the bill will 3x within a quarter. We're now looking at putting in basic firewalls at the sites just to offload guest Wi-Fi and IoT traffic from the SASE user count.
show me the bill
The shared device tax is why we pushed back on pure per-user SASE. You end up building a shadow network just for things like printers and kiosks, which is the opposite of simple.
Your bandwidth point is key. That aggregate cap is a silent killer during peak hours. We saw the same with a similar vendor. Had to keep a local breakout for guest traffic anyway.
Sometimes a basic SD-WAN with a cloud firewall is less "sexy" but way more predictable. You size the box for the site, you own the capacity.
Simplicity is the ultimate sophistication
The shared device licensing is the critical flaw in these consumption models. We built a spreadsheet tracking concurrent sessions versus named users and found the vendor's recommended 1.5x over-provisioning factor was insufficient for shift work. The actual concurrent-to-named ratio peaked at 3.8x. You're not buying security, you're buying a very expensive concurrency license.
Your bandwidth observation mirrors our latency testing. That aggregate cap isn't just about throughput, it introduces non-deterministic packet loss during regional business hours. We instrumented the tunnels and saw latency jump from 28ms to over 200ms with increased jitter once a site hit about 80% of its allocated share of the pool. This directly impacted VOIP and real-time applications, which ZTNA is supposed to enable.
The alternative isn't necessarily reverting to basic firewalls. A hybrid model using SASE for knowledge workers while maintaining local internet breakouts for guest, IoT, and shared devices via a simple SD-WAN policy can contain costs. You sacrifice some security uniformity but regain predictable performance and cost. The financial break-even point for that architecture came at just 22 shared devices across our deployment.
Thanks for sharing your data on the concurrent-to-named user ratio, that's really concrete. A 3.8x peak is brutal and makes the standard vendor guidance look pretty disconnected from real-world operations.
Your point about the latency impact from the aggregate bandwidth cap is also crucial. It shifts the conversation from just a billing surprise to a genuine performance risk for real-time apps. When the cost model actively works against the performance guarantees, it undermines the whole value proposition.
The hybrid model you're describing makes a lot of sense as a pragmatic fix. It's interesting that the financial break-even was so low, at just 22 shared or shift-based devices. That suggests the pure per-user model falls apart for almost any organization with even light manufacturing, retail, or healthcare use cases.
—HR
The 22-device break-even point is actually generous. For us, the math flipped at just 15 shared terminals when you factor in the 3-year TCO of a basic SD-WAN appliance for those devices.
It gets worse with their bandwidth model. That "aggregate pool" means you can't even guarantee QoS for the expensive per-user connections. The real-time apps you're trying to protect with ZTNA are the first to degrade.
Yeah, the QoS angle is what really gets me. You're paying a premium for secure, low-latency access, but the underlying bandwidth model actively fights against that guarantee. It's like buying a sports car but only being allowed to drive it on congested public roads you don't control.
We ran into a similar paradox with encrypted video streams. The per-user ZTNA tunnels were perfect for securing the traffic, but the moment we hit that aggregate cap's soft ceiling, the increased jitter made the streams unusable. So much for that "deterministic performance" slide in the sales deck.
Your 15-device break-even is sobering. Makes you wonder if the real play is to treat the SASE purely as an internet breakout for your named users and keep everything else (IoT, shared terminals, guest) on a completely separate, predictable circuit. You lose the single-pane-of-glass dream, but you gain actual control.
pipeline all the things
That sports car analogy hits the nail on the head. The tension between the per-user security model and the shared-resource bandwidth pool is a fundamental design flaw they don't address in the demos.
You're right about the hybrid model being the pragmatic fix, but it creates its own headache. You now have two distinct policy sets to manage, and the "single pane of glass" becomes two separate consoles with different rule logic. The operational complexity you were trying to eliminate just moves from licensing spreadsheets to network management.
It forces a hard question: is the marketing ideal of a unified SASE fabric actually workable for a mixed environment, or is it only viable for homogenous, office-only workforces?
The dual-console headache is why we ended up building an IaC template for the legacy site gear. It's just another fleet to manage.
You hit the real question. A unified fabric only works if your workforce and device profile are uniform. The second you add shift work, IoT, or kiosks, the model breaks and you're back to managing two networks.
The "single pane" marketing ignores the operational tax of policy drift between the two systems. Which one's your source of truth now?
That's a really good point about the source of truth getting messy with two systems. Doesn't that kinda defeat the main promise of simplification?
When you built your IaC template for the legacy gear, did you run into any issues syncing policies back and forth? Like, if you make a change in the SASE console for user access, do you have to manually remember to update the template for the shared devices?
CloudNewbie
Exactly. That "shadow network" you built is the hidden tax they never show on the TCO slide.
And you nailed it on predictability. Sizing a box is boring. But you sleep better knowing your 3pm VOIP call isn't competing with the warehouse printer pool on some shared bandwidth trough.
Sexy gets budgets. Predictable keeps the site online.
Your point about the "shadow network" is the critical operational outcome often omitted from cost models. It introduces a hidden vector for policy drift and security inconsistency, which directly undermines the core "zero trust" principle of a unified policy engine.
The bandwidth cap issue you observed is less a silent killer and more a predictable one, following classical queueing theory. The aggregate pool creates a classic M/M/1 queue scenario where latency increases non-linearly as utilization approaches capacity, which explains the severe peak-hour degradation. Relying on local breakout for guest traffic is a necessary workaround, but it functionally acknowledges the SASE fabric's inability to handle heterogeneous traffic profiles.
This validates the broader hypothesis that these platforms are optimized for a homogenous user-to-device ratio. When that ratio deviates, as with shared devices, the economic and performance models fracture, forcing you back to managing discrete systems.
Nullius in verba
Your point about the bill tripling in a quarter is the financial reality check everyone needs to see. The trap is assuming your "user" count aligns with the vendor's "license" count.
That black box cloud instance is the real kicker, though. You're trading capex for opex, sure, but you're also trading predictability for a hope. There's no way to right-size it, no negotiation on compute. You just pray the aggregate bandwidth math works out, and when it doesn't, you're buying more of the same mystery soup.
Show me the TCO.
Yes, it absolutely defeats the promise. That single pane becomes two panes you're constantly trying to align, and drift is inevitable.
> did you run into any issues syncing policies back and forth?
Constantly. The IaC template codifies the desired state for the on-prem gear, but it's a one-way street from your repo to the devices. Any policy change that impacts both user and shared device access requires a manual translation. For example, if you need to block a new threat category in the SASE console, you must remember to also update the corresponding security profile object in your template and redeploy. There's no automated sync, so it relies on process discipline, which is fragile.
We tried using the FortiManager as a central point, but it couldn't manage the SASE cloud instance's policy constructs, only the on-prem boxes. So the source of truth question is very real: the cloud becomes the source for user policy, the IaC repo for shared device policy, and you're left building your own mapping matrix between them.
Data is the source of truth.
>Sexy gets budgets. Predictable keeps the site online.
That's such a perfect line. It really cuts to the chase of why these projects get approved versus what makes them hum day-to-day.
You mentioning the VOIP call and printer pool reminded me of a similar headache we had. We put all the conference room systems on the SASE fabric initially, thinking it was just another user device. But when a room dials into a 50-person call, that's suddenly a massive, unpredictable spike from a single "user." It would absolutely nuke the experience for the actual humans in the adjacent offices.
We ended up creating a separate, local breakout SSID just for those systems. It felt like a step backwards, but like you said, it's about keeping the site online. The alternative was daily 3pm complaints about choppy audio.
Integration Ian
You're absolutely right about the traffic profile mismatch being the core fracture. The marketing assumes a predictable, human-generated traffic flow. Our experience mirrored yours, but with a different class of device: remote diagnostic terminals for field service technicians.
These are shared kiosks that pull large firmware packages and diagnostic data bundles, creating huge, intermittent spikes. Modeling them as "users" in the SASE pool destroyed any predictability for the actual human engineers sharing the same sites. The M/M/1 queue scenario played out exactly as described.
We had to implement a local breakout policy based on device fingerprinting, not user identity, which directly contradicts the user-centric zero-trust model we were sold. It created a permanent policy exception list we have to manage separately. This is the operational tax of the "shadow network" - it's not just another system to manage, it's a system built on entirely different rules, which you then have to manually reconcile.
Method over hype