Industrial Data Diode Selection for Thai Factories: A Practical OT-to-IT Guide

When selecting an industrial data diode for a factory, start with the data flow, not a product name. Which production data must leave OT, where will it go, and does any step require information to come back? Thai factories often want equipment data in headquarters systems, quality applications, or cloud analytics without opening another route into controllers. This guide explains where an OT-to-IT one-way boundary fits, what OPC UA and MQTT really require, and how to write an RFP and FAT/SAT acceptance plan.

First decide the direction of the industrial data diode

NIST defines a data diode as a device that permits data to travel in only one direction. Products differ in their optical hardware, software adapters, and protocol conversion. The buying decision, however, begins with the same question: can the intended boundary be OT→IT with no return network path? A firewall rule that allows selected traffic and a physically one-way link demand different evidence in design, testing, and operations. In an RFP, separate the component that enforces direction from the software that collects or replicates data. See the NIST data diode definition.

Do not confuse “we need data out” with “we never need instructions in.” Equipment status, alarms, quality measurements, and maintenance logs may be suitable exports. PLC parameter changes, recipe downloads, interactive remote maintenance, and alarm acknowledgement from an upstream application cannot use that same OT→IT link in reverse. Draw the actual business process step by step to identify every return transaction.

NIST SP 800-82 Rev.3 discusses one-way gateways as an alternative at some OT boundaries while asking designers to account for OT safety, reliability, and performance. It does not say a diode eliminates every OT risk. Endpoints, removable media, local privileges, and change control still matter. Across Thai plants, check each site’s control requirements before standardising a design. NIST SP 800-82 Rev.3

*Orange arrows show blocked attempts in the reverse direction, not an approved return data route.*

Workflows that fit, and workflows that need another route

“Visible from IT” and “controlled by IT” are separate requirements. If both are called “data integration,” the conflict may emerge only during testing. In the first workshop, list for each screen and API what it reads, what it writes, who initiates it, and what operators do during an outage. This makes the export-only part visible.

Where should the OT-to-IT boundary sit in a Thai factory?

Map existing connections from sensors and PLCs, through SCADA and historians, to plant IT, enterprise IT, and cloud. The boundary need not sit next to the lowest-level machine. An existing historian or collection server may normalise data before export and reduce PLC changes. Conversely, aggregating every line behind one gateway may enlarge the impact of a collection failure. Choose the placement with production consequences in view.

Keep real-world exceptions on the drawing: vendor support links, files carried by USB, time synchronisation, antivirus updates, and backup restoration. If another bidirectional route reaches the same OT zone, the zone is not wholly isolated by the diode. Define exactly which path the diode protects and which paths remain. This avoids a false sense of completeness.

For plants with separate buildings or lines, specify the cabinet, power, rack, fibre route, spare unit, and after-hours replacement procedure. Assign responsibility between maintenance and IT before installation. Check whether new collection polling adds load to an OT network or device.

What belongs in the data-flow register?

Use one row per flow: source system; tag or file; meaning and unit; event-time rule; acceptable delay; missing-data treatment; OT-side acquisition; transfer format; IT destination; retention; owner. A temperature value without measurement ID, unit, timestamp, and quality flag may be unusable in analytics. Acceptance must test meaning, not merely connectivity.

“Real time” means different things to a machine dashboard and monthly quality analysis. Have plant owners approve an update interval and recovery time for each use case. Then size transfer, buffering, and replay. A published appliance bandwidth figure is not a guarantee of your data quality or end-to-end recovery.

How OPC UA and MQTT work across a one-way boundary

In the usual OPC UA client/server model, a client connects to a server, requests reads or subscriptions, and receives responses. That dialogue cannot simply be passed unchanged over a physically one-way link. A practical design may put a client on OT to read the OT server, transfer selected data outward, and build a replica server or receiving application on IT. IT clients connect to the replica. Waterfall’s OPC UA Data Access brief describes such a source-client and destination-replica arrangement. It is one vendor implementation, not a feature guaranteed in every product.

OPC UA PubSub is a different model. The OPC Foundation Part 14 specification defines publishers, subscribers, datasets, and broker-based mappings including MQTT. It is wrong to say either that all OPC UA requires a bidirectional boundary or that PubSub works automatically through any diode. Check the exact supported profile, encoding, metadata, security mode, and configuration-change method. Show OT publisher, transfer adapter, and IT subscriber or broker as separate components.

MQTT also needs care. A normal MQTT connection to a broker uses two-way connection management and acknowledgements. “Connect the MQTT packet to the optical one-way fibre” is not an implementation plan. A gateway may receive data on its source side, package it for one-way transfer, and republish it to an IT-side broker; other adapters are possible. Owl Cyber Defense’s cloud gateway description discusses MQTT and other protocols in its own product architecture. Demand a test with your data and destination broker.

*Orange arrows show blocked attempts in the reverse direction, not an approved return data route.*

Do not select by protocol name alone

