Secure file transfer into OT is the problem of getting files an operator legitimately needs - patches, firmware images, antivirus and detection signatures, PLC project files, configuration backups, vendor updates - into a protected control network without giving the outside world a route back in. The data has to move inbound, but the network path it travels should not become a path an attacker can ride in the other direction.

This is harder than it sounds. The most common way to deliver an update is also the most exposed: an inbound connection, a shared mapped drive, or a USB stick carried by a technician. Each of those creates either a bidirectional reachability path or an unmanaged media channel. The goal of a disciplined inbound transfer design is to keep the file flow while removing the return path, and to inspect what crosses before it ever reaches a controller.

01Key takeaways

  1. 01

    Secure file transfer into OT means moving files inbound for legitimate work while preventing the same channel from carrying traffic back out of the protected network.

  2. 02

    Patches, signatures, firmware and engineering files all need an inbound path, which is why import is harder to lock down than the more familiar one-way export of telemetry.

  3. 03

    Removable media is the default inbound channel in most plants and is a documented infection vector, so it needs scanning, kiosks and policy, not a blind eye.

  4. 04

    Inspection matters as much as direction: content disarm and reconstruction, malware scanning and signature verification reduce the risk that the permitted file is itself the attack.

  5. 05

    A one-way inbound path with a staging and validation step lets you import files without exposing a return route, but it changes how acknowledgements, errors and retries are handled.

02What secure file transfer into OT means

Secure file transfer into OT is the controlled movement of files inbound - from an IT, vendor or internet-facing environment into a protected operational technology network - in a way that does not create a usable return path or deliver malicious content. The files are legitimate: operating-system patches, PLC and HMI firmware, antivirus and intrusion-detection signatures, engineering project files, configuration data, or vendor software packages.

The distinction that trips people up is direction. Exporting telemetry, logs and historian data out of an OT network is a well-understood one-way problem. Bringing updates in is the harder mirror image, because the destination is the high-value, high-consequence side. An inbound channel that is convenient to use is often a channel an attacker finds convenient too.

Short version: inbound transfer is about getting the file in while keeping the door closed behind it.

03Why inbound transfer is a high-risk boundary

Every file that enters a control network is a chance to deliver something unwanted. Real-world OT incidents have shown two recurring patterns: malware carried in on removable media, and lateral movement through an inbound path that was opened for a legitimate reason and never closed. The classic example is the engineering laptop or USB drive that touches both a corporate machine and a controller.

MITRE ATT&CK for ICS captures this directly. Replication Through Removable Media (T0847) and Transient Cyber Asset entry describe how files and infected media cross the boundary, and techniques such as Modify Controller Tasking and Project File Infection (T0873) show what an attacker does once a malicious file lands. The transfer channel is the on-ramp; the controller logic is the target.

  • Removable media that is shared between corporate, vendor and OT machines without scanning.
  • Inbound firewall rules or jump-host sessions opened for an update and left in place.
  • Vendor maintenance laptops connected directly to the control network.
  • Patch and signature files downloaded over an untrusted path with no integrity verification.
  • PLC or HMI project files modified to carry malicious logic before they are loaded.

04What actually needs to come in

Designing the channel starts with an honest list of what must cross. Most plants underestimate this, then build a permanent inbound tunnel to cover an occasional need. In practice the inbound payload is small, infrequent and predictable, which is exactly what makes a staged, inspected, one-way design feasible.

Patches and updates
Operating-system and application patches for HMIs, engineering workstations, historians and servers inside the OT zone.
Detection signatures
Antivirus, EDR and IDS/IPS signature and rule updates that must stay current to be useful.
Firmware images
Vendor firmware for PLCs, RTUs, switches and field devices, usually signed by the manufacturer.
Engineering files
PLC project files, HMI configurations, ladder logic and control program changes prepared offline.
Vendor software
Installers, licenses and configuration packages delivered by equipment suppliers and integrators.

