Skip to content
Notifications
Clear all

Why is FortiSASE so hard to configure for a small IT team?

3 Posts
3 Users
0 Reactions
23 Views
(@terraform_titan)
Eminent Member
Joined: 6 months ago
Posts: 11
Topic starter   [#830]

I’ve been wrestling with FortiSASE for the past few weeks, trying to roll it out for a client with a lean IT team of three people. While I'm generally a fan of Fortinet's on-prem gear, the SASE transition has been... surprisingly rough. The core promise of SASE is simplified security and networking, but the configuration complexity feels at odds with that, especially for smaller teams without dedicated network security architects.

From an IaC perspective, the main pain points I’ve hit are:

* **Terraform provider gaps:** The official FortiGate provider has limited support for SASE-specific objects. A lot of the critical configuration—especially for the Security Service Edge (SSE) parts—is still GUI-only or requires their cloud portal’s API, which isn't as mature. This forces manual steps, breaking our desired GitOps flow.
* **State management headaches:** When you do mix Terraform for the basic network constructs with manual portal config, you lose a single source of truth. Drift detection becomes a manual, error-prone process.
* **Overwhelming policy granularity:** The sheer number of knobs to turn for application steering, firewall rules, and ZTNA is impressive, but the onboarding doesn't guide you to a sensible baseline for a small business. It’s easy to create overly permissive rules or break access.

Has anyone else in a small-team context found a way to tame this? I’m looking for practical strategies, like:

* Any known workarounds to manage more of the config as code?
* Essential settings to lock down first for a secure baseline before getting granular?
* How you handle auditing and change tracking without full IaC coverage?

It feels like we need a "small team starter kit" – a minimal, secure, and maintainable configuration template. I’d be happy to start drafting one if we can pool our experiences.

--titan


Plan happy, apply safely.


   
Quote
(@Anonymous 158)
Joined: 3 months ago
Posts: 14
 

Your point about the Terraform provider gaps is a major blocker for automation. It pushes you into a hybrid state that's worse than either pure manual or pure IaC. I've seen teams try to bridge this with custom scripts that poll the cloud portal's API and reconcile it against Terraform state files, but it's a fragile, high-maintenance solution.

The overwhelming policy granularity is another classic case of vendor feature sprawl. For a small team, you need strong defaults and sensible presets, not an infinite canvas. It feels like FortiSASE's configuration model was built by the same engineers who work on their enterprise firewalls, without a true UX shift for the cloud-delivered service.

Have you looked at whether any of the emerging SASE benchmarking frameworks, like those from Miercom or NSS Labs, have done usability assessments? Raw throughput numbers are one thing, but configuration complexity metrics would be valuable for product selection.



   
ReplyQuote
(@cloud_ops_learner_2)
Honorable Member
Joined: 4 months ago
Posts: 561
 

Totally feel your pain. The Terraform provider gap especially hits home - I tried automating a basic SSE app steering policy last month and hit the same wall. Ended up with a messy mix of Terraform for network objects and a custom Python script wrapped around their REST API, which just adds another layer of maintenance.

> State management headaches

This is the silent killer. You start with good intentions, but that hybrid state means someone has to manually audit configs every month. We built a simple drift check using the API to at least flag differences, but it's a band-aid. It feels like they're forcing smaller teams to choose between full manual control or waiting for the IaC tooling to mature, and neither is great for speed or safety.

Have you found any workarounds for the policy granularity? I started using their CLI templates to at least version-control some of the ZTNA rules, but it's still clunky.


Infrastructure as code is the only way


   
ReplyQuote