How Edge Software Supports Hybrid Industrial IoT Deployments

 

What must happen on site, and what can wait for the cloud? Here, industrial edge software means software on gateways, industrial PCs or servers at or near the equipment. It is not the on-device AI models that “edge” often means in tech news. A hybrid industrial Internet of Things (IIoT) deployment pairs that site tier with a cloud or enterprise tier.

The short answer: edge software for hybrid industrial IoT runs on site, between field devices and cloud or enterprise systems. It typically collects data over industrial protocols, translates and filters it, and can run supervisory rules and alarms locally. It sends selected data to cloud platforms, dashboards and databases. When the uplink drops, it can hold data within the limits of its storage and forward it once the link returns.

Why Can’t Industrial IoT Always Rely on the Cloud?

Many industrial sites cannot run everything from a remote data center. NIST SP 800-82 Rev. 3 is the 2023 guide to operational technology (OT) security from the US National Institute of Standards and Technology (NIST). It says cloud services for OT “may have additional availability challenges resulting from increased sensitivity to system performance levels or connection issues”. For assets that are “truly remote”, the Industrial Internet Consortium (IIC) wrote in 2018, “satellite connectivity may be the only option”.

What must keep working typically runs locally. In NIST’s words, “the RTU or PLC controls the local process”, meaning the remote terminal units and programmable logic controllers wired to the equipment. Where a process needs one, a safety instrumented system sits beside them, built to bring the process to a safe state, and NIST notes it is “often independent from all other control systems”. The supervisory edge software described here does not replace the PLC or the safety layer. It is the data and supervisory tier next to them.

ISA-95, a standard for integrating enterprise and control systems, sorts manufacturing activities into levels. The OPC Foundation’s ISA-95 companion specification (2013) places “real-time responses measured in sub-seconds” at Level 2, typically on PLCs and distributed control systems. Level 3 systems “consider real-time to mean information available a few seconds after shop floor events occur”. Supervisory alarms and rules on an edge node belong to that seconds timescale. Running on site, they do not wait for a round trip to a remote data center and can keep working when the uplink is slow or down. In this article, real-time device data means near-real-time supervisory data, not deterministic control, in which a controller must act within a guaranteed time.

None of this makes a local tier mandatory. NIST SP 500-325 (2018) calls that middle layer “fog” and says it is “not perceived as a mandatory layer”, nor is “the centralized (cloud) service perceived as being required”. Different use cases might need different architectures.

What Edge Software Does on an Industrial Site

NIST’s September 2026 initial public draft of SP 800-82 Revision 4 describes an edge gateway architecture in which “OT devices communicate with an industrial gateway or edge platform that normalizes protocols, filters data, enforces policy, and forwards selected data to cloud, vendor, or enterprise systems”. The draft lists it next to a telemetry-to-cloud pattern, in which “control functions typically remain local”, and prefers neither.

Industrial edge platform documentation shows these steps. In EdgeX Foundry, an open-source framework hosted by LF Edge, readings are converted “into a common EdgeX Foundry data structure”, and a rules engine “performs if-then conditional actuation at the edge”. Microsoft’s documentation for Azure IoT Edge 1.6 LTS says that, to reduce bandwidth costs, users “can clean and aggregate the data locally then only send the insights to the cloud for analysis”.

The IIC’s 2018 paper adds that near-real-time analytics “can be processed on a local gateway and provide OEE trends and alerts to operational systems or personnel” (OEE is overall equipment effectiveness). None of the documents reviewed for this article measures how much filtering saves.

Protocol Conversion at the Edge: OPC UA, Modbus, MQTT, BACnet and SNMP

Each protocol below, from OPC UA (OPC Unified Architecture) to SNMP (Simple Network Management Protocol), was written for a different job. The table quotes each protocol’s specification owner, and BACnet International for BACnet/SC. In it, TLS stands for Transport Layer Security, and QoS for MQTT’s quality-of-service levels, which set the delivery guarantee.

