Most IoT architectures you’ll encounter follow the same basic pattern: sensor collects data, data goes to a gateway, gateway pushes to the cloud, cloud runs the processing, cloud sends commands back down. It’s clean, it’s familiar, and for a lot of use cases it works perfectly well.
But in 2026, a growing number of industrial deployments are questioning whether that cloud hop in the middle is actually necessary — or whether it’s introducing latency, cost, and failure points that don’t need to be there.
Direct-to-device (D2D) connectivity bypasses centralised cloud infrastructure entirely. Industrial devices talk to each other directly, peer-to-peer, at the edge — no cloud hop in the middle. The interest is real and accelerating: a 2025 survey of industrial IoT decision-makers found 91% citing rising urgency around D2D adoption over the next 18 months.
Why cloud-centric IoT hits limits in industrial environments
To understand why D2D is gaining traction, you need to appreciate where the cloud-first model starts to break down.
Latency is the most obvious constraint. In a manufacturing context, a CNC machine that detects a fault condition needs to stop — not in 300 milliseconds (a good round-trip time to a cloud endpoint), but in under 10 milliseconds. No cloud architecture can meet that requirement. Real-time industrial control has always had to happen locally, which means cloud has typically been used for monitoring and analytics rather than actual control loops.
Then there’s bandwidth. A modern factory floor might have hundreds of sensors generating continuous streams of vibration, temperature, and current data. Routing all of that through cellular or broadband connections to the cloud is expensive, and often unnecessary when the only thing you actually care about is an anomaly that triggers a local response.
Connectivity reliability is the third issue. Industrial sites — offshore platforms, remote substations, mining operations — often have patchy or intermittent connectivity. A system that depends on a cloud connection to function can’t be the backbone of a process that runs 24/7.
What D2D actually looks like in practice
Direct-to-device isn’t a single protocol or technology — it’s more of an architectural principle. What it means in practice varies by use case.
In a factory setting, it might mean PLCs and sensors communicating directly over OPC-UA or MQTT in a local broker, with edge compute nodes running the processing logic and only pushing aggregated results or exception data to the cloud. The cloud gets a filtered, meaningful data stream; the control decisions happen locally.
In field service — think utilities maintenance, pipeline monitoring, wind farm operations — D2D might mean field devices communicating with each other and with a field engineer’s tablet over a local mesh network, without needing a WAN connection to complete tasks. Inspection records, work orders, and fault data synchronise to the cloud when connectivity is available, but the work can continue offline.
In logistics, autonomous mobile robots (AMRs) in a warehouse increasingly communicate directly with each other and with a local fleet management system over Wi-Fi 6 or private 5G, rather than routing through a cloud orchestration layer. The response times needed for collision avoidance simply can’t tolerate cloud latency.
The role of private 5G and Wi-Fi 6
Private wireless infrastructure has matured enough to make D2D practical at industrial scale. Private 5G networks — now within reach for large manufacturing sites and ports — deliver the predictable latency and bandwidth that direct device communication requires. Unlike shared cellular, a private 5G deployment keeps traffic local and gives you control over performance guarantees.
Wi-Fi 6 (and Wi-Fi 6E) has also improved in ways that matter here. The improved OFDMA scheduling handles dense device environments considerably better than previous generations — which is exactly the challenge on a factory floor with 500 endpoints.
Where D2D fits alongside cloud and edge
D2D doesn’t mean abandoning cloud. The realistic picture for most industrial IoT deployments in 2026 is a three-tier architecture:
The device layer handles real-time sensing and actuation. Direct device-to-device communication handles time-critical local coordination. Edge servers handle local processing, anomaly detection, and buffering. The cloud handles historical analytics, model training, remote monitoring, and enterprise integration.
What’s changing is which tier carries the operational workload. For years, there was a tendency to push that workload up toward the cloud because cloud infrastructure was more powerful and easier to manage. The pendulum is swinging back as edge hardware becomes capable enough and as the limitations of cloud-latency for industrial control become more apparent.
What this means for architecture decisions
If you’re designing an IIoT system today, D2D thinking should be part of the conversation from the start. A few practical implications:
Choose protocols that work well in local broadcast or peer-to-peer modes. MQTT with a local broker, OPC-UA Pub/Sub, and Matter (for smaller-scale device ecosystems) all support local communication without cloud dependency.
Design for offline-first. Assume the cloud connection will be unavailable at some point. Systems that gracefully degrade to local operation and sync when reconnected are significantly more resilient.
Be deliberate about what goes to the cloud. Every piece of data you send to a cloud endpoint costs bandwidth and money. If you can answer the operational question locally, do it locally.
The shift to D2D isn’t about rejecting cloud infrastructure — it’s about being more intentional about where intelligence and communication actually need to happen. In industrial environments, that’s often closer to the machine than the last decade of IoT architecture suggested.