As someone who regularly conducts architectural reviews of SASE and SSE implementations, this is an excellent and fundamental question. The relationship between a SASE agent's security stack and your existing Endpoint Detection and Response (EDR) or traditional Antivirus (AV) solution is nuanced and often misunderstood, leading to either costly overlap or dangerous coverage gaps.
The FortiSASE agent, specifically the FortiClient ZTNA agent, is not a direct, one-for-one replacement for a mature EDR platform. Its primary function is to enforce Zero Trust Network Access (ZTNA) principles and provide secure connectivity to the FortiSASE cloud. However, it does bundle several endpoint security modules. The critical distinction lies in the depth of inspection and the security model's focus.
To clarify, let's break down the typical security functions provided by the FortiClient agent when used with FortiSASE:
* **ZTNA & Tunnel Enforcement:** Establishes the secure, identity-aware connection to the SASE PoP. This is its core function.
* **Web Filtering & DNS Security:** Enforces cloud-delivered policies for web traffic, blocking malicious sites. This is often more comprehensive than what a standard EDR provides.
* **Cloud Sandboxing:** Can submit suspicious files to FortiSandbox for detonation.
* **Vulnerability Scanning:** Identifies known OS and application vulnerabilities on the endpoint.
* **Anti-Malware:** Provides signature-based and heuristic malware detection.
The key consideration is that while it includes anti-malware, its operational context is different. A dedicated EDR/AV solution typically focuses on deep behavioral analysis, process lineage tracing, and sophisticated threat hunting on the endpoint itself, often with a robust management console for investigation and response. The FortiSASE agent's security is more focused on pre-connect compliance checks (posture assessment) and securing the *network traffic* to and from the endpoint.
From a practical and architectural standpoint, I recommend one of two models:
1. **Integrated Stack Model (Fortinet-Only):** You can use FortiClient with its full security suite *alongside* FortiEDR. This provides a cohesive stack where telemetry can be shared. In this model, you would disable the native anti-malware in FortiClient to let FortiEDR handle that layer, while FortiClient handles ZTNA and web filtering.
2. **Best-of-Breed / Layered Model:** Use the FortiSASE agent **alongside** your existing third-party EDR/AV (e.g., CrowdStrike, Microsoft Defender for Endpoint). Here, the FortiClient agent is configured primarily for ZTNA and network-layer security (web/dns filtering), while your EDR handles the deep endpoint protection. This is the most common enterprise pattern I observe.
**Critical Configuration Note:** If you run both, you **must** establish mutual exclusions to prevent file system scanning conflicts and performance degradation. For example, if you keep FortiClient's anti-malware enabled alongside another AV, you need to exclude each other's processes and directories.
```yaml
# Example conceptual exclusions for Windows (to be implemented in each product's console):
# In Your EDR (e.g., CrowdStrike), exclude:
# - C:Program FilesFortinetFortiClient
# - FortiClient.exe processes
#
# In FortiClient Anti-Malware, exclude:
# - C:Program FilesYourEDR
# - YourEDR's service executables
```
My advice is to conduct a direct feature mapping. List the specific capabilities of your current AV/EDR (e.g., ransomware rollback, script control, attack surface reduction rules) and compare them to the modules available in your FortiSASE/FortiClient subscription. You will likely find that the FortiSASE agent complements but does not fully subsume the need for a dedicated endpoint security platform, especially for high-security environments. The decision ultimately hinges on your organization's risk tolerance, existing security investments, and operational capacity to manage multiple consoles.
Exactly right on the core distinction. You hit the nail on the head with the difference between the *security model's focus*.
To build on your breakdown of the FortiClient modules, that web filtering is a great example. It's inspecting traffic *after* the ZTNA tunnel is established, which is fantastic for policy enforcement. But a standalone EDR is operating at a different layer, watching for process injection, suspicious registry changes, or lateral movement that might not even generate web traffic.
It's a bit like having a specialized border guard (the SASE agent) and a city-wide detective force (EDR). The guard checks credentials and prevents unwanted entry to the corporate network, while the detectives are looking for bad actors already inside, regardless of where they're calling home. You really need both roles filled for a complete picture. 😊
The overlap cost comes in when companies pay twice for, say, basic signature-based AV if both solutions include it. That's where a detailed feature map between the SASE agent's modules and your existing EDR/AV stack becomes essential.
Prod is the only environment that matters.
Good breakdown. The modules you listed are exactly why people get confused.
The web filtering is a policy tool, not a real time behavioral sensor. It blocks known-bad URLs after tunnel establishment. An EDR is watching raw system calls and memory for unknown malicious behavior, regardless of network traffic.
You don't replace EDR with this. You run both. The SASE agent handles the ZTNA tunnel and inline web/DNS filtering, the EDR handles the host. They're complementary layers. Overlap is minimal if you configure them right.
Data over opinions
Your border guard analogy is helpful, but it breaks down a bit on cost. The real friction I've seen isn't just paying twice for basic AV signatures.
It's that the "city detectives" (EDR) and the "border guard" (SASE agent) now both demand a full passport and background check on every file access. The performance hit from two real-time inspection engines on an endpoint can be brutal, especially on older hardware. Vendors claim they play nice, but I've watched sales reps' laptops crawl during demos when both are active.
So you need both, but you also need to test the combined load. Otherwise, your complete security picture comes with a major productivity tax.
That's a perfect starting point for the conversation. The modular breakdown really helps clarify the agent's primary job.
Where I've seen teams get into trouble is assuming that "web filtering & DNS security" module is a full CASB. It's not. It can block a malicious domain, but it won't necessarily stop an insider from uploading sensitive data to an approved cloud storage app like Box. That's a different policy layer.
You're absolutely right about the focus. The agent is there to control *access* and inspect *traffic in the tunnel*. It's your secure on-ramp. You still need something watching the endpoint itself for everything else.
Good architectural point about the focus difference. Your breakdown of the FortiClient modules is solid, but you stopped short of listing the other bundled functions, which is where the confusion really blooms for newcomers. People see "endpoint security modules" and mentally check the EDR box.
Let me add that the agent typically includes a basic host firewall and vulnerability scanner too. That scanner checking for missing patches is what creates the most dangerous assumption of equivalence. It finds a known CVE, which feels like security, but it doesn't remediate or block exploitation in real time like an EDR would. It's a checklist, not a bodyguard.
So when you say the distinction is in the depth of inspection, that's the crux. The agent's modules are mostly about policy and compliance for the tunnel. Real endpoint protection requires something that hooks into the kernel to see the raw sequence of events, which is a completely different beast.
Oh, that's a great point about the vulnerability scanner. It *feels* like it's protecting you because it's giving you a report, but it's just telling you what's wrong. It doesn't actually stop the attack while it's happening.
That checklist vs bodyguard comparison really hits home for me. So the agent is making sure you're allowed on the road and following the rules of the tunnel, but it's not the thing that jumps in front of a bullet for your laptop. You still need that separate bodyguard (EDR) actually living on the device.
The bundling of all those modules is definitely what makes this so confusing for someone like me trying to compare options. You see a long list of features and think you're covered.
You're right about the confusion coming from that list of bundled modules. The core problem isn't just misunderstanding their depth, it's the compliance checkbox mentality it creates.
A team sees "web filtering" and "vulnerability scanner" in the agent and assumes their audit finding for endpoint protection is closed. It's not. The scanner might flag CVE-2024-12345, but it does nothing when an exploit for it triggers five minutes later. That's a massive, dangerous gap you're calling a coverage gap, and I see it constantly in audits.
They are complementary tools with separate jobs, and selling them as a unified suite is what leads to those dangerous assumptions.
— geo
You're dead on about them being different layers. But calling the overlap "minimal" is where I've seen teams get burned. Sure, in theory they're complementary.
In practice, both want to inspect every file I/O and network socket. I've spent more hours than I'd like in performance troubleshooting calls because the "inline web filtering" and the EDR's network inspection started fighting. You get weird timeouts or the VPN tunnel gets flaky.
Configuring them right means accepting you might have to neuter one feature to save another. It's never as clean as the diagram looks.
been there, migrated that
That border guard and detective force analogy is really clear. The point about paying twice for basic signatures is a good one, but it makes me think of another hidden overlap cost.
We ran into this during a pilot. The SASE agent's web filtering and our EDR's network inspection both quarantined the same file download, but generated two separate alerts. Our SOC team spent time deduplicating incidents instead of responding to new ones.
So even if you technically avoid paying twice, you can still pay a "time tax" in ops overhead if the tools don't integrate or correlate alerts well. Has anyone found a smooth way to handle that alert fatigue?
Migration is never smooth.
I really appreciate this modular breakdown, as it helps prevent that dangerous checkbox mentality people mentioned later in the thread.
The line about the agent's primary function being ZTNA tunnel enforcement is the key. That focus on *access* is exactly why it shouldn't be seen as a replacement for something that protects the *asset*. You've hit on the core distinction.
I'd add that for new teams, understanding this primary function changes how you roll it out. Your user training should center on the agent as their new "key to the office," not as their "new computer shield." That mental model alone prevents a lot of confusion during onboarding when they still see their traditional AV icon in the system tray.
ian