Why This Matters for OT Engineers

If you operate data diodes in your plant, refinery, water treatment facility, power grid, or transportation system – this article is for you. It is not a sales pitch for a replacement product. It is a practical examination of five scenarios where diode-based connectivity creates operational friction, and what those scenarios reveal about modern OT architecture.

You already know the diodes work. You installed them. You signed off on the security architecture. They eliminate inbound traffic at the physical layer. They satisfy auditors. They produce documentable compliance evidence for NERC CIP, NIST SP 800-82, IEC 62443, and similar frameworks. None of that is in dispute.

What is in dispute – increasingly, across OT environments worldwide – is whether the diode-only architecture still matches the operational reality of 2026. The connectivity scenarios that defined OT environments when diodes were originally deployed (typically 2010-2018) are different from the scenarios you operate today. Vendors expect remote support. CVEs require faster patching. Cloud analytics require bidirectional data flows. IIoT devices need management connectivity. Incident response requires investigators to access OT systems quickly.

This article documents five specific scenarios where the operational gap between “what the diode allows” and “what the work requires” is widest. For each scenario, the article explains the operational limitation, the workarounds that typically emerge, and the architectural concept that addresses the limitation without sacrificing the diode’s strengths. The article ends with practical guidance for OT engineers evaluating their current state.

How Data Diodes Actually Work (And What That Means in Practice)

Before documenting limitations, a brief refresher on what makes diodes structurally different from other security controls.

A data diode is a hardware device that enforces unidirectional data flow at the physical layer. Optical hardware (typically) physically prevents reverse data flow – even at the Layer 1 electrical level. The diode is not a firewall with an allow-only-outbound rule. It is a physical structure where reverse flow is electrically impossible.

This produces three operational properties OT engineers know well:

Direction is fixed at the hardware level. You cannot configure a diode to permit a specific reverse flow temporarily. The hardware does not support bidirectional operation. A vendor request to “just allow this one inbound connection for the firmware update” is structurally impossible to honor.

Protocol support is limited to one-way protocols. UDP-based syslog, OPC UA write-only configurations, file transfer protocols configured for one-way operation, custom one-way data formats. TCP-based bidirectional protocols (SSH, RDP, HTTPS, modern API calls) cannot operate through a diode without architectural workarounds (proxies, store-and-forward gateways, replicated databases) that typically defeat the purpose.

Operational rigidity is the trade-off. The structural impossibility of reverse flow is the security property that makes the diode valuable. It is also the operational limitation that makes the five scenarios below problematic. The diode does not have a “mostly unidirectional with exceptions” mode. It is unidirectional, period.

These properties are real and useful for the use cases the diodes were designed for – typically OT-to-IT data flows where data needs to leave the OT environment but no inbound traffic is required. The scenarios below are the ones where the use case has evolved beyond these design parameters.

Scenario 1: Vendor Remote Support That Cannot Happen

The scenario every OT engineer has lived: a piece of equipment behind the diode needs vendor support. A PLC firmware update from Siemens, Rockwell, or Schneider. A SCADA system patch from AVEVA or GE. A turbine control system tuning from Emerson. A process simulation calibration from Honeywell. The vendor’s support engineer has a specific procedure documented. The procedure assumes remote connectivity – that’s how the vendor supports their product worldwide.

The diode says no. The procedure cannot run as documented.

What happens next typically follows one of three paths:

Path A: The vendor sends a person on a plane. This is the documented “secure” approach. The vendor support engineer flies to your site, sits at a workstation, and performs the work that should have taken 90 minutes remotely. With travel, on-site time, and post-visit documentation, the work consumes 1-3 days of the engineer’s time and your team’s coordination time. For sites with multiple vendor relationships and routine maintenance schedules, this consumes a substantial portion of operational budget – industry data points to mid-sized water utilities spending $200,000-$500,000 annually on vendor travel for what would otherwise be remote work.

The compliance position is clean. The operational position is expensive and slow. The threat schedule does not respect your travel budget – when a critical CVE drops, the patch waits for the next scheduled vendor visit. Industry research documents an average of 180 days from CVE publication to OT patch deployment, with diode-protected environments typically at the slower end of that range.

