Securing the IoT from Hardware to Application: A Layer‑by‑Layer Blueprint

By Wouter van der Beek

In today’s connected world, IoT security is no longer optional—it is a regulatory mandate. Recent legislation requires devices to embed “reasonable security features,” underscoring that the cost of securing a device far outweighs the risk of leaving it exposed.

Security is architected in layers. The foundation starts with the hardware, followed by the network, and finally the application. This article focuses on the Thread network layer—a low‑cost, low‑energy, mesh‑based IP network—and the OCF application layer that governs device interactions.

Hardware Security

Constrained microcontrollers must guard against malicious firmware and hardware snooping. Secure hardware enforces a verified boot sequence, signs the firmware, and isolates memory and peripheral access. Only a trusted, well‑defined API can reach critical code, thereby minimizing the attack surface and creating a robust base for higher‑layer security.

Network Security

Thread protects data in flight with a network‑wide AES‑CCM key. Each packet receives an authentication tag and is encrypted, ensuring integrity, confidentiality, and authenticity. The key is periodically refreshed using a counter‑based derivation to prevent compromise.

When a new device joins, it must acquire the network key securely—a process known as commissioning. Thread uses Password‑Authenticated Key Exchange (PAKE), part of DTLS, to transform a low‑strength shared secret into a strong key. This allows the Thread commissioner (e.g., a smartphone) to transmit the network key to the joining device over an encrypted channel.

Application Security

At the application level, the Open Connectivity Foundation (OCF) offers a comprehensive ownership transfer and device provisioning flow. OCF issues device certificates and maintains a secure database, enabling mutual authentication via a PKI infrastructure.

Provisioning instructions are delivered over DTLS‑encrypted channels. The workflow begins with ownership transfer, proceeds through state transitions, and accommodates changes in ownership by requiring a hardware reset to return to the initial state.

OCF also provides role‑based access control and manufacturer usage descriptors, adding extra safeguards against network‑level threats.

Implementing OCF‑over‑Thread on Constrained Hardware

Deploying OCF over Thread on low‑cost microcontrollers is challenging due to limited code space, memory, and CPU resources. The solution lies in code reuse—sharing a single cryptographic core (mbedTLS) across both stacks, as both OCF and Thread rely on DTLS.

Cryptographic primitives benefit from hardware acceleration, dramatically reducing commissioning time and power consumption. Managing access to this hardware via mbedTLS is critical for performance and security.

Both OCF and Thread groups publish open‑source implementations, eliminating ambiguity and ensuring interoperability for developers.

When the application, network, and hardware layers are tightly integrated, the result is a best‑in‑class secure IoT platform ready for deployment today.

Authors: Wouter van der Beek, senior IoT architect, Cisco Systems and Technical Working Group chair, Open Connectivity Foundation; Bruno Johnson, CEO, Cascoda, member of the Open Connectivity Foundation.