Every OT security conversation runs into the same objection, and it is a fair one: the plant cannot stop. A control system that supports water treatment, power generation, or a production line has availability requirements that make the IT security playbook unusable. You cannot patch during business hours, you cannot deploy agents onto a PLC, and you cannot take a turbine offline to test a policy change.

So OT security has historically meant separation - an air gap, or a physical data diode enforcing one-way flow. The separation works. What has stopped working is everything the business now needs to happen across it.

Why isolation alone stopped being enough

Physical unidirectionality is an absolute truth, and nothing here disputes that. A hardware diode does exactly what it claims. The problem is the growing list of operations it cannot support.

Modern operations are interactive. Engineers need RDP to a workstation, SSH to a server, an API call to a historian, a web interface on an internal application. A one-way channel carries data out. It cannot carry a session.

Vendors need to reach specific machines. OEMs and integrators maintain the equipment they sold. When the sanctioned path can't support that, the alternatives are flying an engineer to site, or opening a temporary firewall rule that outlives the maintenance window by months.

The diode sees direction, not identity. It can prove which way a bit travelled. It cannot say who sent it, whether they were authorized, or what they intended - and those are precisely the questions an auditor asks.

The workarounds become the real risk. When the approved path cannot do the job, people find one that can. USB drives cross the gap by hand. A jump host appears "just for this project." The diode remains secure while the perimeter around it quietly erodes.

Zero Trust in OT is not Zero Trust in IT

Applying the IT playbook directly to OT fails, and understanding why shapes the whole approach.

Availability outranks confidentiality. In IT, the worst outcome is usually disclosure. In OT, it is a stopped process - sometimes a safety event. Any control that risks interrupting operations to improve security has the priorities backwards.

Endpoints cannot be secured directly. PLCs, RTUs, and HMIs run firmware that cannot accept agents, often on operating systems long past end of support, and often under vendor warranties that void on modification. Protection has to come from the architecture around the device rather than from software on it.

Legacy protocols carry no identity. Modbus, DNP3, and their peers were designed for trusted serial links, not authenticated networks. Identity has to be enforced at the access layer, because the protocol itself will never provide it.

Change windows are rare and expensive. A deployment requiring re-architecture of the plant network will wait years for its window. Anything that installs without touching the existing network design is the only thing that gets deployed.

This is why NIST SP 800-82 and IEC 62443 emphasize segmented architectures with monitored boundary communications rather than endpoint-centric controls: in OT, the architecture is the control.

What good looks like at the boundary

Isolation preserved, direction preserved. Connectivity must not require the protected network to accept inbound connections. If the OT side initiates outward and never listens, there is no exposed service to scan or exploit, and the separation discipline survives.

Identity enforced where the protocol can't provide it. Every request resolved to a named person or system before it reaches anything inside, evaluated against directory, MFA, and context - not granted once at tunnel setup and trusted thereafter.

Access scoped to one machine, for one task, for a defined window. A vendor should reach the single system they are servicing, with the session recorded and access revoked automatically when the window closes.

Content inspected on the way in. Firmware updates, patches, and configuration files crossing inward should be sanitized before they land on a production system, rather than trusted because of where they came from.

Lateral movement contained after the crossing. Getting across the boundary should not mean reaching everything behind it. Segmentation inside the OT zone means a single compromised crossing stays a single compromised machine.

One audit trail across the boundary. Who connected, to what, when, what commands they ran, what files moved. Assembled automatically, not reconstructed across four products before an assessment.

How truePass Gravity does it

truePass Gravity is a software-defined diode: it keeps the separation a hardware appliance provides and adds the interactive connectivity it structurally cannot carry. Three layers work as one deployment.

Reverse Access™ - patented transport. An Access Controller inside the protected network initiates every session outbound over TLS on port 443 to an Access Gateway in the DMZ. Nothing is ever opened inward, so no inbound firewall rule exists on the OT side to scan, misconfigure, or exploit. The patents are registered in 22 countries and have been in production use in critical environments for years.

Secure SMB Proxy - controlled file exchange. Files move bidirectionally between isolated environments over the same outbound channel, with Content Disarm & Reconstruction rebuilding inbound files before they reach production systems. Shares stay hidden from enumeration, and every transfer is logged with the identity that moved it. This is what replaces the USB drive carried across the gap by hand.

Zero Trust Application Access - interactive sessions. RDP, SSH, HTTP, and API reach their destination without a network path existing between the two sides. Every request is resolved to a named identity against Active Directory and MFA, evaluated per request rather than per tunnel, and scoped to a single application. Sessions can be revoked mid-stream.

All three ride the same outbound-only path, share one policy model, and write to one audit trail. Adding interactive access or file transfer never adds an inbound port and never adds a second console.

Two properties matter particularly in OT. Deployment requires no architectural change - the platform integrates into the existing infrastructure without redesigning the network and without downtime, and automated discovery maps the environment and builds the initial configuration rather than requiring weeks of manual survey. And the platform has been validated against the conditions national infrastructure imposes: periodic penetration testing simulating state-level APT activity, and performance testing under mission-critical traffic loads with minimal latency, so SCADA and control operations continue uninterrupted.

Where this applies

Remote engineering access. Engineers reach OT workstations and servers from outside the plant with full identity verification, instead of travelling to site or relying on a standing VPN into the control network.

Vendor and OEM maintenance. Equipment suppliers service the specific machine they are responsible for, within a defined window, fully recorded - no jump host, no permanent account, no rule left open after the work ends.

Firmware and patch delivery. Updates cross inward over a controlled, sanitized path with a complete record of what was delivered and by whom.

Historian and telemetry export. Operational data reaches IT analytics and business systems continuously, without the OT network accepting a single inbound connection.

IT-OT convergence programmes. The boundary becomes a policy enforcement point rather than a manual transfer ritual, which is what makes convergence auditable rather than merely possible.

Frequently asked questions

Does this replace our data diode?

It can, and it can also sit alongside one. Where a diode is mandated or already deployed, Gravity typically takes on the connectivity the diode cannot carry - interactive sessions, vendor access, bidirectional exchange. Where the deployment is being designed fresh, it removes the need for the appliance and the point products usually assembled around it.

Is a software-defined diode as secure as a physical one?

They enforce different things. A hardware diode enforces direction physically and stops there - it cannot tell you who sent the data or whether they were authorized. Gravity preserves the isolation by ensuring nothing inbound is ever accepted, and adds the identity, session control, and audit that physics cannot provide. The right comparison isn't which is stronger, but which questions each can answer.

Will this affect availability or latency?

The platform has been tested under high traffic loads for mission-critical use with minimal latency, and deploys without downtime or changes to the existing network architecture. Nothing is installed on the control devices themselves.

How does it map to NIST SP 800-82 and IEC 62443?

Both call for segmented architectures with monitored communications at the boundary. Outbound-only transport, identity enforcement at the access layer, and a single audit trail across the boundary address those requirements structurally rather than through compensating procedures - and the evidence for an assessment comes out of the platform rather than being assembled by hand.

Conclusion

The air gap was never wrong. It was a correct answer to the question of its time, and the question has changed: operations now need engineers, vendors, updates, and data to cross a boundary that was designed to stop everything.

The choice is not between isolation and connectivity. It is between connectivity that happens under policy, with identity and a complete record - and connectivity that happens anyway, through USB drives, temporary rules, and jump hosts nobody documented. The separation stays. What changes is that you can finally see what crosses it.