IoT and connected-device firmware security

Why this area matters

Weak, guessable or hard-coded passwords top the OWASP IoT Top 10, followed by insecure network services and insecure update mechanisms. Large botnets have been built from devices that shipped with one shared password, and an update channel without signature checks lets anyone who can reach the device replace its firmware.

Embedded code gets less scanner coverage than web code, and the important questions — is this image verified before flashing, is this credential unique per device — need reading the code path, not matching a single line.

What goes wrong in real applications

• Unsigned or unverified updates

  Firmware downloaded over cleartext or flashed without a signature check can be replaced with someone else's code.

• Shared or default device credentials

  One password or key across all devices means compromising one device compromises the fleet.

• Cleartext device-cloud traffic

  MQTT or HTTP without TLS exposes telemetry and commands, and lets an attacker on the path send commands to devices.

• Rollback to vulnerable firmware

  Accepting older firmware versions lets a patched device be downgraded to a known-vulnerable build.

Sample: the risky pattern and the fix

int ota_apply(void) {
    size_t len = http_get("http://updates.example.com/fw/latest.bin",
                          fw_buf, sizeof(fw_buf));
    flash_write(FW_SLOT_B, fw_buf, len);
    return boot_set_slot(FW_SLOT_B);
}

void telemetry_init(void) {
    mqtt_connect("mqtt://broker.example.com:1883", "device", "••••••");
}

int ota_apply(void) {
    size_t len;
    if (https_get(OTA_URL, CA_CERT, fw_buf, sizeof(fw_buf), &len) != 0)
        return -1;
    if (!verify_signature(fw_buf, len, VENDOR_PUBKEY))
        return -1;                     /* refuse unsigned or altered images */
    if (fw_version(fw_buf) <= current_fw_version())
        return -1;                     /* no rollback */
    flash_write(FW_SLOT_B, fw_buf, len);
    return boot_set_slot(FW_SLOT_B);
}

void telemetry_init(void) {
    mqtt_connect_tls(MQTT_URL, CA_CERT, device_cert(), device_key());
}

The original downloads firmware over plain HTTP and flashes it without checking where it came from, and every device logs into the broker with the same password over cleartext. The fix verifies a vendor signature and version before flashing, uses TLS, and authenticates each device with its own certificate. API names are illustrative.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• OTA update code: transport, signature verification, version and rollback checks
• Device credentials, keys and default passwords in firmware source and provisioning scripts (Gitleaks plus agent review)
• MQTT, CoAP and HTTP clients without TLS or certificate validation
• Debug interfaces and services (telnet, debug shells) enabled in release build config
• Device-cloud backend code and IaC in the same repository

Scope and limits

• It doesn't test physical devices, extract firmware from hardware, or probe device networks — it reads the source and build configuration in your repository.
• Hardware protections (secure boot fuses, debug-port locking) are only visible as far as the code and config describe them.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Network & transport security — Checks that data in transit is encrypted and certificates are actually verified.
• Cryptography — Checks that cryptographic primitives fit their purpose and keys, IVs and randomness are handled correctly.
• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.