IoT vs IIoT: what changes when the Internet of Things goes industrial

Industrial IoT (IIoT) is the Internet of Things applied to factories, process plants, utilities, mines and other operations where connected devices sit next to machines that make or move physical things. The building blocks are the same as in any IoT system: sensors, connectivity, a data platform and applications. What changes is the price of getting it wrong. A smart bulb that misses a command annoys someone; a pressure reading that arrives late, or a gateway that lets an attacker reach a controller, can stop a line, damage equipment or hurt people.

The short answer. Treat a project as IIoT when it touches operational technology (OT): controllers, drives, instruments and the networks that connect them. Then reliability, deterministic timing, safety, industrial protocols, a lifecycle that matches the machines, and the IEC 62443 security framework all apply. Consumer and commercial IoT (homes, wearables, retail, most building sensors) optimizes for cost, ease of setup and features, and can accept best-effort networks and short product lives.

	Consumer and commercial IoT	Industrial IoT
Typical devices	Plugs, wearables, trackers, room sensors	Sensors on machines, PLCs, drives, meters, process instruments
Cost of a failure	Inconvenience, a support ticket	Downtime, scrap, equipment damage, safety risk
Timing	Best effort, seconds are fine	Deterministic at the control level
Common protocols	Wi-Fi, BLE, Zigbee, Thread, MQTT, HTTP	Fieldbus, Modbus, PROFINET, EtherCAT, OPC UA, MQTT with Sparkplug
Lifecycle	A few product generations	As long as the plant equipment
Security reference	ETSI EN 303 645, Cyber Resilience Act	IEC 62443, Cyber Resilience Act

What makes an IoT system industrial?

The defining feature is contact with a physical process controlled by OT. NIST’s guide to OT security describes these systems as having unique performance, reliability and safety requirements compared with ordinary IT. In a plant, a programmable logic controller runs the control loop, a SCADA system supervises it, and the IIoT layer adds sensors, gateways and analytics on top: condition monitoring on a pump, energy metering per machine, OEE dashboards, or data for predictive maintenance.

Most IIoT systems read from the control layer rather than replace it. The cloud or an edge server analyzes and recommends; the PLC still opens the valve. Keeping the loop local is a design choice, not a limitation: the machine must keep running safely when the internet link or the analytics platform is down.

Why do reliability and determinism matter more?

A control loop that expects a measurement every few milliseconds cannot tolerate the variable delays of Wi-Fi or a shared office network. Industrial Ethernet protocols such as PROFINET and EtherCAT were built to deliver cyclic data with bounded latency and jitter. The older fieldbuses they partly replace are standardized in the IEC 61158 series of fieldbus specifications.

IIoT links further up the stack are less strict, but availability still dominates. Gateways buffer data when the uplink fails, brokers run in redundant pairs, and devices are chosen for temperature range, vibration and electrical noise. Wireless is used where cables are impractical, mostly for monitoring rather than control. A consumer device that needs a reboot once a month would be unacceptable on a production line that runs around the clock.

Which protocols does IIoT use?

Several generations coexist in the same plant.

Modbus, described by its own specification as the industry’s serial de facto standard since 1979, is still everywhere. Modbus TCP uses port 502. It is simple and has no built-in security, which is why it stays behind gateways.
Fieldbuses and industrial Ethernet (PROFIBUS, PROFINET, EtherCAT, EtherNet/IP and others) connect controllers to drives and I/O in real time.
OPC UA, standardized as IEC 62541, is the main interoperability layer between machines and IT. The OPC Foundation describes it as a platform-independent service-oriented architecture with an information model, built-in security controls and a publish-subscribe option.
MQTT carries IIoT telemetry from gateways to brokers and clouds, often with the Sparkplug specification on top to fix topic names, payload encoding and device state.

A typical path is Modbus or a fieldbus at the machine, an edge gateway that translates to OPC UA or MQTT, and a platform that stores and analyzes the data. Consumer IoT rarely needs more than one protocol per device.

How do safety and security differ?

Industrial machines have functional safety systems: emergency stops, light curtains, pressure relief and safety controllers designed under IEC 61508 and the sector standards derived from it. IIoT devices are normally kept outside these safety functions. A monitoring sensor can inform a decision, but it should never be the thing that keeps a person safe unless it was designed and certified for that role.

Security follows the ISA/IEC 62443 series, which sets requirements for securing industrial automation and control systems and assigns them to asset owners, product suppliers, integrators and service providers. Its risk assessment part, IEC 62443-3-2, partitions a system into zones and conduits and sets a target security level for each. In practice that means network segmentation, no direct path from the internet to a controller, and gateways that only push data outward. The glossary entry on IEC 62443 summarizes the series. In the EU, the Cyber Resilience Act applies to connected products in both worlds.

Patching is the other difference. A phone app updates overnight; a controller on a running line is updated during a planned shutdown, after testing, sometimes once a year.

Why is the IIoT lifecycle longer?

Machines are bought to run for a very long time, and the electronics attached to them are expected to last as long. That has three consequences. Projects are mostly brownfield: new sensors and gateways are retrofitted onto equipment that already has a controller, often from several vendors and generations. Devices must be supported, patched and replaceable for many years, so vendor stability and open standards weigh more than the newest feature. And data formats and interfaces must outlive the analytics tools that consume them, which is a strong argument for OPC UA information models and documented MQTT namespaces.

Consumer devices move the other way: a new generation every year or two, cloud services that can be switched off, and support periods that buyers rarely see before purchase.

Where do IoT and IIoT overlap?

The line is not sharp. Smart buildings, energy networks, water utilities and logistics use consumer-style radios and cloud platforms for some tasks and industrial controls for others. The same MQTT broker, time-series database and dashboard can serve both. The useful question is not which label applies but which parts of the system can affect a physical process, and those parts get the industrial treatment.

Where to go next

Industrial IoT: a practical guide walks through architectures, the Purdue model and project steps.
IoT security fundamentals covers the threats behind segmentation and patching rules.
MQTT vs HTTP explains why MQTT carries most IIoT telemetry from the gateway up.
What is the Internet of Things? gives the general definition this guide narrows down.

Topics: IIoT, industrial IoT, OT, OPC UA, IEC 62443, comparison