Listing these flows by frequency and size is the first control. A signature update that runs daily and a firmware push that happens twice a year do not deserve the same standing connection. The rarer the flow, the more it favors a disconnected-by-default or one-way model.

05How a secure inbound transfer path is built

A defensible inbound architecture separates three steps: receive, inspect, then deliver. Files first land in an intermediate zone - a demilitarized zone (DMZ) or staging server - that is reachable from the outside. They are inspected and validated there. Only then are they moved across the final boundary into the OT network, ideally over a path that does not carry traffic the other way.

This maps cleanly onto the layered model in IEC 62443 and the Purdue-style zoning used across the industry. The outer staging zone absorbs internet and IT exposure. The inner boundary between staging and the control network is where the strongest control belongs, because that is the boundary that protects the systems that run the process.

Design rule: never let the source of a file have a direct, standing, bidirectional connection to the device that will execute it. Put a controlled, inspected staging step in between.

06Handling removable media without pretending it does not exist

Most plants still move at least some files on USB drives, and policies that simply ban removable media tend to be ignored under operational pressure. A better approach is to assume media will be used and to channel it through a controlled process. NIST SP 800-82 and CISA guidance both treat removable media as a managed asset, not a forbidden one.

  • Scanning kiosks that inspect every drive at the boundary before it touches an OT machine.
  • A single, logged, organization-issued media pool rather than personal or vendor sticks.
  • Write-protection and read-only mounting where the device only needs to deliver, not collect.
  • Content disarm and reconstruction (CDR) on documents and installers to strip active content.
  • Quarantine and verification of files before they are loaded onto a controller or workstation.

Removable media is one form of transient cyber asset, the term used in NERC CIP for devices and media that connect temporarily. The same scanning and authorization discipline applies to maintenance laptops, which are often the bigger risk because they carry their own software and network stack.

07Inspecting the file, not just the channel

Controlling direction stops the channel from being abused. It does not stop a legitimate-looking file from being malicious. Inbound transfer therefore needs content inspection as a peer control, not an afterthought. The permitted file is the thing most likely to carry the threat, because it is the thing you have agreed to let in.

Integrity verification
Check vendor digital signatures and cryptographic hashes so a patch or firmware image is provably the one the manufacturer published.
Malware scanning
Run multiple up-to-date engines against files in the staging zone before they move inward.
Content disarm and reconstruction
Rebuild documents, archives and installers to remove macros, scripts and embedded objects that scanners may miss.
Type and policy enforcement
Allow only expected file types and sources, and reject anything outside the declared inbound list.

Signature verification deserves emphasis for OT specifically. Firmware and PLC project files are high-consequence artifacts. If the only thing standing between an attacker and a controller is a file that was never checked against the vendor's published hash, the transfer channel has not done its job.

08Standards and compliance mapping

Inbound transfer touches several frameworks, and aligning the design with them makes audits and risk acceptance far easier. The relevant controls cluster around media protection, system integrity, boundary protection and change management.

NIST SP 800-82 Rev. 3
OT-specific guidance on boundary protection, removable media handling and patch management under operational constraints.
NIST SP 800-53
Control families including MP (Media Protection), SI (System and Information Integrity, including SI-3 malicious code) and SC (System and Communications Protection).
ISA/IEC 62443
Zones and conduits, plus foundational requirements covering data integrity and restricted data flow across a defined conduit.
NERC CIP
For applicable bulk electric system assets, CIP-007 patch and malware controls and CIP-010 transient cyber asset and removable media requirements.

None of these standards mandate a single product. They mandate properties: prove what crossed, prove it was inspected, prove the path is constrained, and prove the change was authorized. A good inbound design is one whose evidence you can hand to an auditor without a long explanation.

09Common pitfalls and how they undo the controls