Path B: A separate VPN gets stood up. The vendor’s commercial reality requires remote access. Your operations team needs vendor support to keep equipment running. So an “exception” architecture appears in the DMZ – a VPN concentrator, jump server, or vendor portal that the vendor connects to. The diode is still in place for its original use case. The VPN is now in place for the vendor use case. Two security boundaries with different control properties exist. The architecture document documents both, but the architecture diagram increasingly resembles a graph of historical decisions rather than a coherent security model.

The compliance position is now mixed. The diode’s clean unidirectional guarantee is preserved for the data flows that go through it. The VPN’s security depends on configuration, patching, and the assumption that the vendor’s connection is what it claims to be. CitrixBleed (CVE-2023-4966) and CitrixBleed 2 (CVE-2025-5777) demonstrated what happens when that assumption fails – the VPN concentrator becomes the entry point for compromise that affects everything reachable from the VPN, including OT systems if the VPN was deployed for OT vendor access.

Path C: USB drives. When neither remote access nor on-site visits are practical, files move on physical media. Firmware updates carried on USB drives. Configuration backups exported to portable storage. Diagnostic data collected on removable media. The diode is preserved. The supply chain attack vector that air-gapped environments were designed to prevent is reintroduced through the personnel and removable media that bridge the gap.

The compliance position depends on how rigorously the USB media handling procedure is documented and followed. The operational reality is that USB-based file transfer is slower, more error-prone, and harder to audit than electronic transfer through a controlled architecture.

What the scenario reveals: the diode’s unidirectional guarantee is not the problem. The lack of an alternative architectural pattern for bidirectional vendor communication is the problem. The vendor work needs to happen. If the diode-only architecture cannot accommodate it, the work happens through workarounds that typically degrade the security posture more than a properly designed bidirectional architecture would.

Scenario 2: Firmware Updates the Diode Cannot Deliver

The scenario: A critical CVE affects controllers on your OT network. CISA publishes the vulnerability with a 21-day patching deadline under the Known Exploited Vulnerabilities catalog. The vendor releases a patch within 7 days. Your responsibility is to get the patch onto the controllers before the deadline.

The diode says no. The patch cannot reach the controllers through the unidirectional flow.

What happens next:

The patch waits for the next scheduled maintenance window. Quarterly maintenance windows are typical. The CVE published Tuesday gets patched in 60-90 days. The 21-day deadline passes. The audit will document this. The CISO will get a question from the board. The vendor’s account manager will note the slow patching cycle.

Or: an emergency vendor visit gets scheduled. Same cost structure as Scenario 1, with the additional pressure of an emergency timeline. Travel costs go up because of expedited booking. Internal coordination costs go up because of compressed scheduling.

Or: the patch gets deferred indefinitely. Risk is documented in the risk register. Compensating controls are documented (the diode itself is one). The audit accepts the documentation. Three years later, an attacker exploits the now-three-year-old CVE, and the post-incident review documents the patching gap that was known and accepted.

What the scenario reveals: in 2014, when patching cycles ran on quarterly schedules and CISA had not yet established the KEV catalog with specific deadlines, the diode-and-physical-visit model was operationally adequate. In 2026, CISA KEV catalog deadlines, NERC CIP-007 patching requirements, IEC 62443’s vulnerability management expectations, and cyber insurance underwriter scrutiny all assume patching cadences measured in days or weeks – not quarters. The architectural assumption embedded in the diode-only approach has not changed. The compliance and threat environment has.

A practical examination of why physical-only OT maintenance creates compliance gaps that diode-based architectures cannot close documents the patching cadence problem in operational detail with cost data and compliance impact.

Scenario 3: Bidirectional Data Flows the Plant Actually Needs

The scenario: Modern operations require bidirectional data exchange between OT and IT.

