Meridian Electric Cooperative uses a proprietary OT vendor protocol on the field-service segment that Fortinet's application signature database does not recognize. The administrator wants a deliberate, configured decision for this kind of unrecognized traffic rather than an accidental default. Where in an application control profile is that decision made?

An application control profile includes a distinct entry that governs traffic which doesn't match any known application signature, and the administrator sets an explicit action there — such as allow, block, or monitor — rather than leaving the outcome to an undocumented default. For Meridian's proprietary OT vendor protocol, which Fortinet's signature database has no entry for, this is exactly the setting that determines whether that traffic passes, is blocked, or is simply logged for visibility. The idea that unrecognized traffic is silently dropped ignores that this behavior is a configurable choice, not an automatic failure mode — and getting it wrong could unexpectedly break a legitimate OT protocol the utility depends on. The static URL filter list has no role here at all, since it matches URLs within web sessions, not arbitrary protocol traffic identified by application control. DNS filtering is similarly unrelated: it governs whether a domain name resolves, which is a separate decision from what application control does once a session's traffic doesn't match a known signature. A caveat: because this setting applies broadly to all unmatched traffic, not just the OT protocol in mind, changing it can affect other unrecognized traffic on the same policy too. Confirm the intended action is active by checking the application control log for sessions tagged as an unrecognized or default-category application.