How HTTPS and API Calls Work Across a One-Way Data Diode

Modern operational technology (OT) environments increasingly need to send data to enterprise IT, cloud platforms, security monitoring systems, and analytics applications. That data may include telemetry, logs, alerts, operational measurements, and application data delivered through HTTP, HTTPS, or APIs.

But there is a fundamental networking challenge: HTTP and HTTPS are traditionally designed for bidirectional communication, while a data diode is designed to allow data to flow in only one direction.

So how can organizations securely use HTTPS and API-based integrations without creating a return path into a protected OT network?

The answer lies in understanding the difference between application-level data transfer and network-level communication.

MetaDefender™ Optical Diode and MetaDefender™ Optical Diode Fend use hardware-enforced unidirectional data flow and protocol-aware transfer mechanisms to allow data to move across security boundaries without creating a conventional bidirectional network connection.

HTTPS is HTTP running over TLS. In a conventional HTTPS connection, a client sends a request to a server, and the server sends a response back.

At the network level, this requires bidirectional communication. TCP itself requires a handshake and ongoing control traffic in both directions. A traditional HTTPS session therefore cannot simply be routed through a physically one-way data diode as if the diode were a conventional firewall or router.

This creates an important distinction:

A data diode does not make a normal "two-way" HTTPS connection "one-way". Instead, it enables HTTPS-based data transfer by breaking the conventional end-to-end communication model.

That protocol break is a fundamental characteristic of data diode architecture. Rather than extending a routable network connection from one security zone into another, the architecture transfers the intended data across the boundary and reconstructs the appropriate communication on the destination side.

Consider a simple OT-to-IT use case.

An industrial application generates a temperature reading and needs to send it to a cloud analytics platform using an HTTPS API: OT application → HTTPS/API → cloud platform

In a conventional network, the OT application would establish a network connection to the destination, send an HTTP request, and receive an HTTP response.

With a data diode, the architecture is different.

A typical one-way implementation can be viewed conceptually as: OT application → source-side connector/proxy → one-way optical transfer → destination-side connector → IT/cloud application

The critical point is that the two networks do not share a conventional bidirectional connection.

The source-side component receives the data from the OT environment. The data is then transferred across the hardware-enforced one-way boundary. On the destination side, the receiving component reconstructs or forwards the data toward the intended application.

This approach allows organizations to preserve the semantics of application data transfer while eliminating the return network path.

For example:

1. An OT system generates telemetry.
2. A source-side service receives the telemetry.
3. The relevant data payload is prepared for one-way transfer.
4. The payload crosses the optical isolation boundary.
5. A destination-side service receives the transferred data.
6. The destination side delivers the data to the enterprise, monitoring, analytics, or cloud application.

The networks remain separated even though useful information can cross between them.

This is fundamentally different from configuring a firewall rule that permits HTTPS traffic between two networks. A firewall can allow bidirectional TCP communication when the policy permits it. A data diode is specifically designed to prevent that return path at the hardware level.

Yes, MetaDefender Optical Diode and Fend 50-series models support HTTP and HTTPS alongside industrial and IT protocols.

To do this, each side of the diode must be provided with the required certificates and keys to terminate and initiate a standalone TLS connection with the source and destination respectively.

REST APIs are commonly implemented over HTTP or HTTPS and are increasingly used to integrate OT data with:

• Cloud analytics platforms
• SIEM and security monitoring platforms
• Enterprise dashboards
• Data historians
• Predictive maintenance applications
• Centralized logging systems
• Ticketing and workflow systems

A conventional REST API interaction typically looks like: Client → HTTP/S POST or PUT → API server → HTTP response

In these situations, an application-layer response is part of the normal application exchange. The client expects an HTTP 200 status code and possibly a custom message in the response body.

In a one-way architecture, the input side of the diode can proxy this response, as if from the final destination. If a custom response body for a successful PUT/POST is known and repeatable, it can also be proxied.

For example, an OT monitoring system may need to send:

POST /api/v1/telemetry

with a payload containing:

