A security auditor at the utility wants visibility into every connection attempt that field devices make toward the corporate back-office network that isn't explicitly permitted by any policy, to spot reconnaissance or misconfigured devices. Reviewing the FortiGate's traffic logs, the auditor finds no entries at all for denied sessions, even though explicit policies are correctly logging their own traffic. What is the most likely reason?

The implicit deny policy in FortiOS has its own logging setting, separate from every explicit policy's logging configuration, and that setting is off by default. This means a FortiGate can be logging every explicit policy's traffic correctly while still producing zero entries for sessions the implicit deny catches, purely because nobody turned that one setting on. Enabling logging on the implicit deny is the direct fix for the auditor's visibility gap, and it is a supported, commonly recommended configuration specifically for security-monitoring use cases like spotting reconnaissance. The claim that FortiOS never logs denied traffic under any configuration is false, explicit deny policies log normally when configured to, and the implicit deny can be switched on the same way; the platform is not fundamentally opposed to recording drops. Log volume is managed through log settings and disk/FortiAnalyzer retention, not by explicit policies consuming a shared logging budget that starves the implicit deny, that framing doesn't reflect how FortiOS logging actually works. And while a FortiGate can absolutely forward logs to a FortiAnalyzer, that is a destination for logs the device generates, not a requirement for local traffic-log visibility; local logs still populate independent of an external log server. To verify, the engineer enables logging on the implicit deny policy and confirms new deny entries appear in the traffic log shortly afterward.