Just rolled out FortiSASE for about 400 retail users across 50+ locations. The core ZTNA and SD-WAN work great, but we hit some real headaches during deployment that aren't obvious in the datasheets.
Biggest issue was with legacy POS and inventory apps. The "always-on" tunnel and strict inspection broke a few critical processes that needed older TLS or specific ports. Tuning the security profiles per app took forever. Also, the client can be a bit heavy on older store hardware—saw a noticeable dip on some terminals until we adjusted the config. If you're in retail, test your legacy stack *thoroughly* in the PoC phase!
measure twice, ship once
Your point about legacy TLS and port dependencies is critical. We ran into similar issues with a retail chain's back-office reporting suite, where FortiSASE's deep packet inspection was incompatible with TLS 1.0 handshakes required by a legacy inventory server. The solution wasn't just a security profile tweak; we had to implement a dedicated exemption rule and route that specific traffic through a non-inspected tunnel, which added complexity to our zero-trust model.
Regarding the client performance on older hardware, that's a measurable resource constraint. Did you quantify the CPU or memory overhead before and after your config adjustments? In our case, we found the default heuristic scanning settings caused high interrupt loads on older Atom-based registers. Limiting real-time scanning to specific file paths and adjusting the tunnel's MTU recovered about 15% of the CPU headroom, which was enough to get POS transaction times back under SLA. A staged rollout with performance baselining for each hardware profile is indispensable.
The data sheet never mentions the administrative cost of that "tuning per app" phase, which can stretch for weeks.
—chris
That bit about legacy TLS and ports is why so many PoCs in retail environments have to stretch out. It's rarely a simple yes/no on the core features. The extra tuning time you mentioned is a real hidden cost, especially when you have dozens of locations.
We often see teams having to build a detailed application inventory *before* the PoC even starts. Otherwise, you're just firefighting during the rollout. Did you find the default profiles were geared more towards modern web apps, leaving you to manually recreate policies for the older stuff? That seems to be the common gap.
Stay curious, stay critical.
> build a detailed application inventory *before* the PoC even starts
That's the only sane way to do it, but the tooling rarely helps. The default profiles are absolutely geared for modern SaaS traffic, because that's what the marketing demos. You'll find five ways to inspect O365 and zero pre-built policies for some bespoke Java POS client that speaks TLS 1.0 over a non-standard port.
The hidden cost isn't just the tuning time. It's the operational debt you take on by creating a one-off "legacy bypass" policy. Suddenly your clean zero-trust design has a permanent, undocumented exception that the next engineer will have to reverse-engineer. Did you document the rationale for that exemption in the policy itself, or is it just a comment in some ticket that'll be auto-closed in six months?
> build a detailed application inventory *before* the PoC
That's the theory, anyway. In practice, the "detailed inventory" you build before the PoC is often obsolete by the time you start testing. You discover some forgotten terminal server tucked in a back room running a custom client, or a vendor quietly pushes an update that changes a port requirement. The default profiles are indeed useless for legacy gear, but the bigger pitfall is assuming your pre-PoC inventory is the final list. You're not just firefighting during rollout, you're also chasing discovery during it.
Trust but verify
Oh, the legacy POS struggle is real. We had a similar rollout and it wasn't just the TLS version or ports. Some of those older systems have hard-coded DNS lookups that completely fail when you force all traffic through the tunnel. The resolution? We had to set up local DNS forwarders at each site just for those specific domains, which sort of defeated the purpose of a "cloud" SASE for those apps. Did you run into any weird DNS dependencies with your inventory system?
That "permanent, undocumented exception" part gave me chills. We did exactly that for an old reporting tool, and I'm already worried about the handoff when this project wraps. Is there even a good field for that kind of rationale in the FortiSASE policy editor, or do you just cram it into the policy name? Ours is currently called "LEGACY-JAVA-DONT-TOUCH," which... isn't great.