For teams past the prototype stage — where security stops being a backlog item and becomes a release-blocker. This post covers four specific practices in production IoT security: cryptographic boot verification, signed OTA updates, encryption at rest and in transit, and per-device authentication. Informed by real embedded engineering work, not compliance checklists.

DigitalMonk IoT Engineering Team

Embedded Security & Firmware Engineering · Jalandhar, IN · Alpine, CA · Coventry, UK

The IoT Threat Surface

Before choosing security measures, it helps to be honest about what you are defending against. IoT attack vectors span a wider surface than traditional software systems:

Physical access — An attacker with the device in hand can probe debug interfaces, read flash, and extract firmware. Physical threats are relevant whenever devices ship into environments you do not control.
Firmware extraction and reverse engineering — Unprotected flash on a device left in the field is a readable storage medium. Extracting firmware enables attackers to find credentials, reverse engineer protocols, and identify vulnerabilities.
Communications interception — Unencrypted or improperly validated TLS sessions expose data in transit. On BLE, legacy pairing modes are trivially eavesdropped.
Cloud-side breach — If your device trusts a cloud endpoint using shared credentials, a cloud compromise affects every device in the fleet simultaneously.
OTA pipeline compromise — An unsigned OTA pipeline allows anyone who can talk to the device to install arbitrary firmware. This is one of the most exploited vectors in deployed IoT products.
Supply-chain and provisioning attacks — Credentials baked into firmware at manufacture, factory-default passwords that ship unchanged, and key material stored in version-controlled code are common failure modes.
Default credential leakage — Devices shipped with manufacturer-default credentials that users never change remain permanently accessible to anyone with the default table.

No product needs to defend against every threat at maximum strength. The right security model depends on what the device handles, who has access to it, and what the impact of compromise looks like. For a broader introduction to IoT threat modelling, our understanding security in IoT devices post covers the foundational concepts. This post goes deeper on four specific practices: secure boot, OTA update security, encryption, and device authentication.

Secure Boot

Secure boot is a chain-of-trust mechanism: on each power cycle, the bootloader cryptographically verifies the firmware image's signature before handing over execution. If the signature is invalid — meaning the firmware has been tampered with or replaced — the device refuses to boot. Only firmware signed with the corresponding private key (held securely off-device, typically in an HSM or equivalent) will run.

The chain-of-trust model anchors trust in an immutable root: a first-stage bootloader whose code cannot be overwritten (stored in ROM, or in write-protected flash with hardware enforcement). This root verifier checks the second-stage bootloader or application image. Tamper anywhere in that chain and the verification fails.

Platform Support

Secure boot is well-supported across common IoT SoC families, each with different implementations worth understanding:

Platform	Secure Boot Mechanism	Notes
ESP32	Secure Boot v2 (RSA-PSS 3072-bit or ECDSA)	eFuse-burned public key digest; v2 supports multiple signing keys; applies to bootloader and app partitions
nRF52 / nRF53	MCUboot with signature verification (ECDSA P-256 or RSA)	nRF53 adds hardware CryptoCell-312 for accelerated crypto; immutable bootloader in write-protected flash
STM32	RDP (Readout Protection) levels 0/1/2 + SBSFU / TFM	RDP2 is permanent — no JTAG access, flash read-protected; STM32Cube Secure Boot & Secure Firmware Update (SBSFU) provides full signed-image verification
Raspberry Pi	Limited — OTP-based boot verification on Pi 4/CM4 with signed bootloader	Not MCU-grade secure boot; Pi is a Linux SBC, and the secure boot story is materially weaker than dedicated MCUs. Worth being honest about if Pi is in your design.

Honest trade-offs: Secure boot adds real engineering overhead. Key management becomes a first-class concern — losing the signing private key means you cannot ship future firmware updates to that device family. Development workflows change: every test image needs signing, or you maintain a separate development signing key (which reduces the security guarantee during development). Recovery from a bricked device is harder — by design, invalid firmware cannot run. For products shipping into environments where physical access by adversaries is unlikely and the firmware content is not sensitive, secure boot may not be the first investment. Threat model first.

OTA Update Security

An unsigned OTA update pipeline is effectively a remote firmware installation backdoor. Anyone who can route a packet to your device — on the same network, via a compromised cloud endpoint, or through a man-in-the-middle position — can install arbitrary firmware. This is not a theoretical threat; it is one of the most frequently exploited attack surfaces in deployed consumer and industrial IoT.

What secure OTA looks like

