Securing IoT Devices in Production

IoT devices are the soft underbelly of most organizations' security posture. They run outdated firmware, have weak or default credentials, communicate over unencrypted channels, and are often deployed in physically accessible locations. The Mirai botnet compromised 600,000 IoT devices. The Verkada breach exposed 150,000 security cameras. These aren't hypothetical risks — they're the reality of IoT in production.

At Vaarak, we've secured IoT deployments ranging from industrial sensors in manufacturing plants to medical devices in hospitals. This guide covers the security practices we implement at every layer: device hardware, firmware, communication, cloud backend, and operational monitoring.

Layer 1: Hardware Security

Security starts at the hardware level. Every device should have a hardware root of trust — a secure element or Trusted Platform Module (TPM) that stores cryptographic keys in tamper-resistant silicon. This ensures that even if an attacker gains physical access to the device, they cannot extract the private keys used for authentication and encryption.

• Use secure elements (ATECC608B, STSAFE-A110) for key storage — never store keys in flash memory
• Enable secure boot: verify firmware signature before execution using the hardware root of trust
• Disable debug interfaces (JTAG, SWD) in production firmware through hardware fuses
• Use unique per-device identities provisioned during manufacturing, not shared credentials
• Implement physical tamper detection for high-security deployments (medical, financial)

Layer 2: Firmware Security

Firmware is the attack surface that most IoT manufacturers neglect. Hardcoded credentials, buffer overflows, and unencrypted storage are still depressingly common. We follow a firmware security checklist for every project.

#include "crypto/ecdsa.h"
#include "secure_element.h"

// Verify firmware image before booting
boot_status_t secure_boot_verify(const firmware_image_t* image) {
    // 1. Read public key from secure element (not flash!)
    uint8_t pub_key[64];
    se_read_public_key(FIRMWARE_SIGNING_KEY_SLOT, pub_key);

    // 2. Compute SHA-256 hash of firmware binary
    uint8_t hash[32];
    sha256_compute(image->data, image->size, hash);

    // 3. Verify ECDSA-P256 signature
    if (!ecdsa_verify(pub_key, hash, image->signature)) {
        // Signature invalid — do NOT boot
        log_security_event(EVENT_INVALID_FIRMWARE);
        enter_recovery_mode();
        return BOOT_FAILED;
    }

    // 4. Check firmware version (prevent rollback attacks)
    uint32_t min_version = se_read_counter(VERSION_COUNTER_SLOT);
    if (image->version < min_version) {
        log_security_event(EVENT_ROLLBACK_ATTEMPT);
        return BOOT_FAILED;
    }

    return BOOT_OK;
}

Layer 3: Communication Security

All device-to-cloud communication must be encrypted and mutually authenticated. We use TLS 1.3 with mutual authentication (mTLS) — the device authenticates the server, and the server authenticates the device. Each device has a unique X.509 certificate provisioned during manufacturing, with the private key stored in the secure element.

For constrained devices that can't handle full TLS, we use DTLS (Datagram TLS) over CoAP or MQTT-SN with pre-shared keys derived from the device's secure element. The key point is: no unencrypted communication, ever. Even on "private" networks, because network segmentation can fail.

Layer 4: Cloud Backend Security

The cloud backend is the central nervous system of an IoT deployment. It must enforce device identity verification, rate limiting, input validation, and anomaly detection. Every message from a device should be treated as potentially malicious — validate schema, check bounds, and monitor for abnormal patterns.

• Device identity: Verify device certificates against a CA chain on every connection
• Rate limiting: Cap messages per device per minute — a compromised device shouldn't be able to DDoS your backend
• Input validation: Schema-validate every message. Reject unexpected fields, out-of-range values, and malformed payloads
• Anomaly detection: ML-based baseline of normal device behavior. Alert on deviations (sudden increase in message frequency, unusual payload sizes, connections from unexpected IPs)
• Audit logging: Record every device action for forensic analysis

Layer 5: OTA Update Security

Over-the-air updates are both the most important security feature and the most dangerous attack vector. A compromised OTA mechanism lets an attacker push malicious firmware to your entire fleet. Every OTA update must be code-signed, version-checked (to prevent rollback attacks), transmitted over encrypted channels, and verified on-device before installation.

We implement a staged rollout strategy: updates go to 1% of devices first, then 10%, then 100% — with automated monitoring at each stage. If error rates spike or devices go offline, the rollout automatically pauses and the team is alerted.

Incident Response for IoT

When (not if) a security incident occurs, you need the ability to respond at fleet scale. This means remote device quarantine (block a compromised device from the network), forced firmware update, credential rotation, and forensic data collection. Build these capabilities before you need them.

“In IoT security, assume breach. Every device will eventually be compromised, lost, or stolen. The question is not whether your perimeter will be breached, but whether your defense-in-depth strategy limits the blast radius when it happens.”

— Lisa Patel, Vaarak Security

IoT security is a continuous process, not a checklist you complete once. New vulnerabilities emerge, threat landscapes evolve, and devices deployed today will be in the field for 5-10 years. Build security into your development process, automate security testing, and plan for the long lifecycle of connected devices.