A one-way data path can coexist with a human two-way change process. IT may request a new tag through a ticket; OT approves and configures it locally. Do not describe that as an automatic configuration command travelling backward through the diode. Document technical transfer and human change control separately. For adjacent protocol decisions, see our guides to OPC UA cloud integration and MQTT Sparkplug B implementation.

Comparing a data diode with a firewall

The choice is wider than “which is safer?” A firewall controls permitted communications by rules and can support justified two-way processes. A one-way gateway is designed around the absence of a return network route at that boundary. It can suit passive export, but it cannot replace the return path needed by some operations. Many plants assign different roles to both at different boundaries.

Assess availability, integrity, and operational workload alongside security. A one-way link can prevent traffic on that link from returning from IT to OT. It cannot correct corrupt data generated inside OT, a bad sensor, or collector defects. Nor does it automatically classify or protect confidential data leaving OT. Translate marketing claims into the specific boundary, test evidence, and remaining routes relevant to your plant.

Compare complete scope: appliances, servers or VMs on both sides, licences, adapters, fibre, spares, monitoring, maintenance, FAT/SAT, shutdown work, and later tag additions. Prices depend on scope and configuration, so a generic figure is not useful here. Align bidders on the same bill of work and separate capital and recurring costs.

Define exactly what “one way” proves

An RFP can request a physical and logical diagram, plus a test showing no IT→OT signal path through the defined transfer link. The exact test depends on the product. A certificate name alone does not cover management ports, service lines, failover links, or another network path. Draw where administrators connect to each device and how those sessions are controlled.

“Supports OPC UA” or “supports MQTT” is not a promise of every protocol feature. Specify needed data types, certificates, encryption, reconnection behaviour, client counts, and semantics. The Waterfall replica and Owl cloud-adapter examples show how much the surrounding software can differ even when both advertise one-way transfer.

RFP requirements you can adapt

Begin with the protected boundary and handoff, not a model number. Supply plant and line scope, present OT/IT diagram, maintenance window, and existing OPC UA, MQTT, and historian versions. Give equipment teams, integrators, and bidders the same baseline.

Separate mandatory from optional requirements. Mandatory items might include no IT→OT flow through the specified boundary, preservation of defined data meaning, no adverse effect on control during gateway failure, fault detection, and event logs. Optional items might include dashboards or future expansion. For a cloud use case, ask whether cloud credentials need to sit near PLCs at all, or whether OT acquisition and IT/cloud transmission can be separated.

RFP checklist with vendor response fields

For “maximum tags” or “throughput,” inspect both catalogue figures and the conditions behind them. Refresh rates, payload size, buffer, conversions, encryption, and redundancy change the usable capacity. Measure representative plant data, then attach test conditions. Arbitrary generic figures can cause over- or under-sizing.

In Thai procurement, an English design document and local maintenance instructions may change at different times. State deliverable languages, diagram format, operator instructions, support contacts, and where spares live. Headquarters security approval does not replace the plant OT owner’s approval of how production continues during an outage.

What FAT and SAT should accept

Factory acceptance testing (FAT) checks transformation and failure behaviour in an actual or representative setup. Site acceptance testing (SAT) repeats the needed evidence with installed cable, power, destinations, and operations. A value appearing on a dashboard is insufficient. Check that source and destination mean the same thing, a stopped flow is noticed, and any missing interval can be explained after recovery.

Prepare more than normal sample values: disconnection, bursts, renamed tags, null or bad-quality data, and clock differences. For OPC UA compare value, quality, and time together. For MQTT compare topics, payloads, retries, and duplicates. For historians test recovery after an extended outage. Automatic historical backfill is not universal; purchase it explicitly if required.

*Orange arrows show blocked attempts in the reverse direction, not an approved return data route.*

Example acceptance cases

Attach a measurement method and evidence to each criterion. Replace “low latency” with a permitted delay per dataset, start/end measurement points, and a clock-synchronisation method. Replace “no lost data” with outage duration, buffer capacity, replay period, and a gap indication. Set any contractual numbers from your process and measurements, not from a general article.

SAT should also cover spare parts, after-hours calls, power restart, account handover, and configuration restore. Test reverse-path blocking alongside a review of other routes into the same OT segment. Plant personnel must approve a safe test method that does not overload controllers or issue unintended commands.

Redundancy, recovery, and maintenance limits

A one-way boundary does not supply availability automatically. An OT collector, link, IT republisher, historian, or broker can each stop and leave stale data upstream. Monitor normal, delayed, stopped, and recovering states, and expose the timestamp of the last valid update. A stale value displayed as if current can be more harmful than an obvious outage.

If redundancy matters, specify which components are doubled. Two fibres cannot compensate for one failed source server. If a destination broker stops, receiver buffering may be decisive. A failover can also duplicate events; define a deduplication key such as event ID or a combination of equipment ID and time. If the business requires exactly-once processing, test through the application, not merely at the link.

Plan patches and certificate renewals. If IT cannot send update files into OT through this boundary, an approved local import process is needed. Removable media require scanning, records, and custody. If a temporary two-way maintenance connection is opened, control its approval, start, end, and logs; do not describe the site as continuously one-way during that period.