Most inbound transfer failures are not exotic. They are convenience shortcuts that quietly reintroduce the exposure the design was meant to remove. The boundary looks intact on a diagram while a back channel runs around it in practice.

  • A temporary inbound firewall rule for a patch window that never gets removed.
  • Vendor remote access that bypasses the staging zone and reaches devices directly.
  • A management or update channel that quietly provides the return path a one-way design was meant to remove.
  • Staging servers that are themselves unpatched, dual-homed, or trusted by the OT zone more than they should be.
  • Scanning that is present but disabled, out of date, or skipped under time pressure.
  • No record of which file version reached which device, so a bad update cannot be traced or rolled back.

The recurring theme is the same one that shows up across OT security: a control is only as strong as the operating discipline around it. A one-way path with a forgotten side connection is not one-way, and a scanning kiosk that everyone walks past is not a control.

10Where one-way inbound transfer fits

A one-way path can carry data inbound just as it can outbound - the diode simply faces the other direction, transmitting from the staging zone into the OT network with no return route. This is attractive for import because it removes the inbound session, the standing tunnel and the remote-access path in one move, while still letting patches, signatures and files cross.

The trade-off is that one-way transfer breaks the feedback loop. There is no native acknowledgement that a file arrived intact, no automatic retransmission request, and no easy way to report an error back across the boundary. Real deployments handle this with forward error correction, sequence and integrity checks on the receiving side, and buffering so a momentary outage does not lose data. The workflow has to be designed for one direction rather than retrofitted onto it.

For teams weighing the options, an AIRGAPNET controlled connectivity pattern can be compared with a permanent one-way diode and with firewall-mediated staging. The deciding factors are how often files must move, how high the consequence of a malicious file is, and whether the boundary should be online by default, one-way, or disconnected except during a scheduled, supervised transfer window.

11Closing thought

Bringing files into an OT network is unavoidable. Patches expire, signatures go stale, firmware needs fixing, and engineers need to load new logic. The question is never whether to allow inbound transfer, but how to allow it without leaving an open path behind.

Start with the list of what truly must come in, route it through a staging zone, inspect the file as hard as you inspect the channel, and prefer a model where the return path simply does not exist. Convenience is what reopens the boundary, so the strongest inbound designs make the safe path the easy one.

FAQFrequently asked questions

What is secure file transfer into OT?

It is the controlled movement of files such as patches, firmware, detection signatures and engineering project files from an external or IT environment into a protected operational technology network, done in a way that does not create a usable return path and that inspects the file before it reaches a controller or workstation.

Why is inbound transfer riskier than sending data out of an OT network?

Exporting telemetry one-way is well understood because the destination is lower-value. Inbound transfer targets the high-consequence side of the boundary, so a convenient inbound channel is also a convenient entry point for an attacker. The file itself can be malicious, and the path opened to deliver it can be abused for lateral movement.

Is removable media safe to use for OT updates?

Removable media can be used safely if it is treated as a managed asset rather than banned and then ignored. That means scanning every device at a boundary kiosk, using a single logged organization-issued media pool, applying content disarm and reconstruction, and verifying files before they are loaded. NIST SP 800-82 and NERC CIP both treat media as a transient cyber asset requiring controls.

How does a one-way path bring files inbound without acknowledgements?

A one-way path faces inbound, transmitting from a staging zone into the OT network with no return route. Because there is no native acknowledgement or retransmission, deployments add forward error correction, sequence and integrity checks on the receiving side, and buffering. The workflow is designed for one direction rather than relying on a feedback loop.

Which standards apply to inbound file transfer in OT?

NIST SP 800-82 Rev. 3 gives OT-specific boundary, media and patching guidance; NIST SP 800-53 supplies Media Protection, System and Information Integrity and System and Communications Protection controls; ISA/IEC 62443 frames zones, conduits and restricted data flow; and NERC CIP-007 and CIP-010 cover patching, malware and transient cyber asset or removable media controls for applicable assets.

SRCSources of record

Close the door behind the file

Let updates in without letting attackers back.

Map every inbound flow you truly need, route it through staging and inspection, and decide whether the boundary should be one-way, firewall-mediated, or disconnected except during a supervised transfer window.

Related article

Continue the thread Removable Media Risk in OT: Why USB and Transfer Control Still Matter