Design OT-IT Connections Around Data Direction and Plant State

An analytics system is introduced to read production status. Months later, an optimization feature is added and the organization wants it to write setpoints back to the plant. A data feed has become a potential control path. Calling the original connection read-only does not protect the process. The relevant question is whether the IT recipient can create a write or control effect and in which operating state that effect is permitted. Normal acknowledgments in a read protocol are not the same as authority to control the plant.

NIST still lists SP 800-82 Revision 3 as the final OT security guide. Work on Revision 4 began with a pre-draft call for comments; there is no completed Revision 4. Revision 3 distinguishes operational technology from office IT by its direct effects on physical processes. Its performance, reliability, and safety constraints limit how a security control can be selected and operated.

Direction and the Intermediary Zone

Reading process states for quality, analytics, or production tracking does not give an IT system control authority. Write and control functions need separate, least-privilege authorization; the plant-specific architecture determines whether that also requires a physically separate path. If communication truly must be possible in only one physical direction, unidirectional gateways or data diodes are relevant technologies. A conventional firewall restricts connections but does not create the same physical property. BSI describes an OT DMZ as a transition zone between office IT and production. Intended intermediary systems exchange information while direct communication is avoided. A historian may receive ICS data in the transition zone and expose that view to office systems. Gateways translate protocols and firewalls limit communications. The correct combination remains plant-specific; the label DMZ is not evidence that the architecture works.

Exceptions deserve more scrutiny than the standard flow. Remote maintenance, recipe management, or a later optimization service should not silently add write privileges to an existing read interface. For an auditable architecture, teams can document the source, destination, protocol, permitted effect, and business purpose of each crossing. Adding control functionality then appears as a network and operating change rather than a minor application feature.

Connection Loss and Recovery

Some measurements can be buffered; others lose their business or operating meaning quickly. Before deployment, the organization should determine whether the physical process can continue without the IT connection, what the control room sees when data is stale, and how both sides reconcile after reconnecting. Successfully transporting one message does not answer those questions. On reconnect, the recipient may need rules for ordering, duplicates, and obsolete states. A backlog can arrive intact yet still be processed incorrectly if newer values are already authoritative. A plant-specific acceptance test can interrupt the connection under controlled conditions, observe both sides, and then check the restored data for plausibility. The plant's risk and safety analysis determines which tests are acceptable.

Error displays must also separate the two perspectives. An IT system can detect that updates stopped without knowing the physical cause. The control room needs more than a generic API alert; it needs to know whether displayed values are current and whether operation may continue. Technical availability and permitted plant operation are different findings.

Monitoring in Plant Context

Monitoring reveals participants and communication relationships, while anomaly detection looks for deviations from expected patterns. Maintenance windows, shutdowns, and recipe changes may alter traffic just as an unexpected connection does. Time, plant state, and approved changes therefore help interpret a signal. A deviation is a reason to investigate, not proof of an attack. BSI distinguishes active and passive collection. Active methods generate traffic and may affect sensitive, time-critical, or long-established networks. Passive sensors do not send traffic on the monitored network, although their installation may still require intervention in the network path. The team needs to know which devices or protocols are sensitive to added load or interruption and whether installation requires a maintenance window.

Frequency alone does not classify a connection. Daily remote access can remain risky if its target and privileges exceed the job, while a newly observed device may belong to approved maintenance. The inventory, change record, and current approval give the network observation its operating meaning.

Remote Access

Remote maintenance over public networks increases exposure. BSI guidance recommends placing remote-access components in a separate intermediary zone where possible and limiting access by destination and port. Individual accounts and strong authentication improve attribution. As a local operating rule, the organization can also record the target, time window, and functions needed for the work; activation, session activity, and deactivation remain traceable. Before first use, it tests who can open the path, who can independently block it, and how an interrupted change reaches a known plant state. Closing the client application is not enough at the end. The access path must be technically closed, and the work performed should not exist only in a vendor's external service log. That evidence connects the network diagram to the plant that is actually being operated.

Note: This assessment is not a substitute for a review of the specific case.