1
Signed firmware images
Every firmware image is signed at build time with a private key held in offline key infrastructure. The device verifies the signature before accepting any image — unsigned or incorrectly signed images are rejected, never flashed.
2
Monotonic version enforcement (anti-rollback)
The device tracks a minimum acceptable version number. After successfully installing a new firmware version, the device will not accept any image with an older version counter. This prevents attackers who have obtained a valid signature for a previous (vulnerable) firmware version from downgrading the device.
3
Encrypted delivery for IP-sensitive firmware
If the firmware binary itself contains proprietary algorithms or sensitive logic, encrypting the OTA payload adds a layer of IP protection beyond the transport-layer encryption. Note: this is defence-in-depth for IP, not a substitute for signing — encryption does not prove integrity; signing does.
4
Atomic update with rollback-on-failure
The new firmware is written to a secondary slot and verified before the boot slot pointer is updated. If the new image fails verification, or if the device fails to boot the new image within a watchdog timeout, it rolls back to the previous known-good image. MCUboot implements this pattern well for nRF and STM32 targets.

For a full treatment of OTA architecture — slot management, delta updates, cloud delivery pipelines, and bandwidth considerations — see our OTA updates for IoT deep dive. This section covers the security dimension; the architecture details are there.

The most common production mistake: OTA without signing is consistently one of the most frequent security gaps we see in IoT products at or near release. It is often framed as "we'll add it later" — but adding OTA signing after hardware is in the field requires a field-firmware update to deploy the new bootloader, which itself requires signing infrastructure you don't yet have. Build it into the architecture from the start.

Encryption: In Transit and At Rest

Data in transit

TLS is the correct default for IoT cloud communication. TLS 1.2 is the minimum acceptable — TLS 1.3 is preferred for new designs, as it reduces handshake latency (one fewer round trip) and removes several cipher suites with known weaknesses. On extremely constrained devices (small MCUs with no TLS stack), DTLS over UDP is an option.

A critical and depressingly common mistake: shipping code with TLS certificate validation disabled. This is trivial to do during development (it eliminates cert management friction) and just as trivial to forget to re-enable at production. A TLS session without certificate validation provides encryption but not authentication — the device will happily negotiate an encrypted session with an attacker's server. Certificate pinning or strict chain validation must be enforced in production firmware.

For BLE, use LE Secure Connections (LESC) — which uses ECDH key exchange and provides forward secrecy — rather than legacy BLE pairing. "Just Works" pairing (no numeric comparison, no out-of-band confirmation) is acceptable when the threat model genuinely permits passive eavesdropping risk; for devices with a display, Numeric Comparison or Passkey Entry provides meaningful protection against active MITM during pairing.

For products handling sensitive personal data — for example, healthcare-adjacent devices we've built — we apply TLS-secured cloud communication as a baseline. This is not optional in those contexts; it is the floor, not the ceiling.

Data at rest

Key material should not live in plaintext flash. The consequences of flash extraction (via JTAG with RDP not enabled, or direct SPI flash attachment) are severe when keys are readable in cleartext — an attacker can clone the device identity, decrypt historical communications, or forge signed messages.

Hardware-backed key storage is the right answer when physical key extraction is a plausible threat:

Platform	Hardware Key Storage Mechanism
ESP32	eFuse key blocks — 256-bit keys burned one-time, not readable via software after burning. Flash encryption uses these keys.
nRF53 / nRF52840	Key Management Unit (KMU) — cryptographic keys pushed to CryptoCell hardware without software visibility; ARM TrustZone on nRF5340 provides isolated execution for key operations.
STM32 (with TrustZone)	ARM TrustZone on STM32L5/U5 — secure world / non-secure world isolation; secure storage APIs prevent non-secure application code from accessing key material.
Dedicated secure element	ATECC608, SE050, similar — tamper-resistant ICs with hardened key storage; integrates over I2C/SPI; highest assurance option, adds BOM cost.

Device Authentication

There is an important distinction between a device authenticating to the cloud and a cloud API key being used by the device. API keys shared across a fleet mean that compromise of any single device — or of the firmware itself — exposes credentials that affect every device in the fleet. Per-device authentication means compromise of one device's credentials affects exactly one device.

Authentication approaches