• Historian data flows OT-to-IT for analytics.
• Production schedules flow IT-to-OT for operational coordination.
• Quality data flows OT-to-IT for reporting and continuous improvement.
• Recipe management flows IT-to-OT for batch operations.
• Asset management flows bidirectionally for maintenance planning.
• Alarm data flows OT-to-IT for SOC and operations awareness.
• Acknowledgment data flows IT-to-OT when SOC analysts confirm events.

The diode handles the first item in each pair. It cannot handle the second.

What happens next:

Two diodes get installed (one each direction). This is the architecturally cleanest workaround. Hardware costs double. Audit scope doubles. Synchronization between the two paths becomes its own operational concern. The architecture preserves the unidirectional guarantee in each direction, but the operational reality is two separate one-way pipes that need to coordinate.

Or: a reverse path gets added through a different mechanism. Often this is a VPN, jump server, or vendor portal that handles the reverse direction. The diode is now part of an architecture that includes inbound flow. The compensating control argument – “the diode handles the unidirectional path” – no longer covers the entire boundary.

Or: the bidirectional data simply doesn’t flow. Production schedules don’t reach the OT side automatically; they get re-entered by operators reading from IT-side reports. Recipe management doesn’t push from IT; recipes are loaded manually at the HMI. The plant runs on parallel data sets that engineers manually reconcile. This is the scenario most often described as “the diode is the security boundary, and that’s the cost.”

What the scenario reveals: the diode was designed for use cases where data needs to leave the OT environment but no inbound flow is required. In 2026, almost no OT environment fits this description anymore. Modern plants require bidirectional data flow as an operational requirement, not as a security exception. The architectural pattern that handled the unidirectional case structurally cannot handle the bidirectional case without workarounds. A practical examination of the Zero Trust application of the Purdue Model and bidirectional connectivity at the Level 3-4 boundary documents how bidirectional flows integrate with traditional zone-and-conduit segmentation.

Scenario 4: IIoT Devices and Cloud Analytics That Need Two-Way Communication

The scenario: Your operations team has been evaluating IIoT-based predictive maintenance. The vendor’s platform is cloud-hosted. Sensors deploy on equipment, send telemetry to the cloud, receive analytics-driven configuration updates back. The platform’s value proposition depends on the bidirectional flow – sending data is half the story; receiving recommendations and configuration updates is the other half.

The same applies to:

• Vendor cloud services for equipment monitoring (Siemens MindSphere, GE Predix, Rockwell FactoryTalk Hub, etc.)
• Cloud-based SCADA or historian services
• Cloud-based asset performance management platforms
• IIoT gateways that aggregate sensor data and require management connectivity from cloud orchestrators
• Edge computing platforms with cloud control planes

The diode breaks all of these.

What happens next:

The cloud service runs on-premises instead. The IIoT vendor’s analytics platform gets deployed inside the diode’s protected zone, eliminating the cloud architecture’s benefits (scalability, automatic updates, vendor-managed feature evolution). Operations get a degraded version of what the vendor designed.

Or: a parallel network gets set up outside the diode. IIoT devices deploy on a separate network that bypasses the diode’s scope. Segmentation gaps appear in the architecture. The diode protects what it always protected, but the OT environment now has IIoT-connected equipment outside the diode’s coverage.

Or: the IIoT initiative gets scoped down. What was supposed to be a comprehensive predictive maintenance program becomes a manual data-export process where engineers periodically dump data, send it to the vendor, and review reports days later. The real-time, bidirectional value proposition is lost.

What the scenario reveals: NIST SP 800-82 Revision 3 explicitly acknowledges this scenario, adding new sections on IIoT and cloud-based OT analytics that earlier revisions did not contain. The framework documentation has caught up with the operational reality. The diode-only architecture has not. The diode does not have a configuration mode that supports bidirectional cloud connectivity – it would require structural changes to the hardware that diodes by definition cannot provide.

The identity-based segmentation approach that NIST SP 800-82 Revision 3 references through its Zero Trust integration extends the zone-and-conduit principles to workload identity as a primary segmentation attribute – a model that handles IIoT devices that traditional IP-based segmentation struggles with.

Scenario 5: Incident Response Where the Investigators Cannot Reach the Evidence

