IoT Security Basics: Provisioning, Keys, and Trust

Quickstart

If you only do a few things, do these. They’re the highest-leverage moves for IoT security basics: they reduce the blast radius of a compromise, prevent fleet-wide takeovers, and make incident response possible.

Overview

“IoT security” can feel huge: radio links, firmware, cloud, apps, manufacturing, and end users. But the foundation is surprisingly small: identity, keys, and trust decisions. If you get those right, everything else becomes easier to reason about.

We’ll use a lifecycle lens. Most bugs happen at transitions: factory → customer, onboarding → normal operation, update → rollback, and decommission → reuse/resale.

Core concepts

Let’s align on a few terms. Most teams don’t fail because they don’t know crypto; they fail because they don’t have a consistent model of what is trusted, when, and why.

Provisioning vs onboarding vs enrollment

Root of trust and the chain of trust

A root of trust is the smallest component you assume is trustworthy. Everything else is verified against it. In embedded systems, this is typically a ROM bootloader, a hardware secure element/TPM, or a verified first-stage bootloader.

Key types you’ll actually use

You don’t need ten keys to be secure, but you do need the right separation. The simplest robust approach is: one device identity key + one update verification key (public) + derived session keys during communication.

Step-by-step

Below is a practical, “works in production” flow. It’s vendor-neutral and scales from hobby deployments to real manufacturing. The details change per cloud/provider, but the security decisions are the same.

Step 1 — Write a threat model (small, specific)

Step 2 — Choose an identity strategy

For most connected IoT devices, a per-device asymmetric keypair is the cleanest choice. It supports strong authentication, secure provisioning, and per-device revocation.

Step 3 — Provision credentials (factory or first boot)

There are two common patterns: (1) generate keys inside the device and have the factory sign a CSR, or (2) inject keys during manufacturing (more risk; requires stronger handling controls). Prefer generating keys on the device when possible.

# Demo: create a small CA and sign a device certificate (for learning/testing).
# In production, your CA should be protected (HSM), audited, and separated by environment.

# 1) Create a root CA key + certificate
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
  -subj "/CN=unilab-demo-root" -out ca.crt

# 2) Generate a device keypair (ECDSA P-256) and CSR
openssl ecparam -name prime256v1 -genkey -noout -out device.key
openssl req -new -key device.key \
  -subj "/CN=device-000123/O=unilab-demo" -out device.csr

# 3) Sign the CSR with the CA
openssl x509 -req -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out device.crt -days 365 -sha256

Step 4 — Onboard devices with a safe claim flow

Onboarding answers: “which customer owns this device?” The most common mistake is letting a device be claimed using only a serial number (easy to guess) or a barcode that never expires (easy to copy).

Step 5 — Enforce least privilege in cloud policies

The cloud side is where you prevent “device A publishes commands to device B.” Bind authorization to device identity and keep topic/API permissions tight.

{
  "version": "2026-01-09",
  "statement": [
    {
      "effect": "allow",
      "action": ["connect"],
      "resource": ["device:${deviceId}"]
    },
    {
      "effect": "allow",
      "action": ["publish"],
      "resource": [
        "topic:devices/${deviceId}/telemetry",
        "topic:devices/${deviceId}/status"
      ]
    },
    {
      "effect": "allow",
      "action": ["subscribe"],
      "resource": ["topicfilter:devices/${deviceId}/commands/#"]
    },
    {
      "effect": "deny",
      "action": ["publish", "subscribe"],
      "resource": ["topic:devices/*/commands/#"]
    }
  ]
}

Step 6 — Implement mTLS on the device (and rotate operational creds)

A typical flow is: use the device certificate to establish a secure connection, then request short-lived operational credentials (tokens) for app-specific access. This gives you a clean rotation story without touching the hardware identity often.

# Example: connect to an MQTT broker using mutual TLS (mTLS) and publish telemetry.
# You can adapt this pattern to your platform/language; the important part is:
# device cert + private key authenticate the device, and the broker verifies the CA chain.

import ssl
import time

import paho.mqtt.client as mqtt  # pip install paho-mqtt

BROKER_HOST = "mqtt.example.com"
BROKER_PORT = 8883