Treat a new tag, renamed tag, changed value range, or new cloud topic as a formal request. Adding an IT destination may change OT polling load or information classification. Assign requester, approver, implementer, tester, and operator, then verify data after each change. Our OT security RFP guide offers a wider procurement context.

Start with a small proof of concept

Instead of moving every tag at once, choose one useful path: for example, run/stop state and quality results from one line to a plant IT receiver. Reconcile original values, received values, update times, and outage logs. Ask the plant user whether the result supports a real decision. The proof of concept should reduce uncertainty about boundaries, data meaning, recovery, and ownership, not merely produce an attractive dashboard.

Fix device and software versions, OT endpoints, network changes, test duration, and rollback conditions before the trial. If SAT differs from FAT, log the differences and retest what they affect. For cloud export, classify data and permissions before transmission; one-way flow does not itself restrict who can read the outbound information.

Bring maintenance, production, quality, IT, procurement, security, and the integrator into the decision. Agree who uses the data, who responds during a live outage, and who pays for changes. Between a Thai plant and Japanese headquarters, clarify local execution authority and approval authority in writing.

Approving workflows that still need the reverse direction

The difficult part of a one-way design is often not routine data collection but an occasional reverse-direction task: a new recipe, vendor parameter change, security patch, certificate, time-setting change, or alarm acknowledgement. If a rare task disappears from the requirements register, an informal bypass may emerge after go-live. Record who introduces what information to which OT asset and when. Separate the link that is technically blocked from the separately approved procedure that performs necessary changes.

Not every inbound change requires a network connection. A local operator can apply an offline-approved file from controlled media. Media are not automatically safe: define provenance, malware scanning, hash checks, custody records, backups before and after application, dual approval, and rollback. For a managed network route, specify permitted hours, destinations, authentication, action logs, and who can terminate an emergency session. Treat this as a distinct controlled process rather than an undocumented exception to the diode.

Alarm acknowledgement illustrates the difference. Sending an alarm event OT→IT and sending a human acknowledgement back to alter an OT alarm state are separate flows. Marking an alert as “read” only within IT may need no return path. Changing a control-system acknowledgement state does. State exactly which meaning the RFP and FAT cover, especially where operators rely on the display in an emergency.

Summarise the final decision on one sheet

At the final bidder review, fill in this matrix instead of comparing product brochures alone. Mark each item compliant, conditionally compliant, unverified, or noncompliant. Record added software or procedures for conditional results and the FAT evidence needed for unverified results. Do not turn “unverified” into “compliant.”

This matrix checks both whether the device works and whether the plant can keep using it. A proven one-way link is insufficient if an upstream screen presents stale values as current. Excellent data quality is insufficient if nobody can recover a failure overnight. Record the evidence that the plant owner used to approve the rollout.

FAQ: industrial data diode selection

Q1. Does a data diode make a firewall unnecessary?

No. It addresses reverse communication through a specific boundary. OT segmentation, management ports, justified two-way connections, and IT-side access may need other controls. Define each role on the full plant connection diagram.

Q2. Can an existing IT OPC UA client still connect directly to the OT server?

Do not assume an interactive client/server session will pass unchanged across a physical one-way link. Assess a vendor-supported source collector and IT replica. Test node scope, quality, time, certificates, and change synchronisation.

Q3. Does MQTT become one-way through configuration alone?

A normal broker connection exchanges messages in both directions. A diode architecture needs adapters or brokers on the appropriate sides. Test topics, QoS, reconnection, duplication, and security with actual data.

Q4. Can headquarters send recipes or settings into the plant?

Not through an OT→IT-only link in the reverse direction. Design a separate approved route or procedure, such as controlled media, another managed connection, or a local change process.

Q5. How should we compare implementation cost?

Request the same scope for hardware, collection and replication software, adapters, both-side servers, fibre, FAT/SAT, support, and later tag additions. Include shutdown and recovery constraints. Unscoped headline prices are misleading.

Q6. Will production stop if the diode fails?

It depends on architecture. A monitoring replica can be designed so its failure does not stop the control loop, but collection load and dependencies on upstream information still need assessment. Test sender failure and recovery and approve the plant’s continuity procedure.

Conclusion: define the data and acceptance test before buying

Separate information exported OT→IT from operations that must return IT→OT. Then specify data meaning, protocol endpoints, the exact proof of one-way transfer, replay after failure, and FAT/SAT pass criteria. This turns a product comparison into a design the plant can approve. Give reverse-direction operations a distinct, controlled design and procedure.

If your Thai factory is still drawing its data-flow diagram or RFP, we can help start from the existing OPC UA and MQTT setup and the data your teams actually need. Contact TOMAS TECH.

References

• NIST, Data Diode Glossary
• NIST, SP 800-82 Rev.3 Guide to Operational Technology Security
• OPC Foundation, OPC UA Part 14: PubSub
• Waterfall Security, Waterfall for OPC UA Data Access
• Owl Cyber Defense, Secure Connections to the Cloud
• OPSWAT, MetaDefender Optical Diode