Table sources: OPC Foundation, Modbus Organization, OASIS, Eclipse Foundation, ASHRAE BACnet Committee, BACnet International and IETF (the Internet Engineering Task Force).

Modbus is “an application layer messaging protocol” that “provides client/server communication between devices”, and a separate Modbus/TCP Security specification adds TLS. MQTT 5.0, a 2019 standard of the OASIS open-standards consortium, is a “messaging transport” that is “agnostic to the content of the payload”. BACnet International says the secure BACnet variant, BACnet/SC, “complements” existing options.

In 2026 the UK’s National Cyber Security Centre (NCSC) led joint guidance with the US Cybersecurity and Infrastructure Security Agency (CISA) and six other agencies. It says “Industrial control protocols (Modbus, OPC DA, EtherNet/IP, etc.) should be restricted to isolated OT network segments.” Exchange between OT and IT “should be brokered through a DMZ” (a demilitarized zone between the two networks) over protocols “such as OPC UA over TLS, MQTT over TLS, HTTPS”.

Protection depends on the protocol and on how the site configures it. NIST notes that “Many OT protocols have no authentication at any level.” OPC UA’s own Part 1 “does not specify the circumstances under which various security mechanisms are required”.

What Happens to Industrial IoT Data When the Network Goes Down?

Local functions on the edge node can keep running through a wide-area network (WAN) outage, but offline operation and offline storage have different limits. Microsoft’s Azure IoT Edge documentation states both: devices “can function offline indefinitely after the initial, one-time sync. However, message storage depends on the time to live (TTL) setting and available disk space.” The TTL sets how long a stored message waits to be delivered before it expires, and its default is 7,200 seconds (two hours).

AWS documents that each stream in AWS IoT Greengrass has a maximum size (256 MB by default in its example). Each stream also requires a choice of what happens when it fills: overwrite the oldest data or reject new data. Store-and-forward buffers, which hold data during an outage and send it on afterwards, are typically bounded by time, size or disk and use a configured policy when they fill.

In MQTT 5.0, at QoS level 0 “Message loss can occur”, and at QoS 1 “messages are assured to arrive but duplicates can occur”. At QoS 1, after a disconnection, a subscriber might receive messages “in the order 1,2,3,2,3,4”. What arrives after a reconnect depends on the QoS level and session settings that each hop uses.

Before relying on any buffer, an architect should ask:

• How long must the site survive offline, and is the buffer sized for that duration at peak data rate?

• What happens when the buffer fills: drop the oldest data, reject the newest, or push back on the data source?

• Which delivery guarantee does each hop give, and can the receiver handle duplicates?

• Does order matter to the consumer, and does the chosen product’s replay preserve it?

• Will the target accept late, back-filled data?

Sending Data to Cloud Platforms, Dashboards and Databases

NIST’s draft revision names cloud platforms “for dashboards, analytics, reporting, or predictive maintenance”. Where operational data needs to be shared, the NCSC-led guidance suggests replicating “the OT historian to a historian instance in the DMZ via a unidirectional, secure transfer mechanism” (a historian is the plant’s time-series database).

Late data also needs its original time. OPC UA keeps the timestamp “applied to a Variable value by the data source” apart from the server’s receipt time, and Sparkplug flags back-filled data that “should not be considered a real time/current value”.

Secure Data Exchange: A Boundary to Enforce and a Node to Defend

Edge software does not make an OT network secure. It is where secure exchange can be enforced – and it is also a component to defend. The NCSC-led guidance says “All connections with the OT environment should be initiated as outbound connections from within the OT environment.” NIST adds that outbound connections “could represent a significant risk if unmanaged” and suggests “making outbound rules as stringent as inbound rules”.

For obsolete devices, the NCSC-led document lists “a protocol gateway to translate and inspect traffic before it reaches the device” among its examples of boundary controls. The same document warns that OT gateways are “high-value targets for machine-in-the-middle attacks” and that “An insecure gateway can also offer attackers a persistent point of presence”.

