We've been evaluating FortiSASE for the past three months, and the cloud app discovery module is falling short. It's consistently missing a significant portion of our internally-used SaaS applications, which makes the security and usage reporting incomplete.
**Our setup:**
* Traffic is routed through FortiSASE via the client connector.
* We have the recommended application signatures enabled.
* The discovered apps are mostly the big, standard ones (Office 365, Salesforce, etc.).
**The problem:**
It's missing niche but critical tools for our operations. Examples include:
* A cloud-based ERP (not SAP or Oracle)
* Several industry-specific data analytics platforms
* A handful of newer DevOps and project management tools
This creates a blind spot. If we can't see the traffic, we can't apply proper security policies.
**What we've tried:**
* Verified traffic for these apps is indeed flowing through the SASE tunnel.
* Checked for any custom signatures or categories we might have missed.
* Ensured SSL inspection is configured for the relevant user groups.
Has anyone else run into this level of under-reporting? Is there a specific method to get FortiSASE to recognize custom or less common SaaS applications, or are we reliant on Fortinet updating their signature database? Looking for concrete configuration steps or workflow adjustments.
Yeah, we hit the same wall with the signature-based discovery. It's great for the top 1,000 apps, but anything niche or custom just falls through.
You mentioned checking custom signatures. Did you try feeding it raw traffic logs from one of those missed apps? Sometimes you can spot a unique user-agent string or a specific API endpoint pattern. We ended up creating custom "applications" for a couple internal tools by matching on FQDNs, but it's a manual slog.
Have you looked at sending the FortiSASE logs to a SIEM or even a Grafana Loki instance? You could correlate the raw flow data against your known app list to quantify the gap. Might be easier than fighting the built-in module.
Alert fatigue is real, but so is my rule of silence.
You're right about the manual slog, but feeding raw logs to a SIEM just adds another layer of complexity. The real issue is that signature-based discovery is inherently limited, no matter who builds it.
We handle this by using Datadog's Network Device Monitoring to capture the flow logs directly, then apply our own custom tagging based on destination IP or domain. It's still manual, but at least the taxonomy lives in our observability stack where we can use it for other correlations. Creating a custom "application" in a security product often locks that context away from your performance metrics.
If you're already sending logs to a SIEM for this, you're halfway to needing a separate platform to actually use the data.
null
You're running into the fundamental limit of vendor-maintained signature databases. They prioritize coverage for the highest-risk, most common apps. Niche or proprietary tools are never on that list.
The answer isn't in the discovery module itself, it's in the policy engine. Treat the unidentified traffic as its own category. Build a policy that tags all traffic to those known, missing FQDNs and applies a specific profile. You can label it "Internal SaaS - Unverified" and apply stricter inspection and logging rules than your standard trusted apps.
That way you close the policy blind spot immediately. The reporting gap remains, but that's a visibility problem. The security control is in place.
Where is your SOC 2?
Yep, that's exactly why I moved our internal tool tagging out of the security console and into our observability setup a while back. Using the security product as the source of truth for application identity locks you into their taxonomy and reporting.
You mentioned Datadog - we do something similar with New Relic's network monitoring. The real win for us was tying that custom app context back to user session data and frontend performance metrics. Now we can see if slow load times on our niche analytics platform are a network issue or a client-side JS problem. It's still a manual list to maintain, but at least the data works harder for us.
One caveat, though. While it solves for visibility and performance, it doesn't directly feed your security policy. You still need that mapping in FortiSASE or whatever edge device you're using for access control. So you end up managing two lists.
✌️