IoT

Securing a consumer IoT fleet at scale

The context

An international industrial group was shipping connected consumer devices in very high volume. Every unit sold is a potential entry point: if a device identity can be impersonated, its network pairing intercepted, or unsigned firmware pushed to it, the problem stops being one customer’s and becomes the entire installed base’s.

The group needed an architecture that could register devices by the hundreds of thousands, update them remotely without ever opening a hole, and give its internal teams a view of the fleet’s real state.

What we did

We designed and implemented the complete chain of trust around AWS IoT Core.

Chain of trust from a per-device identity to a signed over-the-air updateEvery device holds its own identity and connects to AWS IoT Core over mutual TLS, under a policy scoped to that single device. Lambda drives provisioning and update campaigns, and DynamoDB holds the fleet state: connection status, the firmware versions actually deployed and campaign outcomes. Firmware artefacts are signed with keys held in AWS KMS, stored in S3 and distributed through CloudFront. Each device verifies the signature before installing, rollout is staged and a rollback path stays available. Updated devices report back through the same chain.Chain of trust, device to updateDevice Aunique identityDevice Bunique identityDevice Cunique identityshipped at scaleAWS IoT Core — mutual TLS, one policy per deviceLambda — provisioning, update campaignsDynamoDB — fleet state, deployed versionsSigned firmware — keys in KMS, artefacts in S3, served by CloudFrontSignature verified on the device — staged rollout, rollback availableOTA
The trust boundary is the device identity, not the product line: a compromised unit cannot act on the others, and nothing installs without a signature the device checks itself.
  • Secure device provisioning, with a unique identity per device and network pairing that does not rely on a secret shared across a whole product line.
  • Signed over-the-air updates, with signature verification on the device. The signing keys are held in AWS KMS and never leave it: a firmware signing key that travels through a build pipeline is a key that can no longer be treated as private. Firmware artefacts are stored in S3 and distributed through CloudFront, so hundreds of thousands of devices can pull the same release without hammering a single origin.
  • Canary deployment, because a firmware release cannot be fully tested in a lab: the real fleet holds hardware variants, unreliable networks and devices that have been offline for months. A release goes to a small cohort first, whose post-update boot and reconnection rates are watched; the campaign only widens if those hold, and the rollback path stays available throughout. That is what separates a fleet update from a gamble.
  • Least-privilege authorisation, per device, so that a compromised unit cannot act on the others or read anything that is not its own.
  • Supervision and fleet management tooling for internal teams: connection state, the firmware versions actually deployed, update campaigns in flight, failed devices and why they failed. Fleet state is held in DynamoDB, written as device events arrive rather than reconstructed on demand.

The outcome

The group has a foundation it adds new product lines to without redoing security from scratch, and its teams can see the state of the fleet rather than infer it from support tickets.

The most valuable part is the least visible one: updating a deployed fleet became a routine act rather than an operation postponed out of caution. That is what turns patching a vulnerability into a matter of days instead of months.

All case studies

Talk to us directly

Write to us directly. No salesperson, no qualification call. One of us two replies, within 24 hours.

contact@onescale.io

We reply within 24 hours, and it is one of us who replies.

Based in Lyon, working with clients in France, across Europe and internationally.