The scenario: An anomaly appears in your OT environment. SOC analysts see indicators of compromise on the IT side. The incident response team needs to investigate the OT side – collect logs, examine controller configurations, validate that OT systems are clean, deploy investigation tools.

The diode says no. The investigation team cannot reach the OT-side evidence remotely.

What happens next:

Investigators travel to the site. This is the documented incident response procedure for diode-protected environments. The investigation timeline extends from hours to days. The Dragos 2026 report documented that organizations with comprehensive OT visibility detect incidents in 5 days while industry average is 42 days – and the investigation timeline extension behind diodes contributes meaningfully to the gap.

Or: emergency VPN access gets stood up. During the incident, an exception VPN gets deployed to allow investigators OT-side access. The VPN is removed after the incident. The architecture’s documented design (no inbound flow to OT) is temporarily violated for the incident duration. The compensating controls during the exception window are typically less rigorous than they would have been if planned access had been designed in advance.

Or: investigation continues without OT-side access. The team works from IT-side evidence and OT-to-IT data exports. The investigation may miss persistence mechanisms on OT controllers, secondary infections, or root cause information that requires direct OT-side access to discover. The post-incident review documents the investigation gap.

What the scenario reveals: the diode was designed for steady-state OT operations. Incident response is not steady-state. It requires temporary, controlled, identity-attributed access to evidence – typically with full session recording for chain-of-custody purposes. The diode does not have an “incident response mode.” Its security guarantees come from being structurally unable to permit reverse flow under any circumstances. That same property is what makes it incompatible with effective incident response. A practical guide on stopping lateral movement at the IT-OT boundary during incident response documents the detection and containment patterns that effective bidirectional visibility makes possible during active incidents.

What These Five Scenarios Have in Common

Each of the five scenarios shares the same underlying pattern: a legitimate operational requirement exists that the diode-only architecture structurally cannot accommodate. Workarounds emerge that either degrade the security posture or degrade the operational outcome. The audit documents the pattern. The risk register documents the gap. The actual security and operational state diverge from the documented design.

The pattern is not the diode’s fault. The diode does what it was designed to do. The pattern emerges because the use cases that defined OT environments when diodes were deployed (typically 2010-2018) are different from the use cases that define OT environments today. Vendor support has shifted to remote-first. CVE patching deadlines have compressed from quarterly to weekly. Cloud analytics has shifted from on-premises to bidirectional cloud. IIoT has emerged as a primary connectivity pattern. Incident response has become time-critical.

The architectural question OT engineers face in 2026 is not “should we keep the diodes.” It is “what handles the use cases the diodes were never designed for, in a way that complements the diode’s strengths rather than undermining them.”

What an Architectural Alternative Looks Like

The architectural pattern that addresses the five scenarios shares specific properties with the diode (zero inbound exposure) while adding capabilities the diode structurally cannot provide (bidirectional flow, identity attribution, content inspection, session recording).

The pattern’s core mechanism: the connection direction is reversed.

Instead of a device on the IT side initiating a connection to an OT-side service (which requires an inbound port), a device on the OT side initiates a connection to a Gateway in the DMZ or cloud. The connection is encrypted, mutually authenticated, and persistent. The Gateway brokers authorized traffic to the internal device. From the OT network’s perspective, no inbound port is open – every connection originates from inside, going out.

This architectural property – zero inbound ports on the protected network – is the same property the diode provides. The mechanism is different. The result for inbound exposure is identical: the OT network has nothing to scan, nothing to find, nothing to exploit.

Where the architecture differs from the diode: the same connection that carries OT-to-IT data can also carry IT-to-OT data, with content inspection (Content Disarm and Reconstruction) on every file, identity attribution (named accounts with per-session MFA) for every operation, and session recording (video and keystroke logs) for every interactive session.

The five scenarios get addressed:

