Migrating 2,000 School Sensors from a Shared Credential to Per-Device Identity
An environmental monitoring rollout has 2,000 sensors installed in school buildings across a region. Firmware revision 1.4 embeds one shared MQTT username and password in every device; the same credential also authorizes writes to the provisioning topic. During a penetration test, a contractor extracted the credential from one device and published forged PM2.5 values for six hours before anyone noticed. The fleet is mixed: 1,400 devices support TLS 1.2 with a key stored in protected flash, 450 have no secure element but can store a file-based key, and 150 are 8-bit controllers with 64 KB RAM that cannot complete a TLS handshake. Devices are behind building firewalls with outbound 8883 only; physical access for reflashing costs about 45 minutes per device and requires a site visit. The program needs per-device identity, revocable credentials, and a migration that does not require replacing the 8-bit units this year. The security team wants a threat model and a phased plan before the next school term.
1. Produce a threat model for the shared credential and rank the risks that matter most for this school deployment.
Read the worked answer
A shared credential collapses 2,000 devices into one identity. Spoofing: anyone with the credential can publish as any device, as the penetration test showed. Integrity: forged PM2.5 values can trigger ventilation changes or school closures; in a school context this is safety-relevant and reputational. Repudiation: logs cannot distinguish the compromised device from a legitimate one, so incident response cannot scope the breach. Privacy: broad topics could expose occupancy or classroom conditions. Lateral movement: the same credential authorizes the provisioning topic, so an attacker can enroll rogue devices or overwrite configuration. Availability: revocation means reflashing or breaking the whole fleet, so operators may delay. Rank credential abuse and provisioning-topic write as critical; forged sensor data as high; fleet-wide revocation risk as high. Include trust boundaries: building firewalls, contractor access, and physical device access. The migration should first remove write access to the provisioning topic, then introduce per-device identity, so the highest-impact path is closed even before every device is rekeyed.
2. Design a tiered identity architecture that fits the three hardware classes and the outbound-only network constraint. Explain where the trust boundary moves and how you would protect it.
Read the worked answer
Use a tiered model rather than forcing one mechanism onto all hardware. For the 1,400 TLS-capable devices, issue per-device X.509 certificates from a private CA with short lifetimes, for example 90 days, and automated renewal; map the certificate subject to device_id in broker ACLs so each device can write only its own topic. For the 450 file-key devices, use per-device credentials stored in a protected file, plus a single-use bootstrap claim code that expires and is exchanged for a short-lived token scoped to the device. For the 150 8-bit units, terminate TLS at a hardened local gateway: each device authenticates with a per-device pre-shared key or HMAC over its payload, and the gateway presents a certificate to the broker and enforces topic ACLs. This keeps the 8-bit units in service but moves the trust boundary to the gateway. Physically secure it, disable unused ports, log all attached device IDs, and segment it from school networks. Do not reuse the shared credential as the gateway credential. Configure the broker with deny-by-default ACLs and test that no device can publish to another device's topic.
3. Define a phased migration and the monitoring that would detect a repeat of the forged-data incident. Include rollback and acceptance criteria.
Read the worked answer
Phase by building and hardware class, not big bang. Phase 0: remove write access to the provisioning topic from the shared account, create per-device ACL templates, and enable broker audit logs. Phase 1: enroll the 1,400 TLS devices in batches of about 100 over two weeks; run dual authentication briefly, with old credentials read-only and new certificates required for write, then revoke old write access. Phase 2: deploy gateways for the 8-bit devices, one per building, validated in a pilot. Phase 3: migrate the 450 file-key devices, prioritizing sensitive areas. Monitor authentication failures per device, publishes from unexpected IPs, provisioning-topic writes, message-rate deviation, and certificate expiry. Define rollback: keep the old credential disabled but recoverable for 24 hours; quarantine a compromised device by ACL rather than changing a fleet-wide password. Acceptance: no device can publish to another device's topic, a revoked credential fails within one token lifetime, and an alert fires within five minutes when forged data or provisioning writes occur.