An architect can give the edge node its own zone. The International Society of Automation’s (ISA) 2024 overview of the ISA/IEC 62443 standards says that dividing a system into zones and conduits “can also reduce overall risk by limiting the scope of a successful cyber-attack”. Services the node does not need can be switched off, as NIST advises for functions “not required for proper operation”.

When Edge Software Is Not the Answer

An edge tier is one more set of devices and software to secure, patch, monitor and retire. NIST notes that some OT environments “have small maintenance windows for applying approved updates” and that a patch “can also introduce a greater risk from a production or safety perspective”. NIST writes about OT patching in general, and the same logic applies to an edge tier.

Where the job is local control, the PLC and an on-premises SCADA (supervisory control and data acquisition) system may already do it. Where the job is telemetry for analytics, the UK NCSC’s 2024 cloud-hosted SCADA guidance describes hybrid deployments in which “only telemetry data is ingested for processing, but control remains in an on-premises SCADA solution”. The 3GPP 5G requirements (TS 22.104), published by the European Telecommunications Standards Institute (ETSI) in 2026, call monitoring data acquisition “typically not latency-critical”.

Neither path should mean exposing OT. CISA and partner agencies (2025) say “Remove OT connections to the public internet” and “Practice and maintain the ability to operate OT systems manually.”

The practical question for an edge tier is whether one of four problems is present: protocols that must stay in isolated segments, outages longer than the source systems can hold, data worth reducing before upload, or alarms that must survive a WAN loss. The NCSC-led principles say the first step for all OT connectivity should be “a formal business case”. Those four questions can be part of it.

Placement is a separate choice: NIST notes that, in its example architecture, IIoT platform functions “can be implemented” on a platform “deployed in an on-site data center, an off-site data center, or in the cloud”. Iotellect’s own guide to the best on-premise IoT platforms for industrial use sets out on-premise, edge and hybrid options side by side.

One Platform Example: Iotellect

The Iotellect industrial IoT platform spans both tiers. Iotellect’s guide says it uses “the same server software at the edge, on an owned server and in a cloud account”. The Iotellect Edge platform is that server “packaged for gateways, industrial PCs, and Linux PLCs” on “Windows and Linux, x86 and ARM”.

According to the product page, the node “runs connectivity, local automation, and HMI on site” (HMI is the human-machine interface), and alarm detection, history and acknowledgment “continue when the uplink is down”. For outages, the page says: “Store telemetry and events on the node and forward them upstream when connectivity returns.” It lists protocol mappings such as “Modbus and OPC UA to MQTT” and calls the nodes cloud-neutral, feeding “whatever runs upstream today, from AWS, GCP and Azure to a plain SQL database”.

Iotellect supplies the software, and the page says the customer’s team “adapts the node afterwards, without a services contract”. The page states no buffer capacity or offline duration, so those remain open design questions.

What the Evidence Does Not Settle

The research behind this article found no neutral, measured comparison of edge and cloud response times for industrial workloads, so the article gives no millisecond figures. The research also found no public, neutral data on how often industrial sites lose their uplink or how much buffered data is lost – so buffer sizing starts from the site’s own outage history. The attack reports reviewed for this article concern boundary appliances such as virtual private networks (VPNs) and firewalls, and none measures attacks on industrial edge software as a category.

Buffers and uplinks have limits. Good hybrid designs write those limits down before the first outage.

About the author

Francisco Fidalgo is a Senior Technical Product Manager at Iotellect, a low-code platform for industrial IoT with SCADA and MES built in. Based in Lisbon, he studied at Instituto Superior Técnico and has spent more than 14 years building enterprise software and IoT products. At Iotellect he works with engineering, sales and integration partners on the platform’s growth in European markets. Francisco writes about IoT project economics, protocol integration and product strategy, including JTBD and platform thinking. You can follow Francisco on LinkedIn.