Quick summary

Industrial IoT systems must assume the network will fail, not hope it stays up. Deloitte estimates unplanned downtime costs industrial manufacturers $50 billion a year, and a substantial share of that loss is tied to connectivity, not equipment failure. Designing for intermittent and degraded networks is the difference between a system that survives reality and one that only works in the lab.

Introduction

The early years of industrial IoT marketing painted a tidy picture: sensors stream data continuously to the cloud, analytics run in real time, and operators make decisions from a dashboard. Then the projects hit the real world. Cellular signal drops in the corner of the plant. A switch reboots. A wind turbine's satellite link cuts out in heavy weather. A factory firewall update breaks MQTT traffic for six hours.

Networks fail. The question is whether the industrial system fails with them, or keeps running until connectivity returns. This article looks at why connectivity reliability is the defining engineering challenge in industrial IoT, what intermittent and degraded networks actually look like in production, and how to design systems that handle them by default rather than by exception.

The real cost of connectivity failure

Connectivity failures are not abstract reliability events. They translate directly into downtime, and downtime is one of the most expensive line items in industrial operations.

Deloitte estimates that unplanned downtime costs industrial manufacturers approximately $50 billion per year, with the average manufacturer facing around 800 hours of unplanned downtime annually (Deloitte, cited in industry research, 2024). Siemens' True Cost of Downtime 2024 report puts the figure for Fortune Global 500 companies at $1.4 trillion per year, equivalent to 11 percent of total revenues, up from 8 percent in 2019 to 2020 (Siemens, 2024).

Not all of that is connectivity, but a meaningful share is. When an industrial IoT system depends on continuous cloud communication for monitoring, alerts, or control, every network outage becomes either a blind spot or a stoppage. The systems that minimise the cost of these events are the ones designed to keep operating, locally and autonomously, while the network is down. That capacity to survive disconnection is the practical definition of connectivity reliability.

In Nordic, DACH, and Benelux industrial sites, where energy-sector deployments, factory automation, and building management systems often span remote installations and harsh environments, the cost of poor connectivity reliability is amplified by geography. A connectivity-fragile system in a distributed energy network or warehouse logistics operation can lose value at every site simultaneously.

Takeaway: Connectivity failures are not edge cases; they are recurring industrial events with significant financial consequences when systems are not designed to tolerate them.

What "intermittent and degraded" really means

Industrial networks fail in more ways than full outages. Connectivity reliability needs to be designed for a spectrum of failure modes, not a binary up-or-down model.

The realistic conditions industrial IoT systems must handle include:

• Full disconnection lasting seconds, minutes, hours, or occasionally days

• Partial connectivity where some endpoints are reachable and others are not

• High-latency conditions that break time-sensitive control loops

• Packet loss that corrupts or delays telemetry without an obvious failure signal

• Bandwidth constraints that force throttling under load

• Authentication or certificate expirations that look like network failures

• Cellular network congestion in industrial parks at shift change

• Wireless interference from heavy machinery, welding, or other industrial equipment

• Update windows that take entire network segments offline

The IETF's RFC 9556 on IoT edge challenges identifies "resilience to intermittent services" as one of the core requirements for any IoT edge deployment, and notes that minimising reliance on high-bandwidth continuous connectivity is a functional necessity, not an optimisation (IETF, 2024). The implication is direct: industrial IoT architectures that assume the network is up are not just optimistic; they are architecturally incomplete.

Takeaway: Connectivity reliability must address a spectrum of failure modes, from full disconnection to subtle latency and packet loss, not just the simple binary case.

The architecture that survives network failure

Surviving intermittent and degraded networks is an architectural problem, not a tooling problem. The systems that handle real-world conditions share a set of common design patterns.

The patterns that consistently work include:

• Local autonomy at the edge: critical control logic runs on edge devices or gateways, not in the cloud, so operations continue during outages

• Store-and-forward telemetry: data is buffered locally when the cloud is unreachable and synchronised when connectivity returns

