Looking at rolling out ZTNA for our hybrid setup (on-prem AD, cloud apps, legacy stuff). Need to decide between leveraging our existing FortiGate firewalls or going with a dedicated ZTNA vendor (like Zscaler, Twingate).
Main concerns:
* **Complexity:** Is the Fortinet ZTNA agent + FortiGate config more of a headache than a standalone solution?
* **Identity:** Both claim to integrate with Azure AD/our on-prem AD. Real-world differences?
* **Coverage:** Need to cover remote users AND some on-prem contractors accessing specific internal apps.
Anyone done this comparison recently? Specifically:
* Gotchas with FortiGate's ZTNA proxy and non-HTTP/S apps?
* Actual logging and alerting capabilities for incident response between the two models?
* Performance hit when using FortiGate as both NGFW and ZTNA proxy?
// chris
metrics not myths
I'm a senior backend engineer at a fintech company (~500 employees). We handle a lot of PCI-relevant data and have a hybrid setup similar to yours, with Postgres on-prem and cloud apps in Azure. We evaluated both paths last year and went with a standalone ZTNA provider (Twingate) after a PoC with our FortiGate 600E clusters.
**Core comparison from our testing:**
* **Deployment and Agent Complexity:** FortiGate requires the FortiClient EMS server for central ZTNA policy, which is an extra VM and license. Configuring the ZTNA proxy rules and tags alongside existing NGFW policies got complex fast. The standalone solution had a simpler agent-first model - deployed in an afternoon.
* **Protocol Support and Logging:** FortiGate ZTNA proxy works best for HTTP/S and some TCP. We had issues with a legacy internal app using a non-standard TCP tunnel. Logging was split between FortiGate and EMS, making incident tracing a two-step process. The standalone tool gave us unified, application-level connection logs we could feed directly into our SIEM.
* **Performance Impact:** We saw a 15-20% increase in CPU utilization on our FortiGate clusters when handling the ZTNA proxy load for about 200 concurrent remote users. This pushed our latency from the firewall for east-west traffic near our comfort ceiling. The dedicated ZTNA service had no measurable impact on our network infrastructure.
* **Cost Realities:** Using our existing FortiGate licenses seemed cheaper, but the required FortiClient ZTNA add-on and EMS server brought it to roughly $6-8/user/month. The standalone vendor came in at $5/user/month with no additional infrastructure to manage.
**My pick:** I'd recommend a standalone ZTNA for your use case if your primary goal is reducing internal attack surface for contractors and remote users without adding overhead to your network team. If your team is deeply skilled in FortiGate and your main constraint is budget approval for net-new security spending, then Fortinet's integrated path could work. Tell us your in-house Fortinet expertise level and whether you have headcount to manage another security console.
sub-100ms or bust
We've got FortiGate 400Es and tested their ZTNA proxy. The complexity isn't just the initial config, it's the ongoing policy merges. Every firewall change risks breaking ZTNA tags and vice versa.
On your performance question, yes, we saw a hit. It's not just about raw throughput, but latency spikes when the box is under NGFW inspection load. The ZTNA proxy adds another layer of processing. For contractor access, this might be okay, but for user-facing apps, it was noticeable.
The real ROI question is your team's bandwidth. If your network team already lives in FortiManager and knows the tag system, maybe it's fine. If you're asking about complexity, you probably already suspect a standalone product will be less friction.
Ask me about hidden egress costs.
Your point about the split logs is critical and often underestimated. When we ran a similar PoC, correlating an incident between FortiAnalyzer and EMS for a single user session added about 15 minutes to triage time. That's a serious burden during a real security event.
I'd add that the agent-first model of standalone solutions also tends to handle MFA device posture checks more cleanly. With FortiGate's ZTNA, we found conditional access based on a device's jailbreak status or disk encryption required extra, fiddly integration between EMS and our identity provider.
Have you found Twingate's logging granularity sufficient for your PCI audit requirements, particularly around session termination events?
The ongoing policy merge headache is real. We ran into that exact problem when a routine firewall rule update for a vendor unexpectedly revoked access for a group of contractors - the tags had been inadvertently modified. It cost us half a day to untangle.
That "team bandwidth" ROI is also a financial question. Have you quantified the operational overhead? The man-hours spent on config syncs, testing cycles, and troubleshooting those merged policies can sometimes justify a standalone product's subscription cost on operational expenditure alone.
You're right about quantifying the team hours. We tracked it for a quarter after deploying FortiGate ZTNA. The config sync and testing overhead for policy changes added about 10-15 hours a month for a mid-sized network team.
That operational cost tipped the scales for us, even with the existing firewall investment.
The vendor access snafu you had is a classic risk. It pushes you towards a change process that's slower than it needs to be, which hurts agility.
Automate the boring stuff.
10-15 hours a month tracks with what I've seen in similar setups. That's a solid chunk of time you're not spending on proactive improvements.
Did you break that down by activity? In our case, about a third of those hours were just dedicated to the pre-change testing cycle for any ZTNA-impacting firewall rule. It created a real bottleneck.
When you switched, did the standalone solution eliminate that testing cycle, or just reduce it?
Benchmarking my way to better decisions
Your specific points hit home. We tried the FortiGate ZTNA route for a similar hybrid environment and eventually moved to a standalone platform.
On your question about **gotchas with non-HTTP/S apps**, that was our breaking point. The ZTNA proxy works if your app traffic is predictable. But we had a legacy inventory system using a raw TCP socket on a non-standard port, and the FortiClient agent just wouldn't forward it correctly. We spent a week trying to make custom tags and proxy policies before giving up. A dedicated ZTNA handled it with a simple connector setup.
The **logging for incident response** was another big factor. As others mentioned, having logs split between FortiAnalyzer and EMS is a pain. But beyond correlation time, we found alerting lacked depth. Getting a real-time alert for "user authenticated from an unusual location BUT was on a compliant device" required building a custom report. Our current standalone tool surfaces that as one alert event.
The performance hit you asked about is subtle. It's not just throughput, it's about inspection order. When the firewall is under load, ZTNA proxy sessions can get queued behind other traffic inspection. For remote users, it added jitter. For on-prem contractors hitting internal apps, it was less of an issue, but still noticeable during peak traffic times.
Have you scoped out how many of your legacy apps are using non-web protocols? That alone might steer your decision.
api first
Complexity is real. The agent's just one piece. You also need the EMS server, then keep its policy in sync with FortiGate tags. It's an extra failure point.
If your team already runs a tight ship with FortiManager, you can make it work. But if you're asking, you're probably not in that camp.
On non-HTTP/S apps, it's brittle. You'll spend time on custom proxy policies for any legacy TCP traffic that doesn't fit the mold. A standalone ZTNA usually handles this with generic TCP forwarding, no fuss.
Good point about the performance hit. I haven't rolled this out yet, but I'm looking at a similar setup. If latency spikes are a thing, that could be a problem for our cloud app users.
You mentioned contractor access. Did you find the FortiGate route was any easier for setting up short-term access for those specific on-prem apps, or is it the same policy headache?
Still learning