• Scenario 1 (vendor remote support): vendors connect through the Gateway with named accounts, MFA, time-bounded sessions, and full session recording. The work happens remotely. Audit evidence is identity-attributed.
• Scenario 2 (firmware updates): patches reach controllers on the threat schedule, not the maintenance schedule. CDR rebuilds firmware files before they reach OT systems.
• Scenario 3 (bidirectional flows): the same architecture handles both directions. No need for two diodes or VPN-plus-diode hybrids.
• Scenario 4 (IIoT and cloud analytics): cloud-based platforms connect through the Gateway with the same controls. IIoT devices deploy within the protected network.
• Scenario 5 (incident response): investigators get controlled, time-bounded access during incidents. Session recording provides chain-of-custody evidence.

The platform that delivers this pattern in a single deployment is the truePass Gravity configuration, with three integrated layers – Reverse Access (zero inbound ports), Heimdall SMB Proxy with CDR (content inspection on file transfers), and Zero Trust Application Access with session recording. The three layers map to the five scenarios as a complete architectural answer rather than as supplementary products bolted onto generic ZTNA.

The broader truePass platform extends this approach across IT and OT environments, providing unified policy and audit across the connectivity types that fragmented architectures struggle with.

Coexistence: What Happens to the Diodes

A practical question OT engineers ask: does this architectural shift mean removing the diodes?

The answer is no – and the deployment pattern that produces the best outcome typically retains diodes for the use cases they handle well.

Keep diodes for the OT-to-IT one-way flows they handle well. Historian data export, log forwarding, monitoring data egress, alarm data flows that genuinely don’t require acknowledgment paths. The diode’s structural unidirectional guarantee is real and useful for these flows.

Add the complementary architecture for the five scenarios. Vendor maintenance, patching, IIoT integration, bidirectional flows, incident response. The new architecture handles these scenarios with identity-attributed controls and full audit evidence.

Run them in parallel with consistent audit evidence. Both architectures export to the same SIEM with consistent identity attribution where applicable. The audit conversation becomes “we have layered architecture for cross-boundary connectivity” rather than “we have a diode and some workarounds we don’t talk about.”

Make the diode decision per-flow, not per-architecture. Different OT-to-IT flows have different requirements. Some genuinely need only one-way flow with maximum assurance – the diode handles those. Some need bidirectional flow with identity attribution – the new architecture handles those. The decision is data flow by data flow, not architecture-wide.

A guide on replacing multiple OT security vendors with a single Zero Trust platform documents the consolidation pattern that emerges when fragmented architectures (diode + VPN + jump server + file transfer + session recording + monitoring) get reorganized around a single connectivity platform.

What OT Engineers Should Take Away

If you operate diodes today, you are not behind. The diodes were the right answer to the question that was being asked when they were deployed. The question has changed.

Three takeaways for engineers evaluating their current state:

Map your scenarios. Walk through the five scenarios in this article and identify which ones currently produce operational friction in your environment. For each, document how the work happens today – physical visits, exception VPNs, USB drives, parallel networks, deferred work. The map of current workarounds is the map of where the architectural gap is widest.

Calculate the cost. Each workaround has a cost. Vendor travel budget. Internal coordination overhead. Patch latency exposure. IIoT initiatives that didn’t deploy. Incident response timelines. Most OT engineers find the actual cost is higher than the budget line because the costs distribute across multiple departments. The architectural conversation with management gets easier when the cost is documented.

Understand the architectural alternative. The pattern that addresses the five scenarios is not “remove the diodes and install VPN.” It is “preserve the diodes for what they do well, add identity-attributed bidirectional connectivity for what diodes cannot do.” The pattern has a specific name (Reverse Access architecture) and specific properties (zero inbound ports on protected networks). It is not a marketing description of better firewalls.

A foundational guide to Zero Trust Network Access fundamentals applied to OT environments provides the architectural framework that connects the five scenarios to the broader Zero Trust principles that NIST SP 800-82 Revision 3 now references.

Frequently Asked Questions

Are data diodes obsolete?

No. Data diodes provide a structural unidirectional guarantee that no software-based control matches. For genuinely unidirectional use cases (OT-to-IT data export, log forwarding, monitoring egress), they remain the strongest available control. They are not obsolete – they are no longer a complete architecture by themselves.

