Fortinet virtual patching needs signature-applicability evidence

Create a versioned signature-applicability record

Fortinet says its OT Security platform provides broad OT signature coverage and can protect unpatched or legacy assets through virtual patching. The distinct control question is whether a particular signature can intercept the vulnerable traffic path for a particular deployed asset without disrupting the industrial process. A catalog claim or vulnerability identifier does not establish that the affected component and code path are present, reachable through the enforcement point, or safe to block.

Record the asset and site, vendor, model, firmware and software, function, process and safety context, vulnerability identifier, affected-component evidence, exposed service and protocol, communication peers, network path, enforcement device and policy, signature identifier and package version, action mode, exceptions, deployment time, expiry, owner, and review date. Preserve uncertainty where inventory or supplier evidence is incomplete. One device family label should not silently scope every installed variant.

Test protection without claiming a software repair

Virtual patching changes network enforcement; it does not modify vulnerable device code. Keep the vendor advisory, approved firmware or software remedy, integrator compatibility review, engineering change, outage plan, backup, rollback, validation, and return-to-service record on a separate track. The compensating control may remain necessary when no supported patch exists, when the installed application cannot yet accept it, or while a safe plant window is prepared, but that status needs an accountable expiry and reassessment trigger.

Test the signature in monitor mode and a representative nonproduction or controlled setting where feasible. Include ordinary control traffic, unusual but legitimate maintenance commands, fragmented or encoded traffic, routing changes, encrypted segments, redundant paths, failover, high load, sensor loss, signature updates, and rollback. Capture expected and actual decisions, latency, dropped or altered communications, process observations, alarms, operator review, and approval before moving to blocking mode.

Monitor bypass, drift, and residual exposure

A signature can be installed while the vulnerable flow bypasses its enforcement point, the policy remains disabled, an exception is too broad, or an alternate protocol reaches the same function. Continuously reconcile protected assets and paths against topology, rule deployment, device health, signature version, policy changes, bypasses, new interfaces, vendor remote access, and observed traffic. A lack of alerts is not proof that exploit attempts were absent or that inspection covered the relevant path.

Define states such as proposed, tested, approved, deployed-monitor, deployed-block, exception, degraded, bypassed, superseded, retired, and unable-to-verify. Every transition needs evidence and authority. If a signature fires, preserve the original traffic and device context, distinguish detection from prevention, investigate process consequence, and connect any incident or maintenance action without treating the product event as a site risk or safety conclusion.

Make temporary-control aging visible

A buyer or site trial should begin with a small set of well-characterized assets and vulnerabilities. Demonstrate how signatures are selected, tested, approved, distributed, confirmed, monitored, excepted, rolled back, and retired. Then trace the vendor-patch path independently. Measures should distinguish eligible assets, verified applicable assets, protected paths, tested policies, current deployments, exceptions, bypasses, detections, blocked events, false positives, overdue reviews, and completed software remediation.

OT Defense Review reviewed Fortinet's registered OT Security page on September 8, 2026. The page supports provider claims about OT signature coverage, virtual patching, monitoring, segmentation, and related controls. It does not establish asset inventory, vulnerability applicability, path coverage, signature efficacy, safe operation, control configuration, absence of compromise, vendor-patch suitability, compliance, or site outcome. No dated post-cutoff product change was verified.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.