IoT Security

What it is

IoT security addresses the unique challenges of securing physical devices that operate in untrusted environments, often without a human operator present. Unlike server security where the hardware is physically protected in a data centre, IoT devices may be accessible to anyone with physical access to a building, factory floor, or outdoor installation. The attack surface includes the device firmware, the network transport, the cloud backend, and the physical device itself.

Core IoT security controls include: strong per-device identity using X.509 certificates (not shared passwords), mutual TLS (mTLS) for transport-layer authentication, hardware-backed secure storage (TPM 2.0 or discrete secure element) for private keys, cryptographically signed OTA firmware updates to prevent malicious firmware injection, and network segmentation to limit lateral movement from compromised devices.

Why it exists

IoT devices have been the entry point for some of the largest attacks in computing history. The Mirai botnet (2016) compromised 600,000+ IoT devices using default credentials and used them to launch the largest DDoS attack seen at the time. IoT devices are attractive targets because they are numerous, long-lived, have constrained OS images without EDR tooling, and are often forgotten once deployed. A compromised IoT device can exfiltrate data, serve as a pivot point for lateral movement onto OT or IT networks, or be enlisted in a botnet.

When to use

All IoT systems require baseline security controls. The depth of controls should match the risk profile: a home smart bulb requires less security than a device on a hospital OT network or a device with physical access to safety controls. Use the PSA Certified framework, ETSI EN 303 645 (consumer IoT), or NIST IR 8259 (IoT security baseline) to calibrate control depth to device risk category.

Typical architecture

PER-DEVICE X.509 IDENTITY
──────────────────────────
  Each device has a unique X.509 certificate signed by your root CA
  Private key NEVER leaves the device (generated on-device or in factory HSM)
  Certificate includes: deviceId (CN), device type (OU), manufacturer (O)
  Certificate stored in: TPM 2.0 key slot, secure element, or eFuse-protected flash

  Why unique certs (not shared):
  - Single compromised cert revocation does not affect other devices
  - Enables per-device access control policies
  - Audit trail: which device published what telemetry

MUTUAL TLS (mTLS)
──────────────────
  Standard TLS: client validates server certificate
  mTLS: server ALSO validates client certificate (device cert)
  → Device is cryptographically authenticated at the transport layer
  → Prevents spoofed devices from injecting false telemetry
  → MQTT over mTLS: port 8883; AWS IoT Core, HiveMQ, EMQX

  Policy attached to certificate (AWS IoT example):
  Allow:  iot:Connect (clientId = ${iot:Certificate.Subject.CommonName})
  Allow:  iot:Publish (topic = "acme/devices/${iot:Certificate.Subject.CommonName}/telemetry")
  Allow:  iot:Subscribe (topic = "acme/devices/${iot:Certificate.Subject.CommonName}/commands")
  → Device can ONLY publish to its own topic, not other devices' topics

TPM 2.0 AND SECURE ELEMENTS
─────────────────────────────
  TPM 2.0 (Trusted Platform Module):
  - Discrete chip (or firmware TPM on modern ARM SoCs)
  - Hardware random number generator
  - Key storage: private keys generated inside, never exportable
  - PCR (Platform Configuration Registers): measure boot firmware, OS
  - Remote attestation: prove to cloud that device booted known-good software

  Secure Element (SE) / eSIM-style chips:
  - OPTIGA Trust M (Infineon), ATECC608 (Microchip)
  - Tamper-resistant hardware; physical attack detection
  - Pre-provisioned at factory with device unique certificate
  - I2C/SPI interface; suitable for resource-constrained MCUs

SECURE BOOT
────────────
  Bootloader verifies firmware binary before executing it
  Chain of trust:
  ROM → immutable bootloader (root of trust)
       → signed bootloader stage 2 (manufacturer key)
       → signed application firmware (manufacturer key)
  Any step with invalid signature: boot halts

  Public key burned into eFuse or OTP flash at manufacturing (immutable)
  Firmware signed with manufacturer private key (stored in offline HSM)

OTA FIRMWARE SIGNING
─────────────────────
  Firmware binary signed with manufacturer private key before release
  Device verifies signature before writing to flash or executing
  Hash: SHA-256 of firmware binary
  Signature: ECDSA-P256 (preferred; smaller than RSA for constrained devices)

  Full verification flow:
  1. Download firmware from CDN
  2. Compute SHA-256 of downloaded binary
  3. Verify ECDSA signature against manufacturer public key (stored in device)
  4. Verify version > current version (prevent downgrade attacks)
  5. Write to inactive partition
  6. Bootloader re-verifies on next boot before executing

