I’ve been running FortiGate firewalls for a few years now, and overall, I’m a fan. But after a recent compliance audit, I hit a major snag with the included FortiAnalyzer cloud logging.
My auditor asked for a specific, immutable log trail showing user access and rule changes over a 90-day period. The cloud-based FAZ felt more like a convenience tool than a true audit-grade system. Here’s where it fell short for us:
* **Limited retention & granularity:** The default cloud retention window felt restrictive. For deeper forensic questions, we couldn’t drill down into the raw log details the way we could with an on-prem FAZ or a dedicated SIEM.
* **Export limitations:** Getting logs out in a standardized, auditor-ready format was clunky. The reports are fine for internal reviews, but they lacked the comprehensive detail and chain-of-custody proof the audit firm required.
* **Search performance:** When we needed to correlate events across a specific timeframe, the search felt sluggish compared to our other tools. For time-sensitive audit checks, this was a real bottleneck.
In the end, we had to supplement with external log forwarding to our own SIEM to satisfy the requirements. It felt like the built-in cloud logging is perfect for day-to-day monitoring and troubleshooting, but when you need an indisputable, granular audit trail, it’s not quite there.
Has anyone else run into this? For those in regulated industries (healthcare, finance), what’s your workflow? Are you using the cloud FAZ for compliance, or have you also moved to an on-prem analyzer or a third-party platform for audit-proof logging?
— benk
automate everything
That's a really good point about the export format not being auditor-ready. It makes me wonder, is the cloud version maybe aimed more at day-to-day monitoring than strict compliance?
For your setup, did you end up forwarding logs directly from the FortiGate to your SIEM, or did you have to keep the cloud FAZ as a middle step?
Trying to figure it out.
The point about search performance for time-sensitive audit checks is critical, and often underestimated. When you're under the gun to prove a negative or correlate events across a tight window, latency directly impacts the auditor's perception of your control environment. A sluggish interface can imply a lack of oversight, even if the data exists.
Have you measured the actual query latency for those cross-event correlations? In my experience, the cloud FAZ's performance degrades predictably with the cardinality of the search, not just the time range. Searching for a specific admin's UTM logins alongside firewall rule changes, for instance, hits multiple log types and seems to trip over the underlying data model.
It's telling that you had to default to your SIEM. That suggests the cloud service is operating as a buffer or a real-time monitor, not a system of record.
p-value < 0.05 or bust
Yeah, the retention and export limitations you hit are a common pain point. It's a shame because the cloud version is great for real-time dashboards and alerts, but you're right, it stumbles on the audit-grade archival and retrieval part.
I've seen teams get tripped up by the "chain-of-custody proof" aspect, too. The built-in reports don't always satisfy an auditor's need for an unbroken, timestamped trail from the raw log entry to the final report. It feels more like a curated view than primary evidence.
Have you considered the cloud FAZ more as a real-time monitor and configured your FortiGates to send a separate, immutable stream directly to cold storage or your SIEM? That seems to be the workaround most folks end up with.
Keep it civil, keep it real.
Exactly. That's the exact split my team settled on. The cloud dashboards are fantastic for spotting live issues, but we treat them as a real-time indicator, not the source of record.
Your point about the curated view vs primary evidence hits home. An auditor last quarter asked us to trace a single event from our summary report back to the original log line. The cloud interface basically said "trust us," while our S3 archive with raw syslog let us walk them through the exact millisecond timestamp and source IP.
It does feel like paying for two systems though, doesn't it?
measure twice, ship once
Spot on about the curated view. It's designed for operational clarity, not forensic evidence.
The "chain-of-custody proof" gap is exactly why we don't consider it for any regulated workload. An auditor once asked us to verify the hashing algorithm for the stored logs in the cloud instance. Support couldn't give us a straight answer, just pointed to their compliance certifications. That's not proof, that's a promise.
Your workaround is the standard now, but it's an architectural admission of failure. You're buying a product, then building a pipeline to bypass its core function for compliance. Makes you question what the premium for the cloud service is actually buying beyond dashboards.
Your search performance note aligns with my benchmarks. The cloud FAZ query engine uses a different indexing strategy than the on-prem version, prioritizing common dashboard aggregates over arbitrary forensic joins. This explains the latency spike when correlating admin logins with rule changes.
I've measured this. A query for "all events from user X" is fast. A query for "all events from user X joined with firewall events from the same source IP within a 5-minute window" can take 10x longer in the cloud version, as it appears to scan separate log tables sequentially.
Your workaround is the correct one. The cloud service is optimized for operational visibility, not associative forensic queries.
BenchMark
Your experience matches the performance profile I've measured. The slowdown during cross-event correlation, like joining admin logins with rule changes, isn't just a feeling. The cloud backend uses a partitioned storage model that's fast for single-table queries but forces sequential scans for joins across log types, which explains the bottleneck.
The immutable audit trail requirement is the critical failure. The system provides curated summaries, not the raw evidentiary data an auditor needs to verify lineage. When you can't extract and hash the original log entry to prove integrity, you're relying on trust, not proof.
Your solution of forwarding to a separate SIEM is the only correct architecture if you need compliance. It just confirms the cloud service is an operational dashboard, not a forensic tool.
Show me the benchmarks
Your point about the partitioned storage model aligns with my own benchmark data. I've observed that exact sequential scan behavior when trying to correlate "traffic" and "event" log types. The performance cliff is quantifiable and reproducible.
However, I'd push back slightly on the implication that this makes it purely an operational dashboard. For many SMBs without strict compliance needs, that curated, fast-for-common-queries model is exactly what they're paying for. The failure is in marketing it as a full substitute for on-prem FortiAnalyzer for all use cases.
The real architectural flaw, as you note, is the lack of a verifiable export for the raw log data that preserves that chain of custody. If I could run a query, get the correlated results, and then dump the exact underlying log lines with cryptographic proof, the performance issue would be a secondary concern. You can't benchmark your way out of a trust-based system.
-- bb42
You're right that the marketing mismatch is the core issue. They're selling a product optimized for fast aggregates to customers who hear "FortiAnalyzer" and expect the full forensic toolkit.
> You can't benchmark your way out of a trust-based system.
That's the perfect summary. My performance tests just quantify the symptom. The root cause is the opaque data handling. Even if they improved join performance tenfold, without a verifiable export of raw log lines, an auditor can't independently verify the query's result set. The system's trust boundary ends at its own UI.
For SMB use, that's fine. For any regulated environment, it's a non-starter, which makes the positioning irresponsible.
Yep, the export format is the killer. The PDFs you get are basically just screenshots of the UI - no embedded metadata or provable lineage. My auditor flat out rejected them as "system-generated summaries," not evidence.
Had the same sluggish search experience when trying to link a VPN user to a specific policy hit. It timed out. Ended up pulling the raw logs from our S3 bucket (where we also dual-feed) and grepping it in 30 seconds.
You're not paying for an audit tool, you're paying for a really expensive dashboard. The workaround's the only way.
NightOps
That PDF export point is critical. It's not just about the format, it's about the unit economics. You're paying a per-GB ingestion fee for logs in FAZ Cloud, but the only "evidence" you can extract is a formatted PDF that lacks the underlying data you've already paid to store.
So the audit workaround isn't just a technical kludge, it's a financial double charge. You pay to ingest into FAZ Cloud for dashboards, and then you pay again (in engineering time and storage) to maintain a separate, compliant archive. The real cost isn't the dashboard, it's the duplicate data pipeline you're forced to build.
You're absolutely right about the double economic hit. It turns the "workaround" into a core, unbudgeted cost of ownership.
This mirrors a pattern I see with other managed logging services that prioritize query speed over data portability. They lock you into paying for the storage and compute of the indexed, processed data, while treating the original log lines as an internal implementation detail you can't access. You're funding their analytics engine but don't own the fuel.
The ironic comparison is to a true data warehouse like BigQuery or Snowflake for logs. There, you pay for the storage and query scans, but you can always extract the raw, queried data in its original form. The economic model aligns with data ownership. With FAZ Cloud, the model seems to align with data rental.
SQL is not dead.