## 5 Results and Discussion  
Table 3 outlines the contribution of our work compared to other studies within this field. As shown in this table, other studies do not perform a comparative analysis of OT-specific security devices and their individual efficacy against common attack vectors. These off-the-shelf solutions show realistic performance in relation to real-world deployments. These real-world deployments often include a mix of vendor-specific devices, legacy firmware versions, and environmental constraints such as EMI or thermal variation. While \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Protection Tested**} & \multicolumn{4}{c}{**Attacks**} \\  & **SYN-Flood** & **RST Attack** & **External Connection** & **Background Traffic** \\ \hline None & X & X & ✓ & ✓ \\ \hline \multicolumn{5}{c}{**Gateway**} \\ \hline SYN-Flood & X & X & ✓ & ✓ \\ Protection & X & X & ✓ & ✓ \\ DoS Prevention & X & X & ✓ & ✓ \\ \hline \multicolumn{5}{c}{**Security Gateway**} \\ \hline All TCP Allowed & X & X & ✓ & ✓ \\ Port-Specific & ✓ & ✓ & ✓ & ✓ \\ Filtering & \multicolumn{5}{c}{**Software-Defined Switch**} \\ \hline Static Route & ✓ & ✓ & ✓ & ✓ \\ Configuration & & ✓ & ✓ & ✓ \\ \hline \hline \end{tabular}  — Attack Prevented X — No effect.  
\end{table} 
Table 2: Effect of security features on vulnerabilities. our controlled testbed cannot replicate these factors directly, our previous works have shown that these tests reflect realistic operational topologies and threat models. Furthermore, it is not feasible for our evaluations to study long-term effects, such as device aging, on the performance metrics we are evaluating here, nor would we expect OT devices to change their networking behavior due to aging, but rather as a consequence of firmware upgrades or topology changes. Thus, given the intractable large variability of these parameters within real-world production deployments, we consider such an evaluation to be out of scope. Also, while it would be advantageous to be able to conduct our experiments on live production environments, such as actual substations, this is neither safe nor allowed in most such environments. Hence, all of our experiments were conducted in environments that closely mirror such deployments, with devices commonly found in use in such environments, and with configurations that are typically employed with them. We did our utmost best to replicate networking conditions in our controlled lab environment as we would encounter them in production environments. Thus, we posit that our test results closely mirror results we would obtain from such environments. Due to these facts, all of our results, insights, and mitigation strategies are very much applicable to actual production environments. They can be applied through firmware modifications as part of regular maintenance efforts. Our future work will test this approach in more detail through our collaborations with OT device manufacturers. We will explore remedial actions in our lab testing environment using actual OT devices and corresponding firmware revisions. Our future work will also incorporate additional high-fidelity production environment replicas through hardware-in-the-loop and emulated traffic traces. The results of our protocol review and subsequent testbed validation experiments highlight significant disparities in the resilience and responsiveness of Modbus TCP and DNP3 when subjected to communication failures. One of the primary issues identified was the impact of Modbus TCP's reliance on a single-ended communication model, which delegates all responsibility for connection re-establishment to the client. This architecture, inherited from Modbus' serial communication roots, lacks the robustness required for time-sensitive operations within modern OT environments, and was clearly illustrated by our experimental results.