Fortinet OT Security Architect common mistakes
Fortinet OT Security Architect · Understand the traps and how to avoid them.
When asked to design segmentation for a Purdue-model OT network, the candidate places the IT/OT boundary firewall at Level 2 (supervisory) instead of between Level 3 (site operations) and Level 4/5 (enterprise/IT), and then justifies it by saying 'the DMZ must protect the PLCs directly'.
Candidates memorize the Purdue levels as a vertical list but never map FortiGate zones, VDOMs, and the industrial DMZ to the actual conduits. They conflate 'protecting controllers' with 'placing the enforcement point', which leads to an architecture that breaks remote-support flows and violates the IT/OT demarcation the exam expects.
What to do instead
Draw the reference architecture before answering: Level 0-2 field devices, Level 3 site operations (where the OT FortiGate sits), the industrial DMZ with a second FortiGate or VDOM pair, and Level 4/5 enterprise. State explicitly that the primary IT/OT enforcement point is the Level 3/4 boundary, the DMZ brokers all IT-to-OT sessions, and direct PLC exposure is never the design intent. Practice labelling each FortiGate interface with its Purdue level and trust direction.
The candidate treats FortiGate VDOMs as the only segmentation tool and ignores FortiSwitch VLANs, microsegmentation, and FortiNAC device profiling, so the design collapses when the scenario asks how to isolate a single legacy CNC or a flat Level 1 subnet without replacing the L2 topology.
VDOMs are the most visible Fortinet segmentation feature, so candidates over-apply them. They miss that OT segmentation often must happen at Layer 2 (VLAN + private VLAN + FortiSwitch port isolation) and at the endpoint-identity layer (FortiNAC), and that VDOMs are an administrative/routing separation, not a substitute for L2 isolation.
What to do instead
Build a segmentation toolbox: VDOMs for administrative and routing separation, FortiSwitch VLANs and PVLANs for L2 isolation, FortiGate policies with industrial protocol inspection for L3/L4 control, FortiNAC for device profiling and dynamic VLAN assignment, and FortiEDR/FortiDeceptor for endpoint and deception. For each scenario, pick the lowest layer that achieves the isolation goal and justify why a VDOM alone is insufficient.
When configuring FortiGate policies for OT protocols, the candidate enables the industrial protocol sensor (Modbus, DNP3, IEC 61850, OPC) on the IT-to-OT policy and expects it to block unauthorized function codes, but never sets the protocol options to enforce or never places the sensor on the correct policy direction.
Candidates learn that FortiGate has industrial protocol signatures and assume enabling the profile equals enforcement. In reality the sensor must be attached to the policy that carries the traffic, the protocol options must be set to block or monitor per function code, and asymmetric or out-of-band traffic bypasses the sensor entirely.
What to do instead
For each industrial protocol, state the policy where it is inspected, the direction (IT-to-OT vs OT-to-IT), the function-code allowlist, and whether the action is monitor or block. Verify the traffic actually traverses the FortiGate (not a direct L2 path), and remember that protocol inspection is stateful and does not protect traffic that never hits the firewall. Lab the Modbus function-code block and confirm with logs.
The candidate designs the OT monitoring stack around FortiAnalyzer log retention alone and never addresses passive traffic analysis, asset discovery, or the fact that many OT devices cannot send logs, so the monitoring design has no visibility into the Level 0-2 devices it claims to protect.
Candidates default to Fortinet's logging products because they are familiar from IT security, but OT visibility requires passive discovery (FortiGuard OT Security Service / FortiDeceptor / third-party passive sensors) and network TAP/SPAN feeds because PLCs and RTUs do not run agents. The exam scenario usually includes unmanaged legacy devices that only reveal themselves through traffic.
What to do instead
Separate the monitoring design into three planes: passive network discovery via SPAN/TAP into a passive sensor or FortiGate in one-arm sniffer mode, log collection via FortiAnalyzer for devices that can log, and active deception via FortiDeceptor for lateral-movement detection. Explicitly state which devices are agentless and how they are discovered, and name the FortiGate sniffer-mode interface as the collection point when no TAP exists.
When asked how to detect an attack moving from IT into OT, the candidate lists only FortiGate IPS signatures and FortiAnalyzer correlation, and omits the need for OT-specific anomaly baselines, east-west traffic inspection inside the OT zone, and the role of the industrial DMZ as a logging choke point.
Candidates map IT detection patterns onto OT and assume perimeter IPS is enough. OT attacks often use legitimate protocol function codes, so signature IPS misses them; detection depends on baselining normal engineering traffic, inspecting east-west flows between Level 2 and Level 3, and correlating DMZ broker logs.
What to do instead
Describe a layered detection design: perimeter IPS at the IT/OT boundary, industrial protocol anomaly detection on east-west policies inside the OT zone, baseline learning for engineering workstation-to-PLC traffic, DMZ broker and jump-host logging, and FortiAnalyzer correlation across all of them. For each layer, name the Fortinet component and the log source, and explain what a signature-only design would miss.
The candidate configures high availability for the OT FortiGate as active-passive with the same firmware and config sync but forgets that OT change windows and protocol sessions (long-lived Modbus/TCP or OPC sessions) behave differently on failover, and never tests session pickup or explains the maintenance impact.
Candidates treat OT HA as an IT HA checkbox. In OT, a failover that drops a long-lived PLC session can stop a production line, and firmware upgrades must follow OT change control. The exam tests whether the candidate understands HA behaviour for stateful industrial sessions and the operational constraints around patching.
What to do instead
State the HA mode, the session-pickup behaviour for the industrial protocols in scope, and the failover test plan including a live PLC session. Address firmware upgrade strategy under OT change windows (secondary unit first, validated during a maintenance window, with rollback). Explain how FGCP heartbeat and link monitoring are configured so a failed OT uplink triggers failover without flapping.
When troubleshooting why an engineering workstation cannot reach a PLC through the FortiGate, the candidate starts by rebuilding policies or disabling inspection, instead of reading the forward traffic log, checking the session table, and confirming the return path and asymmetric routing.
Candidates jump to configuration changes because they lack a structured troubleshooting order. OT networks frequently have asymmetric paths (traffic in via one FortiGate, out via another) and overlapping subnets, so the first diagnostic must be the session and route, not the policy.
What to do instead
Use a fixed order: (1) FortiGate forward traffic log and session table to see if the packet arrived and what policy matched; (2) route lookup and return-path check for asymmetric routing; (3) policy and NAT review; (4) protocol sensor and IPS action; (5) device-side capture. In the answer, name the exact diagnostic commands (diagnose sniffer packet, diagnose sys session list, get router info routing-table) and explain what each result rules out.
The candidate describes administrative access to OT FortiGates as 'use admin accounts with strong passwords' and omits role-based access, MFA, TACACS+/RADIUS integration, and the separation of the OT management plane from the data plane.
OT administration is often treated as an afterthought, but the exam tests whether the candidate can design management access that does not create a new attack path. Candidates forget that management interfaces on the OT FortiGate must be reachable only from a management VDOM or out-of-band network, and that local admin accounts are a common audit finding.
What to do instead
Design a management plane: a dedicated management VDOM or interface reachable only from the IT management network or a jump host, admin accounts backed by TACACS+/RADIUS with per-role profiles (read-only for operators, policy-edit for engineers), MFA on all admin logins, and no admin access from OT data interfaces. State how the FortiGate is patched and backed up under OT change control.
When integrating the OT FortiGate with the enterprise SIEM, the candidate sends all logs unfiltered and does not define the log schema, severity mapping, or the specific OT events (policy denies on industrial protocols, configuration changes, HA failover) that the SOC must see.
Candidates treat SIEM integration as 'turn on logging'. In OT, log volume from chatty industrial protocols can overwhelm the SIEM, and the events that matter (unauthorized function codes, new asset on the OT network, admin login from an unexpected source) get lost. The exam tests whether the candidate can select and normalize the right events.
What to do instead
Define the integration: FortiAnalyzer as the aggregation point, a log filter that forwards only security-relevant OT events (industrial protocol denies, new-device discovery, config change, admin auth failures, HA state change), a severity mapping to the SOC's taxonomy, and the transport (syslog over TLS, FortiAnalyzer connector, or API). Name the specific FortiGate log fields (logid, subtype, action, srcintf/ dstintf) the SIEM parser will key on.
The candidate designs the OT security ecosystem as Fortinet-only and cannot explain how the FortiGate exchanges threat intelligence with FortiGuard, how FortiNAC shares device context with FortiGate, or how third-party OT asset-management and SIEM tools consume Fortinet data via APIs, so the integration answer is incomplete.
Candidates learn individual products but not the integration fabric. The exam expects the candidate to know the Fortinet Security Fabric connectors, the FortiGate API and syslog exports, and how FortiNAC's device profiling feeds dynamic policy. Without this, the candidate cannot answer ecosystem questions about sharing context across IT and OT.
What to do instead
Map the ecosystem: FortiGuard for threat intelligence and OT protocol signatures, FortiNAC for device profiling and dynamic VLAN/ policy assignment, FortiAnalyzer for log aggregation and correlation, FortiDeceptor for deception, and the FortiGate API/syslog for third-party SIEM and asset-management ingestion. For each link, state the direction of data flow, the transport (API, syslog, connector), and what decision the receiving system makes with it.