IoT System Development: How to Secure Device Credentials at Scale
Securing device credentials at scale is the first test of any IoT system development partner. Ask how keys are provisioned, rotated and revoked, and what happens when a device is lost.
Securing device credentials at scale means every device gets a unique identity that can be revoked without touching the rest of the fleet. When you commission IoT system development, apply three criteria: unique per-device keys, a documented rotation and revocation process, and a firmware update strategy that does not depend on physical access. These three separate a maintainable fleet from one that becomes a liability after the first lost device.
What is IoT development and what does it involve?
IoT development is the work of connecting physical equipment to software so that status, location or temperature is reported automatically instead of by phone. It involves four layers: device firmware, a connectivity protocol, a cloud platform that stores and routes data, and a dashboard or integration that people actually use.
The firmware layer reads sensors and manages the network connection. The protocol layer decides how messages travel — MQTT versus HTTP telemetry is a design choice, not a default, because MQTT keeps a persistent connection and suits frequent small updates, while HTTP suits infrequent batch uploads. The platform layer handles device fleet management: registration, credentials, firmware versions and last-seen status.
The application layer is where most projects succeed or fail. A dashboard that shows a temperature trend but cannot trigger an alert to a named person at 2 a.m. does not solve the operator's problem. If the dashboard cannot answer "which unit is out of range right now", the project is not finished.
For industrial IoT solutions, the same four layers apply, but the credential problem grows with the number of devices. A cold chain monitoring deployment with 200 sensors in 40 vehicles has 200 identities to manage, not one.
How should a vendor provision and protect device credentials?
A credible vendor provisions a unique key or certificate per device at manufacturing or installation time, and never ships a shared password across a fleet. Shared credentials mean one extracted key compromises every unit, and revocation becomes a fleet-wide operation.
Ask the vendor to describe the provisioning step in concrete terms. The answer should name the mechanism: a secure element, a hardware security module, or a first-boot enrolment over a trusted channel. If the answer is "we put the password in the firmware", the fleet is one dump away from compromise.
Rotation and revocation matter as much as initial provisioning. A device that is stolen, sold or redeployed must be removable from the fleet without reflashing the others. If revoking one device requires a platform-wide change, the design is wrong.
The delivery team controls the provisioning design and the platform's revocation API. The client controls physical access to devices and the list of who may authorise a revocation. Both sides need a written procedure, because the gap between them is where lost devices stay active.
What does a weak answer sound like when you ask about security?
A weak answer describes security as a feature rather than a process. Phrases like "we use encryption" or "the cloud provider handles it" without naming the key owner, the rotation interval or the revocation path are a warning sign.
Use this list to score the response. Each item should produce a named mechanism, not an adjective:
- Key ownership: who holds the private key, and can the vendor read device traffic?
- Provisioning: is the credential unique per device, and how is it injected?
- Rotation: how often are keys rotated, and does rotation require physical access?
- Revocation: what is the procedure for a lost or stolen device, and who authorises it?
- Firmware update strategy: can a security patch reach devices without a site visit?
- Audit trail: can you see which device connected when, and from where?
A strong answer will also distinguish what the vendor controls from what you control. If the vendor cannot say which security steps are theirs and which are yours, the handover will leave gaps.
| Criterion | Weak answer | Strong answer |
|---|---|---|
| Credential uniqueness | "All devices use the same key for simplicity" | "Each device has its own certificate, injected at first boot" |
| Rotation | "We can rotate if needed" | "Keys rotate on a schedule; rotation is remote and logged" |
| Revocation | "We would disable the account" | "One device can be revoked via API; others are unaffected" |
| Firmware update | "Updates are done on site" | "Signed updates are pushed over the air with rollback" |
| Audit | "The platform logs everything" | "You can query connection history per device for a defined period" |
How do you handle devices that lose connectivity?
Devices that lose connectivity should store readings locally and forward them when the link returns, with a timestamp that shows when each reading was taken. A design that drops data during an outage is unsuitable for cold chain monitoring, where a gap in the record is itself a compliance problem.
The protocol choice affects how outages are handled. MQTT with a persistent session and a local buffer lets a device reconnect and deliver queued messages. HTTP telemetry typically retries a batch, which is simpler but easier to lose. If the device cannot store at least one shift's worth of readings locally, the outage handling is incomplete.
The platform side needs a last-seen rule and an alert path. A device that has not reported for a defined interval should raise an alert to a named person, not merely change colour on a dashboard. The interval depends on how often readings are expected and how long a silent gap can be tolerated before it affects the business.
For fleets that move between networks, the connectivity layer should also handle roaming and SIM changes without re-provisioning credentials. This is a common gap in industrial IoT solutions that were designed for a single site.
What is MQTT and why is it used for IoT?
MQTT is a lightweight messaging protocol that keeps a connection open between a device and a broker, so the device can publish small updates without opening a new connection each time. It is used in IoT because it reduces bandwidth and power use on constrained devices and supports quality-of-service levels that define whether a message must arrive.
MQTT versus HTTP telemetry is not a religious choice. If devices report every few seconds and run on battery, MQTT is usually the better fit; if they upload a batch once a day, HTTP is simpler to operate. The decision depends on update frequency, power budget and whether the platform already supports one protocol well.
Whichever protocol you choose, the credential model must match it. MQTT brokers authenticate clients at connection time, so a per-device certificate fits naturally. HTTP endpoints authenticate per request, which makes token expiry and rotation a design item rather than an afterthought.
For a broader view of how these choices fit into a delivery plan, see our service overview and the articles index.
How much does an IoT system cost to build?
The cost of an IoT system depends on the number of device types, the credential and firmware model, the dashboard scope and the integrations with existing systems. There is no universal figure, because a single-site temperature monitor and a multi-country fleet with over-the-air updates are different products.
The largest cost driver is usually the firmware and provisioning work, not the dashboard. A project that requires secure elements, signed updates and a revocation API carries more engineering than one that reads a sensor and posts to a cloud endpoint. If a quote does not separate firmware, platform and dashboard costs, ask for the split before comparing vendors.
Ongoing cost depends on connectivity subscriptions, platform hosting and the support arrangement for devices in the field. These are operational costs the client controls, and they should be estimated per device per month before the project starts.
For operators in food wholesale, cold chain monitoring adds a record-keeping requirement that affects the platform design; our food wholesale page describes the context. Mining fleets face similar credential questions with harsher connectivity, covered under mining.
Frequently asked questions
What is IoT development and what does it involve?
IoT development involves building the firmware that reads sensors, the connectivity layer that carries data, the platform that manages devices and the dashboard or integration people use. It also includes the credential model that identifies each device and the update path that patches it. The scope depends on how many device types and sites are involved.
How much does an IoT system cost to build?
Cost depends on the number of device types, the credential and firmware model, the dashboard scope and the integrations required. Firmware and provisioning work usually carries more engineering than the dashboard. Ask for a split between firmware, platform and dashboard costs so you can compare quotes on the same basis.
How do you handle devices that lose connectivity?
Devices should store readings locally and forward them with timestamps when the link returns. The platform should raise an alert to a named person when a device has not reported within a defined interval. The interval depends on how often readings are expected and how long a gap can be tolerated.
What is MQTT and why is it used for IoT?
MQTT is a lightweight messaging protocol that keeps a connection open between device and broker, so small updates travel without reopening a connection each time. It suits devices that report frequently or run on battery. HTTP is often simpler for devices that upload a batch once a day.
How should device credentials be secured at scale?
Each device should have a unique key or certificate, provisioned at manufacturing or first boot, with a documented rotation and revocation process. Revoking one device must not require changes to the rest of the fleet. A firmware update strategy that can deliver security patches remotely is part of the same requirement.
Questions we are asked
What is IoT development and what does it involve?
IoT development involves building the firmware that reads sensors, the connectivity layer that carries data, the platform that manages devices and the dashboard or integration people use. It also includes the credential model that identifies each device and the update path that patches it. The scope depends on how many device types and sites are involved.
How much does an IoT system cost to build?
Cost depends on the number of device types, the credential and firmware model, the dashboard scope and the integrations required. Firmware and provisioning work usually carries more engineering than the dashboard. Ask for a split between firmware, platform and dashboard costs so you can compare quotes on the same basis.
How do you handle devices that lose connectivity?
Devices should store readings locally and forward them with timestamps when the link returns. The platform should raise an alert to a named person when a device has not reported within a defined interval. The interval depends on how often readings are expected and how long a gap can be tolerated.
What is MQTT and why is it used for IoT?
MQTT is a lightweight messaging protocol that keeps a connection open between device and broker, so small updates travel without reopening a connection each time. It suits devices that report frequently or run on battery. HTTP is often simpler for devices that upload a batch once a day.
How should device credentials be secured at scale?
Each device should have a unique key or certificate, provisioned at manufacturing or first boot, with a documented rotation and revocation process. Revoking one device must not require changes to the rest of the fleet. A firmware update strategy that can deliver security patches remotely is part of the same requirement.