DEVICE_ID = "device-000123"
CA_CERT = "ca.crt"
DEVICE_CERT = "device.crt"
DEVICE_KEY = "device.key"

client = mqtt.Client(client_id=DEVICE_ID, clean_session=True)

tls_ctx = ssl.create_default_context(cafile=CA_CERT)
tls_ctx.load_cert_chain(certfile=DEVICE_CERT, keyfile=DEVICE_KEY)
tls_ctx.check_hostname = True
tls_ctx.verify_mode = ssl.CERT_REQUIRED

client.tls_set_context(tls_ctx)
client.connect(BROKER_HOST, BROKER_PORT, keepalive=30)
client.loop_start()

for i in range(3):
  payload = {"deviceId": DEVICE_ID, "tempC": 23.4 + i, "ts": int(time.time())}
  client.publish(f"devices/{DEVICE_ID}/telemetry", str(payload), qos=1)
  time.sleep(2)

client.loop_stop()
client.disconnect()

Step 7 — Secure OTA updates (signed, versioned, rollback-safe)

OTA is where attackers go when they can’t break your crypto directly. If an attacker can trick devices into installing malicious firmware (or downgrading to a vulnerable version), your fleet becomes a botnet.

Common mistakes

These mistakes show up in real fleets (not just tutorials). The fixes are usually cheaper than a breach response and dramatically improve reliability.

FAQ

What is device provisioning in IoT security?

Provisioning is the process of giving a device its initial security identity and trust anchors — typically generating or injecting a unique key, installing a certificate (or PSK), and registering that identity in your backend so the device can authenticate later.

Should IoT devices use certificates or pre-shared keys?

Certificates (with per-device asymmetric keys) are usually the safer default because they support strong authentication, least privilege, and per-device revocation. PSKs can work for constrained devices, but only if they are unique per device and you have a solid rotation plan.

Where should the private key live on an embedded device?

Ideally in a secure element/TPM/TEE so it’s non-exportable. If that’s not possible, store it in protected flash with readout protections enabled, rely on secure boot to reduce malware extraction, and assume sophisticated physical attackers may still extract keys.

What does “chain of trust” mean for IoT?

It means each stage verifies the next: a trusted boot component verifies firmware signatures, firmware uses a protected identity to authenticate to the cloud, and the cloud authorizes actions based on that verified identity. No single “I promise I’m legit” step should be trusted without verification.

How do you revoke a compromised IoT device?

You revoke at the identity layer: mark the device as quarantined/revoked in your registry and enforce that state in your authorization policies (e.g., deny connect/publish/subscribe). If you use certificates, you can also rotate or invalidate certs and re-provision the device only after remediation.

How do I secure OTA updates without overengineering?

Start with signed firmware images verified on-device before installation, keep update verification keys separate from identity keys, and prevent downgrade to vulnerable versions. If you can, use A/B partitions and staged rollouts to avoid bricking fleets.

What’s the minimum “must have” for IoT security basics?

Unique per-device identity, mutual authentication to backend, least-privilege authorization, signed OTA updates, and a revocation/quarantine mechanism. Those five cover the majority of preventable fleet compromises.

Cheatsheet

A scan-fast checklist you can use during design reviews, manufacturing prep, and release sign-off.

Wrap-up

IoT security basics are not about fancy algorithms. They’re about eliminating the “easy wins” attackers rely on: shared secrets, unverifiable identity, and updates you can’t trust. If you build a clean provisioning story and a clear chain of trust, you get a fleet that’s easier to operate, easier to debug, and dramatically harder to hijack.

Want to go deeper on the practical side of scaling provisioning and keeping embedded systems safe? Continue with the related posts below.

Related posts

• Device Provisioning at Scale: The Manufacturing Reality
• ESP32 Starter Guide: GPIO, Wi-Fi, and Real Projects
• Arduino to Prototyping: Sensors, Actuators, and Clean Wiring
• Raspberry Pi as a Home Server: Safe Setup and Use Cases
• UART vs I2C vs SPI: Which Protocol to Use and Why
• MQTT Explained: The Message Bus Behind Many IoT Systems