<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: designing-secure-iot-architecture
description: >-
  Design secure IoT architectures with device identity management, secure boot chains,
  network segmentation for constrained devices, OTA update security, and monitoring
  for anomalous device behavior.
domain: cybersecurity
subdomain: security-architecture
tags:
  - iot-security
  - device-identity
  - secure-boot
  - ota-updates
  - mqtt
  - edge-security
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1200"]
---

# Designing Secure IoT Architecture

## Overview

Secure IoT architecture addresses the unique challenges of constrained devices,
heterogeneous protocols, and massive scale. This skill covers device identity
lifecycle, secure boot chains, network isolation, encrypted communication,
OTA update integrity, and behavioral anomaly detection.

Mode: `[MODE: ARCHITECT]` — IoT security design and device lifecycle management.

## Prerequisites

- IoT device inventory and specifications
- PKI or device identity service
- MQTT broker or IoT platform (AWS IoT, Azure IoT Hub)
- Python 3.10+

## Key Concepts

### IoT Security Architecture Layers

```
┌──────────────────────────────────────────────┐
│               Cloud / Backend                 │
│  (Device management, analytics, dashboards)  │
├──────────────────────────────────────────────┤
│               IoT Gateway / Edge             │
│  (Protocol translation, local processing)    │
├──────────────────────────────────────────────┤
│               Communication Layer            │
│  (MQTT+TLS, CoAP+DTLS, HTTPS)              │
├──────────────────────────────────────────────┤
│               Device Layer                   │
│  (Secure boot, TPM, device identity)        │
└──────────────────────────────────────────────┘
```

### Device Identity Lifecycle

| Phase | Action | Security Control |
|-------|--------|-----------------|
| **Provisioning** | Generate device identity | X.509 certificate from PKI |
| **Registration** | Register with IoT platform | Certificate-based authentication |
| **Operation** | Authenticated communication | mTLS, per-device policies |
| **Rotation** | Credential renewal | Automated certificate rotation |
| **Decommission** | Revoke and wipe | CRL update, remote factory reset |

### MQTT Security Configuration

```json
{
  "mqtt_broker": {
    "tls": {
      "enabled": true,
      "version": "1.3",
      "client_cert_required": true,
      "ca_certificate": "/certs/ca.pem"
    },
    "authentication": {
      "type": "x509",
      "fallback": "token"
    },
    "authorization": {
      "acl_type": "per-device",
      "default_deny": true,
      "rules": [
        {"client_id": "device-*", "topic": "devices/${client_id}/telemetry", "access": "publish"},
        {"client_id": "device-*", "topic": "devices/${client_id}/commands", "access": "subscribe"},
        {"client_id": "device-*", "topic": "devices/+/telemetry", "access": "deny"}
      ]
    },
    "rate_limiting": {
      "messages_per_second": 10,
      "max_payload_bytes": 8192
    }
  }
}
```

### Secure OTA Update Flow

```
1. Build → Sign firmware with code-signing key (HSM-backed)
2. Publish → Upload signed image to CDN with integrity manifest
3. Notify → Push update availability via MQTT command topic
4. Download → Device fetches image over TLS with certificate pinning
5. Verify → Device validates signature + version > current
6. Apply → Install to inactive partition, reboot, verify health
7. Rollback → Auto-revert if health check fails within timeout
```

### Device Network Segmentation

```yaml
segments:
  - name: iot-devices
    vlan: 100
    subnet: 10.100.0.0/16
    allowed_destinations:
      - target: iot-gateway
        ports: [8883]  # MQTT+TLS
        protocol: tcp
    blocked:
      - internet-direct
      - corporate-network
      - device-to-device
  - name: iot-gateway
    vlan: 101
    subnet: 10.101.0.0/24
    allowed_destinations:
      - target: cloud-iot-endpoint
        ports: [443]
        protocol: tcp
      - target: internal-api
        ports: [443]
        protocol: tcp
```

## Workflow

### Step 1: Inventory Devices

```bash
node scripts/agent.js --action inventory --devices devices.json
```

### Step 2: Design Security Controls

```bash
node scripts/agent.js --action design --devices devices.json --output controls.json
```

### Step 3: Generate Network Policies

```bash
node scripts/agent.js --action network --devices devices.json --output net-policies.json
```

### Step 4: Validate Security Posture

```bash
node scripts/agent.js --action validate --controls controls.json
```

## Detection

```yaml
title: Designing Secure Iot Architecture Detection
id: 779202df-2994-4fcf-b7e2-b8b890f56c9b
status: experimental
description: Detects suspicious activity related to designing secure iot architecture techniques in security architecture context
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    DestinationPort: 443
    Initiated: "true"
  condition: selection
level: medium
tags:
  - attack.t1200
  - attack.lateral_movement
falsepositives:
  - Network segmentation testing by authorized infrastructure teams
```

## Verification

- [ ] All devices have unique cryptographic identities
- [ ] Secure boot chain verified from bootloader to application
- [ ] Device-to-cloud communication encrypted (TLS 1.3 / DTLS)
- [ ] MQTT ACLs enforce per-device topic isolation
- [ ] OTA updates signed and verified before installation
- [ ] IoT network segment isolated from corporate network
- [ ] Anomaly detection baseline established per device class
- [ ] Decommissioning procedure includes credential revocation

## References

- [NIST SP 800-183 Networks of Things](https://csrc.nist.gov/publications/detail/sp/800-183/final)
- [OWASP IoT Security Verification Standard](https://owasp.org/www-project-iot-security-verification-standard/)
- [ETSI EN 303 645 Consumer IoT Security](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)
