Internet of Things: Long-Lived Distributed Systems in the Physical World
📑 On this page
- A concrete example: smart thermostat
- Device hardware
- Embedded software
- Connectivity
- Device identity
- Onboarding
- Local versus cloud decisions
- Telemetry
- Remote commands
- Secure updates
- Physical access
- Safety and fail-safe behavior
- Fleet operations
- Product lifetime and exit
- Manufacturing is part of the trust chain
- Design field diagnostics carefully
- Knowledge check
- The one idea to remember
An internet-connected object is not merely a smaller web application.
It has constrained hardware, a physical location, intermittent connectivity, and a lifecycle that may outlast the team or cloud service that launched it.
An IoT product is a distributed system that joins sensors or actuators, embedded software, networks, backend services, and physical consequences.
Its design must include installation, maintenance, failure, ownership transfer, and retirement.
A concrete example: smart thermostat
A thermostat:
- senses temperature and humidity,
- applies local control rules,
- drives heating or cooling,
- displays status,
- sends telemetry,
- receives schedules,
- and accepts remote commands.
If the internet fails, safe local control should continue. If the cloud account changes owner, the old owner should lose access.
Device hardware
IoT hardware may include:
- microcontroller or processor,
- memory and storage,
- sensors,
- actuators,
- radio,
- power system,
- secure element,
- and physical controls.
Cost, heat, battery, and size constrain computation. Hardware choices also determine how long cryptography, updates, and future protocols remain practical.
Embedded software
Firmware initializes hardware, samples sensors, applies control logic, communicates, stores configuration, and handles updates.
It must cope with:
- power interruption,
- limited storage,
- timing deadlines,
- corrupted state,
- and partial hardware failure.
Use watchdogs, safe defaults, atomic configuration changes, and tested recovery paths.
Connectivity
Devices may use Wi-Fi, Ethernet, cellular, Bluetooth, mesh radio, or specialized low-power networks.
Choose based on:
- range,
- energy,
- bandwidth,
- mobility,
- installation,
- local infrastructure,
- subscription cost,
- and environment.
Connectivity will fail, so queue important events, define offline behavior, and reconcile after reconnection.
Device identity
Each device needs a unique, verifiable identity.
Provision credentials securely during manufacturing or onboarding. Avoid shared default passwords or one secret across an entire product line.
Bind device identity to the correct customer, tenant, and permissions. Support credential rotation and revocation when a device is stolen or retired.
Onboarding
Initial setup crosses trust boundaries:
- phone to device,
- device to network,
- device to cloud,
- and user account to ownership.
Use authenticated pairing, short-lived codes, proximity proof where appropriate, and clear reset behavior. An attacker should not claim a device merely by learning its serial number.
Local versus cloud decisions
Keep safety-critical and time-sensitive behavior local when possible.
Cloud services are useful for:
- fleet management,
- remote access,
- aggregate analytics,
- complex models,
- and cross-device coordination.
Define what happens when cloud, DNS, time synchronization, or vendor APIs are unavailable.
Telemetry
Telemetry can show:
- device health,
- firmware version,
- battery,
- connectivity,
- faults,
- and usage.
Collect only what supports a defined purpose. Physical-device data can reveal presence, habits, location, or health. Minimize, protect, retain, and delete it accordingly.
Remote commands
Actuator commands can unlock doors, stop machines, change doses, or alter temperatures.
Authorize every command by user, device, action, and current state. Add limits, freshness, replay protection, acknowledgement, and audit records. Consequential actions may require local confirmation or human approval.
Secure updates
Long-lived devices need authenticated, integrity-checked updates.
The update system should support:
- signed firmware,
- rollback protection,
- staged deployment,
- interruption recovery,
- compatibility checks,
- and emergency revocation.
Maintain enough storage or partitioning to recover when an update fails.
Physical access
Attackers may hold the device, inspect ports, replace sensors, read storage, or probe buses.
Use secure boot, protected debug interfaces, tamper evidence where justified, encrypted sensitive storage, and server-side limits. Assume consumer devices can eventually be examined deeply.
Safety and fail-safe behavior
Define safe states for sensor failure, stale commands, battery depletion, network loss, and software crash.
A smart lock, pump, toy, and industrial controller require different choices. Security controls should not create unsafe physical behavior, and safety overrides should not become unmonitored security bypasses.
Fleet operations
Operators need inventory of:
- owner,
- location,
- hardware revision,
- firmware,
- credentials,
- connectivity,
- support status,
- and known vulnerabilities.
Monitor update coverage, failed devices, unusual commands, and obsolete versions. One forgotten hardware revision can block a fleet-wide security fix.
Product lifetime and exit
State how long cloud service, security updates, spare parts, and support will continue.
When service ends, devices should degrade safely, allow local use where feasible, export user data, remove credentials, and avoid becoming permanent insecure equipment.
Ownership transfer and factory reset must remove prior accounts and sensitive history.
Manufacturing is part of the trust chain
Security begins before the device reaches a customer.
Manufacturing systems may write firmware, serial numbers, calibration, and credentials. Protect those stations, restrict who can provision production identities, and record which artifact and key material entered each unit.
Reject duplicate identities and detect unauthorized firmware at first connection. Test a sample from each production run for secure boot, update verification, radio behaviour, and reset.
Suppliers also need controlled component substitutions. A replacement sensor, flash chip, or radio can change calibration, security properties, and software compatibility even when the enclosure looks identical.
Design field diagnostics carefully
Support teams need enough information to distinguish power, sensor, radio, configuration, and cloud failures.
Provide bounded health reports and user-visible status without exposing private telemetry or universal debug credentials. Temporary diagnostic access should require authorization, expire automatically, and be logged.
Knowledge check
- Why is an IoT device more than a small web client?
- Which behavior should continue during internet failure?
- Why must each device have unique credentials?
- What makes remote actuator commands high risk?
- Which records are needed to operate a device fleet?
The one idea to remember
IoT connects software to long-lived physical objects. Reliable products plan device identity, offline behavior, secure commands, signed updates, physical access, privacy, safety, fleet visibility, ownership transfer, and end-of-support from the beginning.