Sensor on a device measures a physical condition
A sensor is the first link in any IoT chain: it converts a physical condition — temperature, vibration, light, pressure, location — into an electrical signal a microcontroller can read. That reading only becomes "IoT" once it leaves the device. Network connectivity, whether Wi-Fi, cellular, or a low-power radio, carries the reading to a platform that can store and process it, and IBM's overview of the Internet of Things describes this ingest layer as the point where raw signals become usable data.
From there, data analytics compares the new reading against a baseline or a threshold. If a warehouse's humidity sensor reports a value outside the range set for stored goods, the platform doesn't just log the number — it flags a deviation. The final stage is action: an automated control loop adjusts a valve or damper directly, or a dashboard alert prompts a person to intervene. This is the same four-stage mechanism — sense, transmit, analyze, act — underlying every example usually filed under "IoT," from a home thermostat to a factory's predictive-maintenance system. Once you can name the four stages in an example, the word stops being a marketing umbrella and becomes a description of a specific pipeline.
Machine wear produces subtle vibration or temperature change
Mechanical wear rarely announces itself with a sudden failure; it shows up first as a small rise in vibration amplitude or bearing temperature, well before a part visibly fails. Industrial IoT sensors mounted on rotating equipment report that drift continuously rather than at the interval of a scheduled inspection, which is the practical difference between condition monitoring and calendar-based maintenance.
Analytics applied to that stream — often a trained baseline plus a deviation threshold — flags degradation while the machine is still running normally by every other measure. Oracle's explanation of Internet of Things use cases frames this as the shift from reactive and preventive maintenance to maintenance scheduled on actual equipment condition. The economic case follows directly: a technician is dispatched when the data says a bearing is drifting out of tolerance, not on a fixed monthly schedule that either wastes labor on healthy equipment or misses a failure between visits. This is the argument industrial buyers actually use to fund an IoT deployment — fewer unplanned stoppages, not a vague promise of "smart" operations.
Every added connected device widens the network attack surface
Every device added to a network is another point of entry, and IoT devices are disproportionately risky because many ship configured for convenience rather than security. A large share arrive with default administrator credentials, no mechanism for firmware signing, and — once the vendor stops supporting the model — no patch path at all.
The consequence is not hypothetical: the Mirai botnet compromised large numbers of IoT devices precisely through unchanged default passwords, then used them to launch distributed denial-of-service traffic, an incident Wikipedia's overview of the Internet of Things cites as a turning point in how security engineers treat consumer and industrial devices as network risk rather than isolated gadgets. An attacker doesn't need to breach a corporate firewall directly if a single unpatched camera or sensor sitting on the same VLAN offers an easier route inward.
The mitigations are specific rather than aspirational:
- Segment IoT devices onto their own VLAN, separate from workstations and servers.
- Change default credentials at provisioning, before a device is ever exposed to a network.
- Track firmware versions per device class and retire models once the vendor stops issuing updates.
- Close or restrict management ports (Telnet, unauthenticated web admin) that don't need to be reachable from outside the segment.
"Is IoT good or bad" isn't a question with a single answer — it's a question of whether these four steps happened before the device went into production.
Goods or equipment carry connected tags and sensors
A pallet, container, or piece of leased equipment fitted with a connected tag reports two things continuously: where it is, and whether it stayed within the conditions it's supposed to. Location comes from GPS or cellular triangulation; condition comes from onboard sensors for temperature, humidity, or shock.
That combined stream flows into a platform the way any other sensor data does, but the decision it supports is logistical rather than mechanical. SAS's explanation of the Internet of Things points to supply chain visibility — knowing not just that a shipment left the warehouse, but whether a refrigerated load held temperature the entire route — as one of the more measurable returns on IoT investment, because a spoiled shipment identified in transit can be rerouted or written off immediately rather than discovered on delivery. The step that separates a tracking system from a true IoT deployment is exactly this: the data has to trigger a decision — reroute, discard, insurance claim — not just populate a map.
Data
Data, in this context, is the sensor reading itself — a temperature value, a GPS coordinate, a vibration amplitude — generated continuously or on an interval by a device. It is raw and, on its own, not actionable; a single vibration reading tells you nothing until it's compared against a baseline or a threshold.
Coursera's explanation of the Internet of Things with examples describes this raw stream as the input layer that every subsequent stage — transmission, storage, analysis — depends on, and notes that the value of an IoT deployment is almost entirely determined by what happens to the data after it's captured, not by the sophistication of the sensor generating it. A device producing perfectly accurate readings that nobody analyzes or acts on delivers no more value than no sensor at all.
Internet of Things (IoT)
The Internet of Things is the network of physical objects — embedded with sensors, software, and network connectivity — that exchange data over the internet without requiring a person to manually enter or transmit that data. Wikipedia's article on the Internet of Things traces the term to the late 1990s, applied first to RFID-tagged objects reporting their identity and location, and notes that the scope has since expanded to include everything from wearable health monitors to industrial control systems.
IoT vs. M2M vs. "connected device"
These three terms get used interchangeably, but they draw a useful line. Machine-to-machine (M2M) communication predates IoT and typically describes a closed, point-to-point link between two specific machines — a vending machine reporting stock to its own operator's server over a dedicated cellular connection, for instance. IoT generalizes that idea: devices publish data to a shared platform, often over the public internet, where it can be consumed by multiple applications, dashboards, or third parties, not just the one system that installed the sensor. A "connected device" is the broadest of the three — any object with network access — and doesn't imply the sensor-to-platform-to-analytics pipeline that defines IoT specifically.
Four types of IoT
No single standards body defines a canonical four-way split of IoT, but a defensible categorization by who is buying and what's being connected is commonly used across industry explainers, including IBM's and Microsoft Azure's glossary entry on IoT:
| Type | Typical device | Primary buyer | Example |
|---|---|---|---|
| Consumer IoT | Smart thermostat, wearable, doorbell camera | Household | Home temperature scheduling |
| Commercial IoT | Point-of-sale sensor, connected medical device | Business, healthcare provider | Inventory tracking, patient monitoring |
| Industrial IoT (IIoT) | Vibration sensor on rotating equipment, flow meter | Manufacturer, utility | Predictive maintenance |
| Infrastructure IoT | Smart grid sensor, traffic sensor, water meter | Municipality, utility | Grid load balancing |
IoT device
An IoT device is a physical object with embedded compute and network connectivity — enough processing to read a sensor and format the result, and enough connectivity to send it somewhere. The boundary sits at intent: a laptop connects to the internet but is a general-purpose computer first, while a soil-moisture sensor or a fleet tracker exists specifically to capture one kind of reading and transmit it, with no general-purpose interface at all. A smart bulb controlled from a phone app counts; a Wi-Fi-enabled laptop running a browser does not, even though both hold an IP address.
Five commonly cited examples span very different device classes:
- A smart thermostat that learns an occupancy pattern and adjusts heating or cooling accordingly.
- A wearable fitness tracker reporting heart rate and step count to a paired phone app.
- An industrial vibration sensor bolted to a pump housing, reporting to a maintenance platform.
- A GPS asset tracker attached to a shipping container.
- A connected smoke detector that alerts a phone when triggered, rather than only sounding locally.
What happens when the device stops getting updates
Every IoT device has a support horizon shorter than its physical lifespan, and the end of that horizon is rarely announced clearly. When a vendor discontinues firmware updates or shuts down the cloud platform a device depends on, the device typically keeps running its last firmware version indefinitely — which means any vulnerability discovered after that point goes unpatched permanently. A device that still functions can still be an open door on the network it sits on; "still works" and "still safe to leave connected" are separate questions, and the second one has no reliable expiration warning built in.
Actuator
An actuator is the component that does the opposite job of a sensor: instead of capturing a physical condition, it changes one, acting on a motor, valve, relay, or damper in response to a decision made from sensor data. A thermostat's sensor reads room temperature; its actuator is the relay that switches the furnace or compressor on or off.
Most explanations of IoT describe the sensing half in detail and leave the actuator half implicit inside words like "automation" or "control." That's a gap worth closing, because it's the actuator that turns IoT from a monitoring system into a control system. A pipeline that only senses and reports is a dashboard; a pipeline where the platform's decision also drives an actuator — closing a valve, cutting power to a failing motor — is what most industrial and home-automation deployments are actually built to do. Distinguishing the two matters when evaluating a deployment, because an actuator introduces a failure mode a pure sensor never has: an actuator that fires incorrectly, whether from a bad reading, a network delay, or a compromised platform, can cause direct physical damage in a way a mis-logged sensor value cannot.
Network connectivity
Network connectivity is the wired or wireless link that carries a device's data to a platform, and the choice of link is a tradeoff between power draw, range, and bandwidth rather than a single default.
| Connectivity | Typical range | Power profile | Best suited for |
|---|---|---|---|
| Wi-Fi | Building-scale | Higher draw, needs regular power | Fixed devices near mains power |
| Cellular (LTE-M, NB-IoT) | Wide area, carrier-dependent | Moderate; battery-viable for months | Mobile assets, remote sites without Wi-Fi |
| Low-power wide-area (LoRaWAN) | Several kilometers, terrain-dependent | Very low; battery life measured in years | Sparse, infrequent readings over large areas |
Where processing happens — on the device itself, at a local gateway (edge), or entirely in the platform's cloud — is a related but separate decision from which radio carries the data: a device can transmit over a low-power link and still do meaningful filtering locally before it sends anything, reducing both power draw and the volume of data the platform has to ingest.
IoT platform
An IoT platform is the software layer that receives device data, stores it, and exposes it to applications and dashboards, sitting between the device fleet and whatever uses the data. Azure's IoT glossary entry describes this layer as handling device registration, message ingest, and often device management — pushing firmware updates and monitoring connectivity status — as a single service rather than something built from scratch per deployment.
Three broad platform shapes are available: a self-hosted broker run on infrastructure the operator controls, a managed cloud IoT service billed per message or per connected device, or a vendor's proprietary cloud bundled with the hardware itself. The deciding factors are usually message volume and who needs to hold the encryption keys and device credentials — a self-hosted broker keeps both in-house at the cost of running the infrastructure; a managed service removes that operational burden in exchange for a recurring bill tied to message count.
Who owns the data the platform stores
A separate question from platform choice is data ownership: many consumer IoT devices route readings through a vendor's cloud under terms that let the vendor retain, aggregate, or resell that data even after the device is sold or the account is closed. This is a privacy question distinct from the security question of whether a device can be compromised — a device can be perfectly secure against outside attackers while still sending every reading it captures to a vendor's servers as designed. Reading what a device's terms of service permit before connecting it is the only way to know which situation applies.
Data analytics
Data analytics is the step that turns a stream of raw sensor readings into a decision, and it's the stage that determines whether an IoT deployment is worth its cost. At the simplest level, this is threshold comparison — is this reading outside an acceptable range. At a more developed level, it's trend detection across a device's history, comparing today's vibration signature against months of prior readings to catch gradual drift a single threshold would miss.
Anyone evaluating a first IoT deployment gets more value starting from the decision than from the device:
- Name the specific decision the data needs to support — reorder stock, dispatch a technician, shut off a valve — before selecting a sensor.
- Measure the baseline manually first, so the automated reading has something known to be compared against.
- Pilot on a small, contained set of devices on their own network segment before expanding fleet-wide.
- Budget for the platform's per-message or per-device cost at the fleet size the deployment will reach, not the pilot size.
Roles and pay bands
"IoT job" isn't a single role; the work splits across embedded firmware engineering, network and infrastructure engineering, cloud platform engineering, and industrial controls — each with distinct skills and distinct pay bands, so a salary claim attached to "IoT" without naming which of these applies isn't a checkable number. Anyone assessing whether IoT work pays well should ask which of those four job titles is actually on the posting, not treat "IoT" as an occupation in its own right.
Start by naming the one decision a sensor reading in your own context needs to trigger — that single sentence determines which sensor, which connectivity, and which platform actually make sense to buy.