• Idempotent message handling: messages can be safely retried without producing duplicate effects on the receiving system

• Quality-of-service tiers in protocols: MQTT QoS levels, OPC UA acknowledgements, and similar mechanisms ensure delivery guarantees match the criticality of the data

• Graceful degradation: features that depend on the cloud disable cleanly, while local features continue, rather than crashing the whole system

• Hybrid cloud and edge data models: real-time decisions happen locally, while aggregated analysis happens in the cloud

• Clear time synchronisation: edge devices keep accurate local time so buffered data can be correlated correctly when uploaded

IBM's research on edge computing for IoT is explicit on the principle: edge devices are designed to "process data continuously and function even when they lose internet connectivity", which is what prevents downtime during outages or disasters (IBM, 2025). The shift from cloud-centric to edge-centric design is not just about latency; it is about operational continuity.

For industrial buyers, this architectural shift has practical procurement implications. A connectivity-reliable IoT solution treats the edge as the primary system, with the cloud as an accelerator, rather than treating the cloud as the system and the edge as a thin client.

Takeaway: Reliable industrial IoT architectures push critical logic to the edge and treat the cloud as an accelerator, not a single point of failure.

Connectivity choices that match the risk profile

No single connectivity technology fits every industrial scenario, and assuming otherwise creates fragility. The right approach matches the connectivity layer to the operational reality of the site.

Common options and their fit profile:

• Wired Ethernet and fieldbus protocols: highest reliability, lowest flexibility, ideal for fixed industrial assets

• Wi-Fi 6 and 6E: good throughput, but vulnerable to interference in heavy industrial environments

• Cellular LTE and 5G: solid coverage in most European industrial geographies, with growing private 5G adoption for sites that need deterministic performance

• Private 5G networks: forecast to reach $8.7 billion in manufacturing revenue by 2030, growing at 54 percent CAGR from 2025, driven by demand for low-latency, high-density industrial connectivity (industry forecasts, 2025)

• LoRaWAN and NB-IoT: low bandwidth, long range, and excellent for distributed metering and sensor networks

• Satellite IoT: increasingly viable for remote installations, particularly with LEO constellations offering 100 to 150 ms latency

• Redundant connectivity: many industrial systems now use two or more independent connectivity paths for critical functions

The most resilient industrial designs do not pick one connectivity technology; they layer multiple options and design the system to fall back gracefully when the primary path fails. This is particularly relevant in Nordic and DACH energy deployments, where critical infrastructure regulations increasingly expect operators to demonstrate not just connectivity, but continuity of connectivity.

Takeaway: Resilient industrial IoT designs combine multiple connectivity technologies and define clear fallback behaviour, rather than depending on a single network.

The regulatory dimension of reliability

Connectivity reliability is increasingly a regulatory concern, not just an operational preference.

The EU NIS2 Directive, applicable since October 2024, imposes cybersecurity and operational resilience obligations on essential and important entities across energy, manufacturing, transport, healthcare, and digital infrastructure. Reliability of monitoring, incident detection, and reporting capabilities are central to NIS2 compliance, and these depend directly on the connectivity layer (European Commission, 2024).

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, adds product-level obligations that include vulnerability handling and security updates across the device lifecycle. Both depend on functioning connectivity to deploy fixes, monitor exploitation, and report incidents through the ENISA Single Reporting Platform from 11 September 2026 (European Commission, 2024).

IEC 62443, the international standard for industrial automation and control system security, treats network availability, segmentation, and resilience as core requirements for industrial systems. In practical terms, this means connectivity reliability is now part of the audit surface for European industrial operators. A system that cannot operate during a network outage is no longer just an operational concern; it is a compliance concern.

Takeaway: EU regulation now treats operational and connectivity resilience as core compliance requirements, not optional engineering features.

Building reliability into procurement, not just engineering

Industrial IoT reliability is built through procurement choices as much as engineering ones. Buyers who specify reliability requirements upfront get systems that behave very differently from those who accept whatever the vendor proposes.

