Industrial IoT Platform Architecture: Layers, Protocols, and Components Explained.
A practical guide to how industrial IoT systems are structured — from sensor to cloud, including edge computing, device identity, and post-quantum security.
What is IIoT platform architecture?
IIoT platform architecture describes how industrial IoT systems are structured across multiple layers: physical devices and sensors, edge gateways for local processing, a message broker for telemetry transport, a central IoT platform for device management and dashboards, and identity and security layers. Each layer has defined responsibilities, protocols, and scaling characteristics.
The seven layers of IIoT platform architecture.
Industrial IoT systems are built from distinct functional layers. Understanding each layer's role helps you choose the right components and avoid common design pitfalls.
Device & Sensor Layer
Physical endpoints — PLCs, RTUs, sensors, meters, actuators, and embedded modules. Devices communicate over field protocols (Modbus, OPC-UA, Wireless M-Bus, BACnet) or directly over IP (MQTT, CoAP, HTTP).
Connectivity & Edge Gateway Layer
Edge gateways aggregate device traffic, translate protocols, and act as the first hop toward the cloud. They run local logic to reduce bandwidth, filter noise, and operate offline when connectivity is lost.
Message Broker & Transport Layer
The message broker decouples device producers from platform consumers. MQTT is the dominant protocol for constrained devices; AMQP bridges enterprise services. High-availability brokers with durable queues prevent data loss during outages.
IoT Platform & Device Management Layer
The platform manages device identity, telemetry ingestion, rules processing, dashboards, and multi-tenant access control. It is the operational core that operators interact with daily.
Identity & Authorization Layer
Every device, user, and service must be authenticated and authorized before accessing resources. Runtime policy evaluation prevents stale-permission windows that occur when permissions are embedded in tokens.
Edge Compute & Orchestration Layer
WebAssembly workloads can be deployed and updated remotely on both cloud nodes and microcontrollers. This layer enables AI inference, data transformation, and protocol bridging at the edge without firmware reflashing.
Security & Cryptography Layer
Long-lived IoT devices must remain secure after classical PKI is broken by quantum computers. Hardware-accelerated post-quantum cryptography provides forward-secure device identity that outlives the deployment lifetime.
How the Abstract Machines stack maps to each layer.
Each product addresses a specific architectural layer. They can be deployed individually or as an integrated stack.
IIoT protocols: which to use and when.
Protocol selection depends on device constraints, network conditions, data volume, and integration requirements. Most production deployments use multiple protocols.
Primary IoT telemetry protocol. Lightweight publish-subscribe with QoS 0/1/2, retained messages, and Last Will. MQTT 5.0 adds shared subscriptions, flow control, and user properties.
Enterprise message queuing. Used for integrating IoT data streams with ERP, MES, and cloud services. Supports transactions, routing topologies, and dead-letter queues.
REST-like protocol optimised for constrained devices with limited bandwidth. Runs over UDP, includes DTLS for security. Common in smart metering and sensor networks.
Industrial automation standard for PLC and SCADA integration. Rich information model, complex address space, and built-in security. Common in manufacturing and process control.
Ubiquitous serial protocol in industrial automation. Runs over RS-485 (RTU) or Ethernet (TCP). No built-in security — requires gateway-level encryption for remote access.
European standard for wireless utility meter reading. Used for smart metering of electricity, gas, heat, and water. Operates at 868 MHz sub-GHz for range and wall penetration.
Edge vs cloud processing.
The decision of where to process data has significant implications for latency, bandwidth costs, offline resilience, and security.
Process at the edge when:
- Control loops require sub-100ms response times (cloud round-trips introduce too much latency)
- Devices operate in locations with intermittent connectivity — local processing must continue offline
- Data volume is high but only aggregates or anomalies are relevant to the cloud (bandwidth reduction)
- Data sovereignty or regulatory requirements restrict transmission of raw device data off-premises
- AI inference must run close to the sensor to be actionable (e.g. real-time vision, predictive maintenance)
Process in the cloud when:
- Long-term storage and historical analysis are the primary use case — cloud storage is cheaper and more scalable
- Cross-site correlation is needed — aggregating data from hundreds of sites for fleet-level analytics
- Heavy ML training runs that require GPU resources not available at the edge
- Compliance reporting and audit trails that must be tamper-proof and centrally managed
- Real-time dashboards and alerting that operators access from anywhere
IIoT security architecture.
Industrial IoT systems have distinct security requirements compared to consumer IoT. Devices are long-lived, operate in physical environments, and often control critical infrastructure.
Device identity
Every device needs a unique cryptographic identity issued at manufacture or provisioning. Device certificates or API keys authenticate the device to the message broker and platform. When a device is decommissioned, its credentials must be revoked and access blocked immediately — runtime policy evaluation (not token-embedded permissions) guarantees this.
Atom — runtime IAM →Transport security
All device-to-broker and broker-to-platform communication should be encrypted. TLS 1.2+ for MQTT and HTTPS. mTLS for inter-service communication. DTLS for CoAP over UDP. For constrained devices where TLS is too heavy, lighter alternatives exist but increase risk — the gateway should terminate TLS on behalf of downstream devices.
Secure boot & OTA updates
Firmware must be signed and the signature verified at boot before execution. OTA updates must be delivered over authenticated, encrypted channels and must include rollback protection — a failed update must not brick the device or leave it in an unknown state.
Quarc — hardware-enforced secure boot →Post-quantum preparedness
Industrial devices deployed today may be in the field when quantum computers become capable of breaking ECC and RSA. NIST finalised post-quantum cryptography standards in 2024 (FIPS 203, 204, 205). New designs should evaluate ML-KEM (key encapsulation) and ML-DSA (signatures) for device identity and firmware signing, especially for devices with 10+ year deployment lifetimes.
Quarc — PQC secure element →Common questions.
What is IIoT platform architecture?
IIoT platform architecture describes how industrial IoT systems are structured — the layers, components, and protocols that connect physical devices to cloud applications. A typical architecture includes device and sensor layers, edge gateways, message brokers, an IoT platform for device management and dashboards, an identity and authorization layer, and optional edge compute and cryptography layers.
What is the difference between IoT and IIoT?
IoT (Internet of Things) is the broad category of connected devices — consumer electronics, smart home devices, wearables. IIoT (Industrial Internet of Things) specifically refers to connected devices in industrial contexts: manufacturing, energy, utilities, transportation, and infrastructure. IIoT systems typically have higher reliability requirements, longer device lifetimes, and stricter security and compliance needs.
Why is MQTT the dominant protocol for IIoT?
MQTT was designed for constrained devices over unreliable networks. Its publish-subscribe model decouples producers from consumers. Quality of Service levels (0/1/2) provide flexible delivery guarantees. It runs over TCP with minimal overhead, making it suitable for everything from microcontrollers to cloud-scale brokers. MQTT 5.0 adds features like shared subscriptions, topic aliases, and enhanced authentication that enterprise deployments need.
What is an IoT gateway and do I need one?
An IoT gateway is a device that aggregates data from local sensors and field devices and forwards it to a cloud platform. Gateways are necessary when field devices speak non-IP protocols (Modbus, Wireless M-Bus, Bluetooth), when local processing or offline buffering is required, or when you want to reduce cloud bandwidth by aggregating and filtering data at the edge. For devices with native IP and MQTT support, a gateway is optional.
How does edge computing fit into IIoT architecture?
Edge computing moves processing from the cloud to the device or gateway. In IIoT this reduces latency for time-critical control loops, lowers cloud bandwidth costs, and enables operation during cloud connectivity loss. Edge compute layers typically run lightweight runtimes — containers, WebAssembly, or native binaries — on gateway hardware. WebAssembly is increasingly used because it provides sandboxed isolation, sub-10ms startup, and portability from cloud servers down to microcontrollers.
What is a message broker in IIoT architecture?
A message broker is the central routing component for device telemetry. Devices publish messages to topics; platform services subscribe to those topics. The broker decouples producers from consumers, handles delivery guarantees (QoS), and can buffer messages during downstream failures. In enterprise IIoT, brokers also provide durable queues with consumer groups so multiple downstream services can consume the same data stream independently.
How should IoT device identity be managed?
Each device needs a unique cryptographic identity — typically a certificate or API key associated with a device record in the platform. That identity controls which topics the device can publish and subscribe to. Runtime policy evaluation (rather than token-embedded permissions) ensures that when a device is decommissioned or its credentials are revoked, access is blocked immediately without waiting for tokens to expire.
Why does post-quantum cryptography matter for IIoT now?
Industrial devices deployed today often remain in the field for 10–20 years. Quantum computers capable of breaking ECC and RSA are projected to become practical within that window. NIST finalised post-quantum cryptography standards in 2024. EU and US regulators project mandatory PQC adoption in critical infrastructure by 2030. Devices that ship now with only classical cryptography will be vulnerable before end-of-life.
Open-source components for every layer.
Abstract Machines builds open-source infrastructure for each layer of the IIoT stack. All products are Apache 2.0.
Multi-protocol IoT platform with device management, visual dashboards, rules engine, and RBAC.
Enterprise MQTT 5.0 + AMQP broker. Clustering, durable queues, 500K+ connections/node.
Runtime RBAC/ABAC for IoT. Single Rust binary, PostgreSQL-backed, live policy evaluation.
WebAssembly orchestrator from cloud to Zephyr RTOS microcontrollers. OCI registry, FaaS at the edge.
RISC-V Linux gateway for industrial IoT. Containers, Wasm, and EU-manufactured.
ESP32-C6 RISC-V with 6 native radios — Wi-Fi 6, BLE, NB-IoT, Wireless M-Bus, Thread, Ethernet.
Post-quantum cryptography secure element. Hardware-accelerated ML-KEM-768 and ML-DSA-65.