Zero trust for IoT and edge fleets: a practical model
An edge fleet has no perimeter to defend — the devices are in warehouses, vehicles, homes and factory floors, on networks you don't control. Zero trust is the only model that fits: every device, request and data flow is authenticated and authorised on its own merits, every time.
The four controls that matter
| Control | What it means for a device | Failure it prevents |
|---|---|---|
| Strong device identity | A hardware-bound key (TPM / secure element), not a shared secret | One extracted credential ≠ fleet-wide access |
| Short-lived, scoped tokens | Device gets a token for this action, expiring in minutes | A stolen token is worthless within the hour |
| Mutual TLS everywhere | Device verifies the backend; backend verifies the device | Rogue endpoints, on-path tampering |
| Least-privilege topics | A sensor can publish its own telemetry and nothing else | A compromised sensor can't send commands |
Device ──(mTLS, hardware key)──► Broker ──► only its own topic
│ │
└── token: {publish: sensor/42/telemetry}, ttl: 15m
Beyond the basics
- Signed firmware + secure boot. An unsigned update path is a fleet backdoor.
- Attested telemetry. The backend should be able to tell a genuine device reading from a spoofed one.
- Segmented backend. The service that ingests telemetry is not the service that issues commands.
- Assume a device is compromised. Model what one rogue device can do; if the answer is "move laterally" or "send commands", the topic scoping is wrong.
The rule
No shared secrets, no long-lived credentials, no implicit trust from being "on the network". Hardware identity, minute-scale scoped tokens, mutual TLS, and per-device topic permissions. Everything else is detail on top of those four.
END OF ANALYSIS