Sensor on a device measures a physical condition
A sensor is where every IoT chain starts: a component that converts a physical condition — temperature, vibration, pressure, light, location — into an electrical signal a device can read. Everything that follows depends on that single measurement being taken accurately and often enough to be useful. IBM's overview of IoT describes this as the pattern common to nearly all deployments: sensors gather data, connectivity moves it, and software acts on it.
The mechanism has four identifiable stages:
- A sensor on a device measures a physical condition and produces a reading.
- Network connectivity sends that reading to an IoT platform, wired or wireless.
- Data analytics on the platform compares the reading against a normal range and flags a pattern outside it.
- Automated control or an alert triggers action — a valve closes, a technician gets paged, a machine schedules its own maintenance.
That fourth stage is where the phrase "predictive maintenance" earns its keep: the pattern found in stage three doesn't just get logged, it changes what happens next in the physical world. Once a reader can name which of these four stages a given example belongs to, "IoT" stops being an abstraction and becomes something with visible joints.
Machine wear produces subtle vibration or temperature change
Before a bearing or motor fails outright, it usually drifts — a small rise in temperature, a change in the vibration signature, a shift in current draw. That drift is often too gradual for a person on a maintenance round to notice, but it is exactly the kind of continuous, small-magnitude change a sensor is good at catching.
Industrial IoT sensors mounted on the equipment report this drift continuously rather than at the interval of a scheduled inspection. Cisco's explainer on industrial IoT frames this as one of the core use cases separating industrial deployments from consumer ones: the value isn't the reading itself but the ability to compare thousands of readings over time and flag when one asset departs from its own baseline.
Once analytics flags degradation before failure, maintenance moves from calendar-based to condition-based: a technician is dispatched when the data says wear has begun, not on a fixed monthly or quarterly schedule. This is the clearest business case IoT has, because it converts into a number a finance department can act on — fewer unplanned stoppages, and maintenance labor spent on equipment that actually needs it rather than equipment that happens to be due.
Every added connected device widens the network attack surface
More sensors and controllers on a network means more places for someone to get in. Each device is a small computer with its own operating system, its own open ports, and its own patch cadence — or lack of one — and every one of them is a potential foothold once it's reachable from outside.
The specific failure mode repeats across incident reports: devices ship with default administrator credentials and no practical path to receive a security patch after the vendor stops supporting them. IBM's overview of IoT names security as one of the field's persistent concerns precisely because so many deployed devices were never designed to be updated once installed. An unpatchable camera or sensor sitting on the same network as file servers and payroll systems is not a hypothetical; it's the default state of a lot of deployed hardware.
The countermeasure is not a verdict on IoT as good or bad — it's specific and structural:
- Change default credentials before a device goes on the network, not after.
- Put IoT devices on their own network segment (VLAN), isolated from servers and workstations.
- Track which devices are still receiving firmware updates and retire the ones that aren't.
- Require devices to use TLS for any traffic that leaves the local network, rather than plaintext.
Applied consistently, these four steps close the entry point that an attacker exploiting the weakest device would otherwise use to reach everything else on the network.
Goods or equipment carry connected tags and sensors
In supply chain and logistics, the device sensing a physical condition is often attached to a shipment rather than a machine: a tag or sensor riding in a container reporting location, temperature, humidity, or shock. Oracle's overview of IoT lists asset tracking and cold-chain monitoring among the more mature commercial applications of the technology, precisely because the readings map directly onto a compliance requirement — did this shipment stay within the temperature band it was supposed to.
Location and condition data flow continuously into a platform as the shipment moves, rather than being checked only at pickup and delivery. That continuous feed is what gives supply chain visibility its value: a dashboard can show not just where an asset is right now but whether it stayed within tolerance for the whole journey, not just at the two endpoints anyone would have checked anyway.
When a reading shows a cold-chain breach or a route deviation, the same data that flagged the problem lets a business identify the loss immediately and reroute or replace the shipment before the failure compounds — a spoiled pallet caught in transit rather than discovered on arrival. That conversion from raw tracking data into a rerouting decision is the step that separates "we have a dashboard" from an IoT deployment that pays for itself.
What the four types of IoT actually are
There is no single standards body that defines "the four types of IoT" the way a spec defines a protocol version, so any list should be read as a categorization rather than a law. A defensible one, drawn from how the field is generally organized by application domain, sorts deployments into consumer, industrial (IIoT), commercial, and infrastructure IoT.
| Type | Typical device | Primary concern |
|---|---|---|
| Consumer IoT | Thermostats, wearables, home cameras | Convenience, ease of setup |
| Industrial IoT (IIoT) | Vibration sensors, PLCs, machine controllers | Uptime, predictive maintenance |
| Commercial IoT | Asset trackers, smart point-of-sale, building sensors | Inventory, occupancy, logistics |
| Infrastructure IoT | Grid sensors, water meters, traffic sensors | Public safety, resource management |
The boundary between these categories is mostly about who bears the cost of failure. A consumer sensor missing a reading is an inconvenience; an industrial sensor missing a reading can mean a missed failure warning on equipment that costs real downtime; an infrastructure sensor missing a reading can affect a public utility. IBM's IoT overview and Cisco's industrial IoT explainer both organize their use-case discussions along broadly this same domain split, even without naming it as a canonical four-way taxonomy.
Sensing and acting are not the same job
A sensor measures; it does not do anything to the physical world on its own. The component that acts — closing a valve, cutting power to a motor, unlocking a door — is an actuator, and conflating the two is where a lot of "how IoT works" explanations go vague.
The distinction matters because it's the difference between monitoring and control. A deployment that only has sensors can tell you a pump is overheating; a deployment with an actuator wired to the same platform can shut the pump off automatically once analytics crosses a threshold, without waiting for a person to read an alert and act on it. Automated control is only possible where an actuator exists downstream of the decision — otherwise every "trigger" in the chain is really just a notification to a human, and the loop closes through a person instead of through hardware.
How the reading gets from the device to the platform
Network connectivity is the wired or wireless link that carries a device's data to a platform or to other devices, and the choice of link shapes almost everything else about a deployment — power budget, cost, range, and how it behaves when something drops.
- Wi-Fi — high throughput, short range, needs continuous power; fine for a home device near an outlet, poor for a battery-powered field sensor.
- Cellular (LTE-M, NB-IoT) — wide coverage without owning infrastructure, ongoing carrier cost per device, useful for assets that move.
- Low-Power Wide-Area Networks (LoRaWAN and similar) — long range and low power draw at the cost of low bandwidth, suited to infrequent readings from remote sensors.
- Wired (Ethernet, industrial buses) — the most reliable and highest-bandwidth option where devices are fixed and already near infrastructure, common on factory floors.
Where the processing happens is a related but separate choice. Some analysis runs on the device itself, some on a nearby gateway (edge processing), and some only after the reading reaches a cloud platform — and that placement determines how the deployment behaves when the connection to the platform is lost. A device doing nothing but forwarding raw readings goes blind the moment its uplink drops; a device or gateway doing some local analysis can keep flagging anomalies and buffering data until the link comes back.
What an IoT platform actually does with the data
An IoT platform is the software layer that ingests, stores, and manages the readings devices send, and hosts the applications that act on them. It's the piece that turns a flood of individual device messages into something a dashboard, an alert rule, or another system can consume.
Coursera's overview of IoT describes the platform layer as sitting between the device fleet and the applications that use the data — handling device registration, message ingestion, and storage so that application developers don't have to solve those problems per device. Data analytics is the step that runs on top of that stored data, turning individual readings into a pattern: a threshold breach, a trend, a deviation from a device's own baseline. Without that platform layer doing ingestion and storage reliably, the analytics step has nothing consistent to work from.
Where IoT differs from "just a connected device"
Not every device with a chip and a network connection is meaningfully "IoT," and the boundary is worth drawing rather than assumed. A laptop or phone is a general-purpose networked computer a person operates directly; an IoT device is typically purpose-built, operates with little or no direct human interaction per reading, and exists specifically to sense or act on a physical condition and report it.
Wikipedia's entry on the Internet of Things traces the term to describing physical objects embedded with sensors, software, and connectivity that exchange data with other devices and systems over the internet — the connectivity and the physical-world sensing are both required, not just one or the other. That's also roughly where "machine-to-machine" (M2M) communication sits historically: M2M usually describes point-to-point device links over a dedicated channel, often without internet routing or a platform layer, while IoT generally implies internet connectivity and centralized ingestion into a platform that can combine data across many devices. An industrial PLC talking to a single controller over a serial link is closer to classic M2M; the same PLC reporting into a cloud platform alongside a thousand other machines is IoT.
The jobs behind IoT are not one job
"IoT job" doesn't point to a single role, and pay varies enormously depending on which actual discipline is meant. The work splits roughly into embedded/firmware engineering (writing the code that runs on the device itself), network and infrastructure engineering (the connectivity layer), cloud/platform engineering (ingest, storage, and application logic), and industrial controls engineering (the PLC and SCADA side of manufacturing deployments).
Each of those has its own hiring market, its own required skill set, and its own salary band, and none of them is well described by "IoT engineer" alone. Phoenix University's explainer on IoT notes that the field draws on skills from data science, network engineering, and software development simultaneously, which is exactly why a single "IoT salary" figure is close to meaningless — a firmware engineer's pay, a cloud platform engineer's pay, and an industrial controls engineer's pay are set by different labor markets, not one combined one. Anyone comparing pay across postings should match the actual job title, not the word "IoT," before comparing numbers.
What to check before starting a deployment
Before buying sensors or picking a platform, a few questions settle most of the downstream decisions:
- What physical condition needs measuring, and how often does it actually change — this sets the required reading frequency, which sets the power and bandwidth budget.
- Where will the device sit relative to power and network coverage — this decides between Wi-Fi, cellular, LPWAN, or wired connectivity.
- Who owns the readings once they leave the device, and can the vendor resell or repurpose them — this is a separate question from device security and deserves its own answer in any contract.
- What happens when the vendor's platform reaches end of support — a device that stops receiving updates or loses its cloud backend becomes either inert or a liability, and that date is worth asking about before purchase, not after.
Start with one sensor and one measurement worth watching, confirm the reading reaches a platform reliably, and only then scale the device count up — the mechanism from sensor to action is the same at ten devices as it is at ten thousand, but the failure points multiply with every device added.