1
mTLS with per-device X.509 certificates
Each device holds a unique client certificate and private key. The cloud authenticates the device via the certificate chain, and the device authenticates the cloud via the server certificate. Per-device certificates mean revocation of a compromised device does not affect the fleet. This is the architecture used by AWS IoT Core, Azure IoT Hub, and Google Cloud IoT (per-device cert provisioning). The overhead is certificate management infrastructure at manufacture; at scale this is solved with factory provisioning tooling.
2
Pre-shared symmetric keys provisioned at manufacture
Simpler to implement than mTLS; each device has a unique symmetric key provisioned during manufacturing and stored in protected flash or a secure element. Works well for MQTT with HMACs or for protocols that support PSK-based TLS cipher suites. Key rotation is harder than with certificate-based approaches.
3
Hardware-backed device identity
Secure elements like the ATECC608 can generate and hold a device-unique key pair in hardware that never leaves the device. The public key is registered with the cloud at provisioning; thereafter, the device proves identity by signing challenges with its hardware-held private key. This provides the strongest per-device identity guarantee because the private key is physically non-extractable.

On crypto and blockchain-adjacent products we've built, we apply patterns such as on-device private-key isolation (transactions signed in hardware, keys never exposed to host software), smart-contract integration via APIs for on-chain state, and on-chain audit logging where tamper-evident records matter. The hardware-wallet pattern — private keys living entirely in the device's secure storage, with all signing operations occurring on-device — is directly applicable to high-assurance device identity scenarios beyond blockchain contexts.

DigitalMonk's Approach to Security in Practice

Security in production IoT is an engineering discipline, not a checklist exercise. The following is how we approach it on real products.

✓

Security checklist at firmware sign-off

Every production firmware release goes through a security checklist before sign-off — covering credentials, debug interfaces, secret material, OTA signing, and known-issue review. This is a process gate, not a formality. The checklist exists because the most common production security mistakes are not architectural failures — they are omission failures caught by systematic review.

✓

TLS as a baseline for sensitive-data products

For products handling sensitive personal data — for example, healthcare-adjacent devices we've built — we apply TLS-secured cloud communication as a baseline. This is the floor, not the entire security architecture; it is the first thing we confirm before considering other transport-layer decisions.

✓

Security thinking at the spec stage

The most expensive security fix is the one discovered at release. We introduce threat modelling and security requirements at the product specification stage — before hardware is locked and before firmware architecture is committed. Decisions about secure storage, OTA signing, and authentication model are architectural; they need to be made early.

For a broader view of our IoT engineering work — firmware, hardware, cloud connectivity, and security — see our IoT services page. Security is one dimension of production-grade embedded engineering; it does not stand alone from the firmware architecture, power management, and connectivity design decisions it sits alongside.

Common Production Security Mistakes

These are not theoretical vulnerabilities — they are patterns we still see in IoT products at or near release. They are worth naming directly because most of them are fixable early and expensive late.

Hardcoded credentials in firmware
API keys, MQTT passwords, cloud endpoint credentials, and Wi-Fi PSKs committed to firmware binary or to version control. Any shipped device exposes these; any version-controlled codebase exposes them to anyone with repo access. Credentials should be provisioned at manufacture, not compiled in.
Unsigned OTA
Already covered above — but worth repeating because it is the most common single gap. An OTA pipeline without signature verification is a remote arbitrary code execution primitive. It should be treated as a blocker for production deployment.
No rollback protection
Signed OTA without anti-rollback means an attacker in possession of a legitimately-signed older firmware image can downgrade the device to a version with known vulnerabilities. Monotonic version counters are the fix; they add trivial implementation overhead.
Default credentials shipped unchanged
Devices that ship with manufacturer-default usernames and passwords, or with first-boot passwords identical to the device serial number (trivially predictable), remain permanently exposed. Per-device unique provisioned credentials, or forced first-boot credential change, are the correct patterns.
TLS with certificate validation disabled
A frequently seen pattern: TLS is implemented and the connection is technically encrypted, but certificate validation is disabled or bypassed — meaning the device will connect to any server, including an attacker's. The code typically contains something like verify_peer = false or equivalent. This is a non-trivial misconfiguration to catch at review without explicitly checking for it, which is why it appears on the sign-off checklist.
Debug interfaces left open in production
JTAG, SWD, and UART debug consoles are invaluable during development. In production hardware shipped to end users, they are physical attack surfaces. JTAG and SWD should be disabled via RDP, eFuse burning, or equivalent hardware protection. UART debug output should be gated or removed. Leaving them open in production is a common omission, not a deliberate choice — which makes it a sign-off checklist item.
Keys and secrets in version control
Signing keys, private certificates, cloud provisioning credentials, and factory-test keys committed to source control — even internal repos — represent a persistent exposure risk. Leaked repo access at any point in the product lifetime exposes the material. Secrets belong in secrets management systems (hardware HSMs, cloud KMS, CI/CD secret stores), not in version control.
No key rotation plan
Products that have no mechanism for rotating device credentials at scale have no recovery path for credential compromise. Discovering that 50,000 deployed devices share a compromised symmetric key, with no way to rotate it without physical access, is an unrecoverable situation. Design key rotation as a supported operation from the beginning, even if you use it rarely.