Practical procurement principles include:

• Specify required behaviour during full and partial network outages, with measurable acceptance criteria

• Require edge autonomy for safety-critical and time-critical functions

• Define minimum buffering capacity for telemetry during outages

• Specify supported failover behaviour between connectivity paths

• Require interoperability with site-specific connectivity options, not just the vendor's preferred network

• Build connectivity testing into the acceptance process, including simulated outage conditions

• Verify compliance with relevant standards (IEC 62443, NIS2 applicability, CRA readiness)

The strongest industrial buyers treat reliability as a contractual specification, not a marketing claim. The systems they end up with are the ones that survive what production environments actually do to networks.

Takeaway: Reliability requirements specified in procurement produce systems that behave very differently from those built without explicit reliability constraints.

Conclusion

Industrial networks are not the controlled, predictable environments that early IoT marketing assumed. They are noisy, intermittent, occasionally hostile, and subject to regulatory expectations that grow tighter every year. Designing connectivity reliability into industrial IoT is no longer optional; it is the difference between a system that delivers business value and one that delivers expensive disappointment.

The shift that matters is conceptual: stop treating connectivity as a given and start treating it as a variable. Design the edge to operate autonomously, choose connectivity layers that match the risk profile, and define explicit behaviour for the failure modes that production environments will produce.

For European industrial operators facing both rising downtime costs and tightening regulatory expectations under NIS2, the CRA, and IEC 62443, this discipline is what separates resilient industrial IoT from fragile industrial IoT. It is also what makes the difference, over a 10 or 15-year industrial deployment, between a system that pays back its investment and one that quietly drains it.

FAQ

Why is connectivity reliability such a big issue in industrial IoT?

Industrial sites face a wide range of network failure modes, from full outages to subtle latency and packet loss, and unplanned downtime costs industrial manufacturers an estimated $50 billion per year according to Deloitte. Systems that depend on continuous cloud connectivity are exposed every time the network fails.

What is the role of edge computing in connectivity reliability?

Edge computing allows critical logic and telemetry buffering to happen locally on devices and gateways, so industrial systems continue to operate even when the cloud is unreachable. The IETF's RFC 9556 identifies resilience to intermittent services as a core requirement for any IoT edge deployment.

Should industrial IoT systems use one connectivity technology or several?

The most resilient designs combine multiple connectivity layers, such as wired, cellular, and wireless, and define clear fallback behaviour when one path fails. Private 5G is gaining traction in manufacturing because it offers deterministic performance for time-sensitive applications, but it complements rather than replaces other layers.

Does EU regulation cover connectivity reliability?

Yes. The NIS2 Directive, the EU Cyber Resilience Act, and IEC 62443 all treat operational and connectivity resilience as core compliance requirements for industrial operators and manufacturers. Reliability is now part of the audit surface, not just an internal engineering concern.

What should buyers specify in industrial IoT procurement?

Buyers should specify required behaviour during full and partial network outages, edge autonomy for critical functions, minimum buffering capacity for telemetry, supported failover behaviour, and interoperability with site-specific connectivity options. Including these in contracts produces measurably more reliable systems than accepting vendor defaults.

Sources

• IoT value set to accelerate through 2030: Where and how to capture it – McKinsey – https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/iot-value-set-to-accelerate-through-2030-where-and-how-to-capture-it
• Edge Computing for IoT – IBM – https://www.ibm.com/think/topics/iot-edge-computing
• RFC 9556: Internet of Things (IoT) Edge Challenges and Functions – IETF – https://datatracker.ietf.org/doc/rfc9556/
• Cyber Resilience Act – European Commission – https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• NIS2 Directive – European Commission – https://digital-strategy.ec.europa.eu/en/policies/nis2-directive
• IEC 62443 Series: Industrial communication networks – Network and system security – International Electrotechnical Commission – https://www.iec.ch/blog/understanding-iec-62443