# Production MQTT Security Checklist

Use this checklist before launch, after material policy or identity changes, and during incident exercises. Record an owner, evidence link, and review date for every item. Never paste live credentials into this document.

Deployment: ──────────────────── Owner: ──────────────────── Review date: ────────────────────

## Transport security

- [ ] Production clients use MQTT over TLS or secure WebSocket; plaintext listeners are not reachable from production networks.
- [ ] Clients validate the broker certificate chain, hostname, validity period, and intended trust anchor. Verification cannot silently fall back to insecure mode.
- [ ] The broker uses a currently supported TLS configuration and a documented server-certificate renewal process.
- [ ] Device clocks and trust stores can be updated safely before certificates expire or roots change.
- [ ] A test with an expired, untrusted, or wrong-host certificate fails closed.

## Device identity

- [ ] Every physical device, gateway, and backend client has a unique, inventory-linked identity and credential.
- [ ] No fleet-wide password, private key, or token is embedded in firmware, source code, spreadsheets, or shared images.
- [ ] Client IDs and session ownership are bound to the authenticated identity where the broker supports that check.
- [ ] Secrets or private keys are protected at rest; hardware-backed storage is used where the threat model requires it.
- [ ] Username/password, mTLS, or token authentication was selected based on the device's storage, renewal, clock, and recovery constraints.

## Topic authorization

- [ ] The default outcome is deny; every publish and subscribe permission has a documented workload need.
- [ ] Publish and subscribe are reviewed separately, including retained messages and shared subscriptions where used.
- [ ] Topic filters bind tenant, site, device, and role boundaries to authenticated identity rather than user-supplied payload fields.
- [ ] Field devices do not receive broad `#` access. Any wildcard is justified, bounded, and tested.
- [ ] Positive tests cover expected telemetry and commands; negative tests cover sibling devices, other tenants, broad wildcards, and unauthorized command paths.
- [ ] Policy-template changes are reviewed for their effect on every attached device.

## Credential rotation and revocation

- [ ] The inventory records credential type, issue time, expiry, owner, policy, last use, and recovery path.
- [ ] Planned rotation creates a replacement with equal or narrower permissions and a short, measured overlap window.
- [ ] The new credential is proven with full TLS validation plus positive and negative Topic tests before cutover.
- [ ] Revocation disables the server-side identity, terminates existing sessions, and verifies that reconnect and publish attempts fail.
- [ ] Old secrets are removed from devices and secret stores; later use of a revoked identity raises an alert.
- [ ] Suspected compromise skips planned overlap: revoke first, preserve evidence, then re-establish device trust before replacement.

## Network controls

- [ ] Broker ingress is limited to required ports, networks, private paths, or approved gateways.
- [ ] Device, broker, control-plane, and administrative networks are segmented according to risk.
- [ ] Connection, authentication, publish, and subscription rates have limits appropriate to fleet behavior.
- [ ] DNS, routing, proxy, and firewall changes are controlled and auditable.
- [ ] Capacity and reconnect behavior have been tested for outages, reconnect storms, and slow consumers.

## Monitoring and audit

- [ ] Logs identify the authenticated identity, client ID, source, outcome, and timestamp without recording live secrets.
- [ ] Alerts cover authentication failures, denied Topics, unusual wildcards, reconnect bursts, traffic anomalies, and revoked-identity use.
- [ ] Credential issuance, revocation, policy changes, and operator actions are auditable and exported outside the mutable control plane where required.
- [ ] Time synchronization, retention, access controls, and privacy requirements for security logs are documented.
- [ ] Monitoring distinguishes device, broker, control-plane, and network failures so responders can find the breached boundary.

## Incident response

- [ ] A named responder can revoke one device without rotating or interrupting the fleet.
- [ ] The runbook covers containment, active-session termination, evidence preservation, scope analysis, replacement, and recovery validation.
- [ ] Recovery credentials and privileged access are separated from daily operator accounts and tested securely.
- [ ] The team can identify every policy, Topic, retained message, and downstream consumer reachable by a compromised identity.
- [ ] A tabletop or technical revocation exercise is completed on schedule, with findings assigned and retested.

## Evidence and acceptance

- [ ] Threats, controls, remaining risks, and product/platform limitations are documented separately.
- [ ] Configuration examples were executed in an isolated environment or explicitly marked illustrative.
- [ ] No screenshot, test fixture, ticket, or checklist contains a live credential or production payload.
- [ ] Security, operations, and workload owners accepted remaining risks and set the next review date.

Primary references: [OASIS MQTT 5.0 Security](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Toc3901251), [Eclipse Mosquitto broker configuration](https://mosquitto.org/man/mosquitto-conf-5.html), [Eclipse Mosquitto ACL file plugin](https://mosquitto.org/documentation/plugins/acl-file/), [AWS IoT Lens identity and access management](https://docs.aws.amazon.com/wellarchitected/latest/iot-lens/identity-and-access-management.html), and [OWASP Network Segmentation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html).