Doesn’t a “Reverse Access” architecture just reintroduce inbound traffic?

No. The “reverse” in Reverse Access refers to the connection initiation direction, not the data flow direction. Internal devices initiate connections outward. The protected network has zero inbound ports. Bidirectional data flows over the connections that were initiated from inside. From the network’s perspective – which is what attackers can see and scan – the network has nothing to attack. The architecture preserves the diode’s “no inbound exposure” property while enabling bidirectional data flow.

How is this different from a firewall with outbound-only rules?

A firewall with outbound-only rules typically has services running on the protected side that the firewall protects. The services are still listening; the firewall just blocks inbound packets to them. If the firewall fails (misconfiguration, vulnerability, policy gap), the services are exposed. Reverse Access architecture has no listening services on the protected side. There is nothing for an attacker to reach if they bypass the firewall – the connection is initiated from inside, and the protected device only responds within an established outbound session.

What about NIST SP 800-82 compliance?

NIST SP 800-82 Revision 3 (2023) explicitly references Zero Trust architecture (NIST SP 800-207) as a complementary pattern to traditional segmentation. The framework supports the architectural model described in this article. The practical compliance position is that the diode plus the bidirectional architecture together produce stronger evidence against the SP 800-82 Revision 3 control set than either alone – particularly for the AC (Access Control), AU (Audit and Accountability), and SI (System and Information Integrity) control families.

Is this an enterprise IT solution being marketed for OT?

No. The architectural pattern described in this article was specifically designed for cross-network OT environments – including the Heimdall SMB Proxy with Content Disarm and Reconstruction layer that handles the file transfer use cases (firmware updates, configuration files, project files) that distinguish OT from typical IT. Enterprise ZTNA platforms designed for IT applications typically lack this capability or offer it as a separate product.

How long does deployment typically take?

For a typical mid-sized OT environment with 6 sites and 40+ controllers, parallel deployment alongside existing diodes takes 4-6 weeks. Migration of the highest-priority scenario (typically vendor maintenance) takes another 4-6 weeks. Full migration of all five scenarios takes 16-20 weeks. The diodes remain operational throughout.

What if my organization has strict air-gap requirements?

True air-gapped networks (no electronic connectivity to other networks under any circumstances) are not in scope for this architecture. The five scenarios assume connectivity exists or is required. For air-gap-strict environments, the architecture does not apply. For environments with air-gap-as-default plus exception-based connectivity (which describes most modern OT environments), the architecture provides the controlled connectivity that exception cases require.

Conclusion

Data diodes solved a specific problem: how to allow data to flow from a protected OT environment to a less-protected IT environment without creating an inbound attack surface. They solved it well. The structural unidirectional guarantee remains valuable.

The five scenarios documented in this article – vendor remote support, firmware updates, bidirectional data flows, IIoT and cloud analytics, and incident response – describe the operational reality of OT environments in 2026. They were not the operational reality when diodes were originally deployed. The diode’s design parameters and the modern operational requirements no longer match across the entire OT connectivity surface.

The architectural answer is not to remove the diodes. It is to add a complementary pattern that handles the scenarios diodes structurally cannot. The pattern preserves the diode’s most valuable property (zero inbound exposure on protected networks) while adding the capabilities the diode cannot provide (bidirectional flow, identity attribution, content inspection, session recording).

For OT engineers evaluating their current state, the practical path is: map the scenarios, calculate the operational cost of current workarounds, and evaluate architectural alternatives that complement the diode rather than replace it. The diodes that worked in 2014 still work in 2026 – for the use cases they were designed for. The use cases the diodes were not designed for need a different architectural answer. The architectural answer exists. It is not difficult to deploy. It coexists with the diodes you already have.

The OT environments that complete this evolution by the end of 2026 will have stronger compliance posture, faster patching cycles, lower vendor maintenance costs, more effective incident response, and clearer audit evidence than the environments that don’t. The choice is not whether to preserve what diodes do well. It is whether to add what diodes structurally cannot do.