Skip to content
← All writing

The IoT stack has quietly stopped being interesting — and that is the good news

Connectivity, identity, edge inference and OTA have all converged on boring answers. After a decade of bespoke everything, the fleet problems that remain are organisational, not technical.

Harish Duddupudi6 min read

I spent five years at Bosch building a platform that ingested telemetry from vehicles in the field and tried to make sense of it in real time. Most of what was hard then was hard for a stupid reason: there was no default answer to anything. Every layer — transport, identity, provisioning, update, storage — was a bespoke decision, and every bespoke decision became a thing somebody had to keep alive for a decade.

That has changed. Not because the problems got easier, but because the industry finally converged. If you are designing a connected product now, the interesting question is no longer how to do any individual layer. It is whether you can resist the temptation to be clever about layers that are already solved.

Connectivity: pick the boring one

The transport argument is over. MQTT won for device-to-cloud telemetry, and the useful debate moved one level up: what you put inside the messages.

The pattern worth adopting is a defined payload contract with birth and death certificates — a device announces its schema on connect, and the broker's last-will message tells the platform when it disappears. Sparkplug formalised this on top of MQTT, and even where teams do not adopt the spec wholesale, they end up reimplementing its ideas badly.

The reason matters. Without it, "is this device offline or just quiet?" becomes an unanswerable question, and every dashboard grows a hand-tuned staleness heuristic. I have seen three separate teams build three different staleness rules for the same fleet, and none of them agreed during an incident.

For constrained and mesh contexts, Thread and Matter have taken the consumer end of this. For industrial, OPC UA over MQTT is the interoperability story that customers now ask for by name. In cellular, the shift from plastic SIM to eSIM and now iSIM removes an entire class of logistics problem: you no longer ship hardware variants per carrier region.

Identity is the part people still get wrong

This is where I would spend the design budget.

A device needs a cryptographic identity that is not a shared secret, is provisioned at manufacture rather than in the field, and can be rotated without a truck roll. In practice that means a hardware root of trust — a secure element or TPM — holding a private key that never leaves it, with certificate-based mutual TLS on top.

The failure mode when you skip this is not subtle:

  • Shared credentials mean one extracted key compromises the fleet
  • Field provisioning means your factory process is your security boundary
  • No rotation means a compromise is permanent

Attestation closes the loop: the device proves not just who it is but what it is running, so the platform can refuse to accept telemetry from firmware it does not recognise. If you are in automotive or medical, this stops being optional — it is what the cybersecurity regulations effectively require.

# The shape of a device record worth having. Note what is absent:
# no password, no shared key, no "device_secret" column.
device:
  id: urn:dev:ops:32473-fleet-a-004512
  identity:
    root_of_trust: secure-element
    cert_fingerprint: sha256:9f2c...
    issued_by: fleet-a-intermediate-ca
    rotates_at: 2027-03-01
  attestation:
    firmware_measurement: sha256:41ab...
    accepted: true
  shadow:
    reported: { fw: 4.2.1, config_rev: 88 }
    desired:  { fw: 4.3.0, config_rev: 91 }

That reported/desired split is the other idea worth stealing. A device shadow — a server-side document holding both the last known state and the intended state — turns configuration management from a messaging problem into a reconciliation problem. Reconciliation loops you can reason about. Fire-and-forget command messages you cannot.

Edge inference stopped being a science project

The genuinely new capability is that meaningful models now run on parts that cost a few dollars. Microcontroller-class inference with quantised models handles anomaly detection, keyword spotting, vibration classification and basic vision without a round trip.

What this changes architecturally is the shape of the data. The old pattern was: ship raw telemetry, decide in the cloud. That is expensive on bandwidth, expensive on storage, and slow to react. The new pattern is: infer at the edge, ship events and enough context to audit the inference.

Ship raw Infer at edge
Bandwidth Scales with sensor rate Scales with event rate
Latency to action Round trip Local
Model iteration Easy — reprocess history Needs OTA of the model
Debuggability Full fidelity Only what you chose to keep

That last row is the trap. Teams move inference to the edge, stop retaining raw signal, and then cannot explain a false positive six months later or retrain on it. The discipline that works: infer locally, act locally, and retain a sampled or triggered window of raw signal for exactly the cases where the model was uncertain or wrong.

OTA is a product feature, not a delivery mechanism

Every connected product eventually ships a bad build. The differentiator is what happens next.

The properties that matter:

  1. Atomic and dual-bank. The device boots the new image or falls back to the old one. There is no partial state.
  2. Staged rollout by cohort. Percentage-based, with automatic halt on a health signal regression.
  3. Signed and verified on-device. The device, not the server, decides whether an image is trustworthy.
  4. Delta updates. Not a nicety when you are paying per megabyte across a million devices.
  5. Independently updatable model artefacts. Retraining a model should not require shipping firmware.

Point five is newer and underrated. Once inference lives on the device, model weights become a separate release train with a different cadence than the firmware — and if you have not separated them, every model improvement inherits firmware's release risk.

The data layer settled too

Time-series storage has consolidated: columnar formats, hypertables or purpose-built engines, with downsampling and retention policies expressed declaratively rather than as cron jobs someone wrote in 2019. The important design choice is picking your aggregation windows before you have a petabyte, because the migration afterwards is genuinely painful.

Digital twins have finally acquired a usable definition after years of being a slide-deck word. The version that earns its keep is narrow: a queryable model of a device's structure and current state, with a stable identifier scheme, so that applications ask "what is the state of pump 4512" instead of joining seven telemetry tables.

What is actually still hard

None of the remaining problems are protocol problems.

Fleet heterogeneity. You will support hardware revisions you did not design, for longer than anyone promised. Every feature becomes a matrix.

The ten-year support tail. A device shipped today may outlive the cloud service it talks to, the TLS ciphers it trusts, and the team that built it. Certificate expiry is the single most common cause of mass field failure I have seen, and it is entirely predictable — which is what makes it embarrassing.

Cross-discipline contracts. The interesting bugs live where firmware, cloud and hardware meet. At Bosch the practice that helped most was not technical: it was writing the device-to-cloud schema down as a shared artefact that firmware and platform teams both signed off on, before either wrote code.

Cost per device per month. It is a real number, it compounds across a fleet, and it is usually nobody's job until finance notices.

What I would watch

  • WebAssembly at the edge as a way to ship sandboxed logic to devices without shipping firmware. Promising, not yet boring.
  • Post-quantum migration for device identity. Devices shipping now with a ten-year life will outlive current assumptions, and firmware that cannot rotate its algorithms is a liability being manufactured today.
  • Regulatory pull. Cyber-resilience rules are converging on requirements — SBOMs, vulnerability disclosure, guaranteed support windows — that turn engineering hygiene into a market-access condition.

The best sign of a maturing platform is that its interesting decisions move up the stack. If your team is still arguing about transport protocols, that is worth noticing. The argument was settled; the problems that are left are about the fleet, the tail, and the organisation.

Written by Harish Duddupudi in Ontario, Canada. If this was useful — or wrong — I’d genuinely like to hear about it. Send a note.

Keep reading