In March 2025, security researchers disclosed CVE-2025-2189, a vulnerability in Tinxy smart devices: the firmware stored security credentials in plaintext, and an attacker with physical access could extract them by analyzing the binary. This is not an unusual finding. It is closer to a baseline expectation. Across consumer IoT, when researchers extract a firmware image and run binwalk, they find hardcoded keys, unencrypted secrets, and reused certificates more often than they don’t.
The gap between marketing-page encryption claims and what actually ships in firmware is the subject of this article. Most IoT devices technically support encryption — they negotiate TLS, their cloud APIs use HTTPS, their datasheets list AES-128. But encryption on a connected device is only as strong as the key management beneath it, and the key management is where consumer-grade IoT routinely fails. With the EU Cyber Resilience Act’s main obligations taking effect December 11, 2027, that gap is becoming a regulatory liability rather than a quiet engineering shortcut.
Why IoT Encryption Looks Strong on Paper and Weak in Firmware
The cryptographic primitives in modern IoT are not the problem. AES, ChaCha20, TLS 1.3, ECDSA with P-256, and SHA-256 are all readily available on chips that cost under a dollar. The problem is everything around them: where the keys live, how they got there, and what happens when an attacker reads the flash directly.
A representative pattern from disclosed vulnerabilities: a smart bulb advertises “AES-128 encryption” in its specifications. The firmware does, in fact, use AES-128. But the AES key is the same on every unit shipped from the factory, baked into the firmware image. CVE-2019-17098 affected the August Connect WiFi bridge, where the app and the firmware used a hardcoded cryptographic key for communication, allowing an attacker to decrypt an intercepted payload containing the WiFi network authentication credentials. The cryptography is sound. The deployment makes it irrelevant.
This pattern repeats because the alternatives — per-device keys, hardware-backed key storage, secure provisioning at manufacturing — add cost, manufacturing complexity, and engineering time that consumer IoT margins do not absorb easily. When performing security research on IoT devices, hardcoded credentials, static encryption keys, unencrypted communications, outdated software components, and insufficient hardware security are common findings. The OWASP IoT Top 10 has ranked weak, guessable, or hardcoded passwords as the number-one IoT risk for years, and the 2025 update did not change that ordering.
The economic asymmetry is the deeper issue. A serious key-management architecture — secure element, per-device keys provisioned at manufacturing, OTA-signed firmware with rollback protection — costs the manufacturer dollars per unit and weeks of engineering. The cost of shipping without it is borne by users and the broader internet, which inherits the botnet.
What Encryption Actually Has to Cover
A useful frame for IoT encryption is the four asset types that need protection and the distinct cryptographic problem each presents. They fail independently. A device can do one well and the other three badly.
Data in transit. The session between device and cloud, or device and local hub. The standard answer is TLS 1.2 or 1.3 over TCP, or DTLS 1.2/1.3 for UDP-based protocols like CoAP. This is the part most devices get approximately right, because TLS libraries — mbedTLS, wolfSSL, BearSSL — are mature and fit on Cortex-M-class hardware. The recurring failure is certificate validation: devices that ship with verify_peer = false to avoid handling certificate rotation, devices that pin a certificate that expires three years in, devices that fall back to plaintext on TLS handshake failure rather than refusing to connect.
Data at rest on the device. Configuration, credentials cached for offline operation, telemetry buffered before upload. The problem here is where to put the encryption key. If the key is in the same flash as the data, an attacker who can read flash can decrypt. The honest answer requires hardware: a secure element like Microchip’s ATECC608, NXP’s EdgeLock, or an integrated secure subsystem on the SoC.
Firmware integrity and updates. The signing key for OTA updates is the most consequential key on a fleet. A leak compromises every device, present and future. Anti-rollback protection, where the device refuses firmware versions older than its current one, is independently important — without it, attackers downgrade devices to known-vulnerable versions and exploit those.
Device identity. The cryptographic credential a device uses to prove it is itself, not a clone. This underpins everything else: zero-trust network access, mutual TLS to the cloud, attestation. If device identity is a shared secret, the whole architecture collapses on the first firmware extraction.
Where Keys Should Actually Live
The architectural answer the industry has converged on is a hardware root of trust (HRoT): a small, isolated, hardware-enforced zone that stores keys and performs sensitive cryptographic operations. The keys never leave that zone. Application firmware can request “sign this” or “decrypt this” but cannot read the key itself.
On Arm Cortex-A application processors — the kind in smart speakers, set-top boxes, gateways — the dominant pattern is TrustZone, which splits the processor into “secure world” and “non-secure world” with hardware enforcement. The concept of secure and non-secure worlds extends beyond the processor to encompass memory, software, bus transactions, interrupts, and peripherals within an SoC, with non-secure software blocked from accessing secure resources directly. The secure world runs a small TEE OS (commonly OP-TEE), and cryptographic services run inside it.
On Arm Cortex-M microcontrollers — the constrained devices in sensors, locks, bulbs — the equivalent is TrustZone for Armv8-M, available on Cortex-M23, Cortex-M33, and Cortex-M55 cores. The reference firmware is Trusted Firmware-M (TF-M), which implements the Platform Security Architecture (PSA) Certified specification. TF-M provides the PSA Crypto API, secure storage, and an initial attestation service running in the secure world; the application runs in the non-secure world and calls in.
For SoCs without TrustZone, the alternative is a discrete secure element on the I²C or SPI bus: Microchip’s ATECC608A/B, NXP’s SE050, Infineon’s OPTIGA Trust M. These are small chips ($0.50–$2.00) that hold ECC keys, perform ECDSA and ECDH, and physically resist key extraction.
The PSA Certified scheme provides a graded certification framework — Level 1, 2, and 3 — with increasing assurance. Level 1 is documentation review. Level 2 adds a 25-day lab evaluation against software attacks. Level 3 adds resistance to physical attacks. Most consumer IoT today, when certified at all, is Level 1.
What the Current Failure Modes Look Like
The CVE record reads as a catalog of the same handful of mistakes repeated across vendors. CVE-2024-9991 in Philips lighting devices allowed attackers with physical access to extract WiFi credentials by analyzing binary firmware. CVE-2023-50129 affected the Flient Smart Door Lock v1.0, where unencrypted NFC tags allowed cloning by brief physical proximity. None of these are exotic attacks. They are firmware extraction with binwalk and strings, NFC sniffing with off-the-shelf hardware, or running openssl s_client against a misconfigured TLS endpoint.
A separate failure category is using the right primitive incorrectly. Devices that derive AES keys from MAC addresses, IVs reused across messages, ECB mode chosen because “the spec said AES,” random number generators seeded from boot time. Even when encryption is used, it doesn’t guarantee security if it’s poorly implemented — IoT devices often suffer from weak cryptographic practices, such as failing to properly validate certificates or relying on outdated algorithms.
OTA Updates: The Highest-Stakes Cryptographic Surface
Of all the cryptography on an IoT device, the firmware update path matters most because compromise scales. A signing key leak doesn’t expose one device — it exposes every device that trusts that key, often for the product’s entire lifecycle.
The minimum architecture: a private signing key held in an HSM (not on a developer laptop), public verification key burned into device ROM or one-time-programmable fuses at manufacturing, every update signed with the private key, every device verifies before flashing. The signature scheme is typically ECDSA P-256 or Ed25519 — both fit comfortably on Cortex-M, both produce 64-byte signatures, both are well-supported in TF-M and mbedTLS.
Above that minimum, several controls compound: anti-rollback via a monotonic counter that the bootloader checks; per-device encryption of the update payload (so the firmware binary itself isn’t trivially extractable from network captures); dual-bank A/B updates so a failed flash leaves a working image; secure boot that verifies the bootloader itself before it runs, anchored in an immutable ROM stage.
The category of catastrophic failure here is signing-key compromise. The best mitigation is operational: keys live only in HSMs, signing requires multiple-person authorization, every signing operation is logged, and the device firmware supports key rotation so a leaked key can be retired. Most consumer IoT devices today support none of those. A signing-key leak means every device shipped is permanently exposed.
What the EU Cyber Resilience Act Changes
The regulatory frame is shifting decisively. The EU Cyber Resilience Act entered into force on 10 December 2024. The main obligations apply from 11 December 2027, with reporting obligations applying as of 11 September 2026. The CRA, formally Regulation (EU) 2024/2847, applies to virtually every connected product placed on the EU market.
The encryption-relevant requirements, drawn from Annex I, are direct. Products must protect the confidentiality of stored, transmitted or otherwise processed data by encrypting relevant data at rest or in transit by state of the art mechanisms, and protect the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against any manipulation or modification not authorised by the user. Manufacturers must provide security updates for the product’s expected lifecycle, ship with secure-by-default configurations, and document the cryptographic mechanisms used.
The teeth: actively exploited vulnerabilities require notification within 24 hours, products with digital elements that don’t comply cannot be sold in the EU after December 11, 2027, and substantial modifications to existing products after that date pull them into full CRA scope. This is enforced by CE marking, not voluntary attestation — the same mechanism that already gates electrical safety and EMC compliance on every device sold in Europe.
The U.S. equivalent is more fragmented: the FCC’s voluntary Cyber Trust Mark program for consumer IoT, which began accepting applications in 2025 and aligns with NIST’s IoT cybersecurity baseline (NISTIR 8259A). It is a label, not a ban. Devices without it can still ship.
FAQ
Is TLS 1.3 enough for IoT data in transit? For the session itself, yes — TLS 1.3 with a modern cipher suite (AES-GCM or ChaCha20-Poly1305) and proper certificate validation is sound. The failures are almost always around it: certificate validation skipped, certificates pinned that later expire, fallback to unencrypted on handshake failure. TLS is the easy part.
Do I really need a hardware secure element on a $5 sensor? For a sensor whose only secret is a cloud API token shared with thousands of identical units — probably not, but recognize that the device offers no meaningful authentication and must be treated as untrusted by the network it connects to. For any device with a unique cryptographic identity, the answer is yes; without hardware-backed key storage, the per-device key is recoverable in minutes.
What about post-quantum cryptography on IoT? ML-KEM-768 and ML-DSA-65 fit on Cortex-M-class hardware in terms of CPU, but the key and signature sizes — ML-KEM-768 public keys are 1,184 bytes, ML-DSA-65 signatures are around 3,300 bytes — strain flash and RAM budgets on cheap MCUs. Most IoT will not migrate to PQC until the next hardware generation. Long-lived devices (industrial, medical, automotive) need a PQC plan now; consumer devices have time.
How do I audit a third-party device for these problems? Extract firmware via the OTA update mechanism or hardware (UART/JTAG if exposed, chip-off if not). Run binwalk and strings for hardcoded secrets. Inspect the bootloader for signature verification. Test the OTA path with modified images. Capture network traffic and check for missing TLS or weak cipher suites. The same techniques researchers use to file CVEs.
The Honest Assessment
The hardware to do IoT encryption properly has been commodity for a decade. PSA Certified, TrustZone-M, sub-dollar secure elements, mature TLS stacks, signed-update reference implementations — none of this is research. The reason consumer IoT firmware keeps failing the same ways is that the cost of failure has, until now, fallen on someone other than the manufacturer.
The CRA changes that calculation in Europe by December 2027. Manufacturers selling into the EU have roughly 18 months to convert “we use AES-128” marketing claims into auditable architectures with per-device keys, hardware-backed storage, signed and verified updates, and documented cryptographic agility. The companies that take that seriously will end up with better products. The ones that don’t will discover that CE marking has acquired a security dimension, and that telling customs the firmware ships with a hardcoded key is no longer a viable strategy.
For practitioners reading this: the practical short list is unchanged from what it was five years ago. Per-device keys provisioned in a secure element. Signed firmware with anti-rollback. TLS with real certificate validation and no plaintext fallback. Disabled debug interfaces in production. Documented OTA path. None of it is novel. All of it works. The reality check is that most devices still don’t do it.
