Getting a single device online is a demo. Running a fleet of them — bespoke hardware, in the field, for years — is a different category of problem entirely. The hard parts aren't the sensors or the firmware. They're identity, updates, security, and operations at scale. That's the platform layer, and it's where most "IoT projects" quietly stall once they leave the lab.
If you're building or operating connected hardware beyond a handful of units, here's what the platform underneath it actually has to do.
Identity comes first, or nothing else is safe
Every device needs a strong, unique, verifiable identity from the moment it powers on. That's the foundation everything else stands on: secure connectivity, access control, and the ability to trust a message actually came from the device it claims to. In practice that means a certificate and key hierarchy (PKI), mutual TLS for connections, and a way to rotate and revoke credentials when a device is compromised or retired. Get this wrong and you don't have a fleet, you have an attack surface.
Onboarding has to be zero-touch
If adding a device to the fleet requires a human to configure it, your fleet has a hard size limit set by how many people you can pay to configure devices. At scale, onboarding has to be zero-touch: a device powers on, proves its identity, and provisions itself into the fleet with the right configuration and access — no operator in the loop. This is also where digital twins (or device shadows) earn their keep: a server-side model of each device's desired and reported state, so you can manage a device that's currently offline and reconcile it when it reconnects.
Updates are the feature that decides everything
Hardware in the field will need new firmware and software for as long as it lives — for security patches if nothing else. Over-the-air (OTA) updates are not a nice-to-have; they're the difference between a fleet you can maintain and a recall. And OTA done carelessly is its own disaster: a bad update pushed to every device at once can brick the entire fleet remotely.
A real update system does this safely:
- Staged rollouts. Update a small percentage first, watch the telemetry, then expand. Never all at once.
- Atomic updates with rollback. A failed or interrupted update leaves the device on its last known-good image, not bricked.
- Signed images. Devices only accept updates signed by you, so a compromised channel can't push malicious firmware.
Operations: you can't fix what you can't see
A fleet you can't observe is a fleet you'll find out about from angry customers. The platform needs telemetry and health from every device, aggregated into something a human can actually act on — fleet-wide views, not a firehose of per-device logs. Pair that with role-based access control so the right people can take the right actions (and an audit trail of who did what), and you can operate thousands of devices with a small team instead of being operated by them.
The unglamorous list that makes it real
Put together, a production device platform needs:
- Identity & access: per-device PKI, mutual TLS, RBAC, secrets management
- Provisioning: zero-touch onboarding, configuration management
- State: digital twins / device shadows, reliable persistence
- Updates: signed, staged, atomic OTA with rollback
- Operations: telemetry, observability, audit logging, fleet-wide control
- Integration: APIs and webhooks so the fleet connects to the rest of your business
None of it is exotic on its own. The engineering is in making it work together, securely, for years, across hardware you designed yourself — and in building it so it scales from ten devices to ten thousand without a rewrite.
Where teams get stuck
The common failure is building the device first and the platform never — shipping hardware that works in a demo, then discovering there's no safe way to update it, no way to onboard the next thousand, and no way to see what the fleet is doing. The platform is harder to retrofit than to plan.
If you're putting bespoke hardware into the field and the platform layer is still a question mark, that's exactly the kind of architecture worth getting right before the fleet grows past the point where you can fix it by hand.