Frequently Asked Questions

No — and blanket answers here are dangerous. Secure boot is worth the complexity for devices that handle sensitive data, operate in accessible physical environments, or run software that must not be tampered with (medical, industrial, safety-adjacent applications). For a sensor node in a locked server room whose firmware never changes, the overhead may exceed the threat. The right question is: what is the attacker's capability, what is the impact of a compromised device, and does secure boot address the most plausible threats? Map the threat model first, then decide.
Sign every firmware image with a private key held securely off-device. The bootloader or OTA client verifies the signature against the corresponding public key before accepting the image. Without a valid signature, the update is rejected. Additionally, enforce monotonic version counters so a valid but older (and potentially vulnerable) firmware image cannot be installed. For the OTA transport, use TLS — an attacker intercepting the connection should receive ciphertext they cannot modify without breaking the signature anyway, but transport encryption is still correct defence-in-depth. Our detailed OTA guide covers the full update pipeline.
For data in transit, TLS 1.2 at minimum — TLS 1.3 preferred for new designs (reduced handshake latency and improved cipher suite defaults). On constrained MCUs where TLS is too heavy, DTLS over UDP is an option. For BLE, use LE Secure Connections (LESC) rather than legacy pairing — LESC uses ECDH key exchange, which provides forward secrecy. For data at rest, AES-128 or AES-256 with keys stored in hardware-backed secure storage. The algorithm choice matters less than the key management: the best cipher is useless if the key is sitting in plaintext flash.
Depends on the threat model. If an attacker with physical access is plausible and the device holds sensitive key material, a hardware secure element (or the equivalent — TrustZone, ESP32 efuse-backed key storage, nRF KMU) meaningfully raises the bar for key extraction. If physical access is not a realistic threat, software key storage in a protected flash region may be sufficient. The BOM cost of a dedicated secure element (ATECC608, SE050, similar) is modest — typically a few dollars — but adds integration complexity. For high-assurance or tamper-evident applications it is worth it; for many consumer IoT designs it is not the first priority.
Secure boot ensures that only cryptographically signed firmware runs on the device — it protects the software execution chain from modification. Secure storage protects cryptographic key material (private keys, certificates, symmetric keys) at rest, preventing extraction even if an attacker reads the device's flash. They address different threats and both can be relevant simultaneously. Secure boot without secure storage means your firmware is tamper-resistant but an attacker who reads flash could still extract secrets. Secure storage without secure boot means keys are protected but an attacker could still replace the firmware with something malicious. Well-hardened devices implement both.
There is no universal interval — rotation policy depends on the key type and threat model. Session keys (TLS session keys, symmetric encryption keys for individual messages) are rotated per session or per message by the protocol. Long-lived device identity keys (the private key that identifies the device to the cloud) are harder to rotate because they require provisioning infrastructure. A practical baseline: plan for key rotation as a supported operation at design time, even if you do not rotate frequently in practice. The worst outcome is discovering a key compromise affecting a fleet of devices that have no key-rotation mechanism. Certificate expiry for mTLS deployments also forces rotation on a schedule.
At the specification stage — not at release time. Security decisions made early (hardware secure element vs. software key storage, OTA signing strategy, authentication model) are inexpensive to change at spec time and very expensive to change after hardware is locked or firmware is in production. The most common failure mode we see is security being treated as a release-gating checklist rather than a design input. By the time a security checklist surfaces an issue at release, the fix typically requires rearchitecting something that was set in concrete two engineering phases earlier. Start with a brief threat model: who attacks this device, how, and what do they gain? That drives the right answers on everything that follows.

Building or Shipping a Security-Critical IoT Product?

Security gaps in IoT are most expensive when found at release — or after. Our embedded engineering team works through threat models, firmware architecture, OTA pipelines, and production sign-off with security as a first-class input, not a last-minute checklist.

Talk to our IoT engineering team →

Get a Free Project Estimate