{"temperature":72,"pressure":101.3,"status":"normal"}

The architectural objective is not to establish a permanent bidirectional API session between OT and IT. Instead, the data is transferred outward through the diode and delivered to the destination-side application.

The input side of the diode upon receiving the POST would return a 200 OK status to the client before forwarding the payload across the optical isolation and then connecting to the destination server to deliver the message with another POST /api/v1/telemetry,

This makes one-way architectures particularly useful for telemetry, event, log, and monitoring APIs, where the primary business requirement is outbound data publication.

While encryption helps keep data confidential in transit, it does not prevent malicious data from being sent or received. A data diode addresses a different problem: communication direction.

If an enterprise or cloud environment is compromised, a conventional bidirectional connection can potentially provide an attacker with a path toward the OT environment, depending on network architecture and security controls.

A hardware-enforced data diode removes that return path. Thus, OT data can leave the protected network without creating a routable path for external systems to send traffic back into it.

For critical infrastructure, that distinction can be significant. Data diodes are used to transfer operational information to monitoring and enterprise systems while maintaining physical network separation.

Looking to strengthen your OT network security?

Explore how OPSWAT’s MetaDefender Optical Diode and Fend solutions enable secure, hardware-enforced one-way data transfer across critical network boundaries. Talk to our experts to discuss your OT architecture and data transfer requirements.

When designing an OT-to-IT architecture, it is important to start with the actual communication requirement rather than the application protocol.

Ask three questions:

1. What data needs to leave the OT environment?

Identify telemetry, logs, alerts, files, process data, or other information that needs to reach IT, cloud, or monitoring systems.

2. Does the destination actually need to send data back?

Many integrations are described as requiring “connectivity” when the underlying business requirement is simply to publish information outward. If the returning data is simply an acknowledgment of receipt or success, a unidirectional architecture can proxy these responses and eliminate an unnecessary network path.

3. Where should the protocol boundary occur?

Protocols such as TCP, HTTPS, and REST APIs assume certain bidirectional behaviors. A data diode architecture therefore needs to define where sessions terminate, how data is transferred across the boundary, and how the destination-side application receives it.

This application-aware approach helps organizations modernize OT connectivity without treating network isolation and application integration as mutually exclusive requirements.

1. Can a data diode transmit HTTPS traffic?
   Yes. MetaDefender Optical Diode and MetaDefender Fend support HTTP/HTTPS-based data transfer, but HTTPS cannot operate as a conventional bidirectional end-to-end session across a physically one-way boundary. The diode terminates and then initiates a separate encrypted session on each side of the diode and must therefore be provided the keys and certificates to handle those sessions.
2. Can APIs work through a data diode?
   Yes. API-based data transfer can work through a data diode when the architecture is designed around PUT/POST one-way communication. The key is to avoid requiring a bidirectional API session across the diode and instead use source- and destination-side mechanisms to transfer the required application data.
3. Does a data diode replace HTTPS encryption?
   No. They solve different security problems. HTTPS provides encryption and authentication for application traffic, while a data diode provides hardware-enforced control over the direction of network communication.
4. What is the difference between a firewall and a data diode?
   A firewall controls traffic using software-defined security rules and can permit bidirectional communication. A data diode physically enforces one-way communication, preventing a return network path by design.
5. Why use a data diode for OT-to-IT communication?
   A data diode allows organizations to share operational data, telemetry, logs, and other information with enterprise or cloud systems while maintaining physical separation from those networks. This reduces the attack surface associated with bidirectional connectivity.
6. What is MetaDefender Optical Diode?
   MetaDefender Optical Diode is an optical, hardware-enforced data diode designed to provide secure one-way data transfer between networks. It can support IT protocols such as HTTP and HTTPS alongside other supported protocols and use cases.
7. What is MetaDefender Optical Diode Fend?
   MetaDefender Optical Diode Fend is a data diode solution designed for secure unidirectional data transfer across IT and OT environments. Depending on the model and deployment, it supports IT and industrial protocols and can help connect isolated OT networks with systems that require access to operational data.