CERTIFICATE ROTATION AT SCALE
───────────────────────────────
  Problem: 100k devices, certs expire in 3 years; rotate before expiry

  Rotation flow:
  1. Cloud generates new cert for device, stores as "pending" in registry
  2. Cloud pushes new cert to device via shadow desired state or MQTT message
  3. Device stores new cert in secure storage alongside old cert
  4. Device reconnects using NEW cert, reports success via shadow
  5. Cloud marks rotation complete, deactivates old cert
  6. Cloud revokes old cert (adds to CRL / OCSP)

  Automation: AWS IoT Device Advisor, custom Lambda + IoT Jobs

MQTT BROKER AUTH & ACLs
─────────────────────────
  Authentication: mTLS (preferred) or username/password with JWT
  Authorisation (ACL policy per cert):
  - Publish: device can only publish to its own topic namespace
  - Subscribe: device can only subscribe to its own command topic
  - Connect: clientId must match certificate CN (prevents impersonation)

IOT NETWORK SEGMENTATION
──────────────────────────
  IoT VLAN: segregate IoT devices from corporate LAN and OT network
  Firewall rules:
    IoT VLAN → IoT broker (port 8883): ALLOW
    IoT VLAN → corporate LAN:          DENY
    IoT VLAN → Internet (HTTPS/443):   ALLOW (for OTA downloads)
    Corporate LAN → IoT VLAN:          DENY (manage via cloud, not direct)
  → A compromised IoT device cannot reach internal services or pivot to IT/OT

Pros and cons

Implementation notes

Factory provisioning: The most secure approach is to generate the device private key inside the secure element or TPM at the factory, create a Certificate Signing Request (CSR), and have your PKI sign it — the private key never leaves the hardware. If using a factory HSM to pre-inject keys, ensure the HSM generates unique keys per device and that the provisioning line network is isolated. Audit the provisioning process as it is the root of your entire device identity chain.

Downgrade attack prevention: OTA signature verification is necessary but not sufficient — an attacker could replay a legitimately signed but vulnerable old firmware version. Embed a monotonic version counter (ratchet) in firmware or in TPM NV storage; refuse to install any firmware with a version number equal to or less than the current value.

Common failure modes

• Default credentials: Devices shipping with default username/password (admin/admin, user/1234) that are never changed represent the IoT security failure mode responsible for the most large-scale compromises (Mirai et al.).
• Hardcoded credentials in firmware: Embedding API keys, MQTT passwords, or cloud endpoint credentials in firmware binaries; these can be extracted by anyone who downloads the firmware update and decompiles it.
• No certificate expiry monitoring: Certificates expire silently, causing devices to stop connecting; monitor cert expiry across the fleet and initiate rotation campaigns 90 days before expiry.
• Flat IoT network (no segmentation): IoT devices on the corporate LAN with no firewall restrictions allow a compromised sensor to probe and attack internal services.

Decision checklist

• Does every device have a unique X.509 certificate, not a shared credential?
• Is MQTT transport secured with mTLS (not username/password)?
• Are private keys stored in hardware (TPM 2.0 or secure element)?
• Is secure boot enabled with the root of trust burned into immutable storage?
• Are OTA firmware updates cryptographically signed and verified on device?
• Are IoT devices on a segregated VLAN with firewall rules denying access to corporate and OT networks?

Example use cases

• Smart meter deployment (utility): 5M meters; ATECC608 secure element per device; factory provisioning with unique cert; mTLS to AMI head-end; OTA signed with HSM-held key; separate RF mesh network completely isolated from IT; certificate rotation every 5 years via automated Job.
• Industrial robot arm: TPM 2.0 for key storage; secure boot with manufacturer root of trust; OTA updates only accepted during scheduled maintenance windows (network access control); device on OT VLAN; mutual TLS to local MQTT broker with per-device ACL policy.

Related patterns

• Device Management — Certificate provisioning and rotation are core device management operations.
• IoT Architecture — Security controls layer on top of the core MQTT/cloud architecture.
• Security Architecture — Broader security patterns (zero trust, PKI, network segmentation) that underpin IoT security.

Further reading

• ETSI EN 303 645 — Cyber Security for Consumer IoT
• NIST IR 8259 — IoT Device Cybersecurity Capability Baseline
• X.509 client certificates — AWS IoT Core