When to Add Security to Your IoT Devices (and How It Changes by Architecture)

In the rapidly evolving landscape of the Internet of Things, security, unfortunately, often feels like an afterthought. Or, sometimes, it gets completely overlooked. But with the ever-growing threats we're facing plus stricter regulations coming down the pipeline — like the EU's Cyber Resilience Act — and the fact that devices are sticking around longer these days, this kind of reactive approach is no longer viable.

So, the question is: when is the right time to bake security into your IoT devices? And, does the answer change depending on whether you’re working with, say, a Linux-based edge gateway or a bare-metal microcontroller? Let’s get into it in this week's article.

The best time to integrate security?

The very beginning. It’s a simple truth: security is at its most effective and, frankly, least expensive when it’s woven into the product from the initial stages.

During the design phase for example threat modeling can help identify the critical assets that need protection – your firmware, your encryption keys and your user data, for instance. Architectural decisions can also play a crucial role in establishing long-term security. Think about features like secure boot paths and hardware-based cryptography. Plus, you can design the device to be updatable, a vital requirement these days both from a regulatory and operational perspective.

Then there’s development. Secure coding practices can help to prevent entire categories of vulnerabilities from even existing in the first place. You can implement and test things like secure boot and attestation alongside the core functionalities. Integrating with a secure element or a TPM is going to be a whole lot easier during this phase rather than trying to bolt it on later after the product is released.

And finally, during deployment. Some security measures like the generation and deployment of encryption keys or the assignment of unique device identities, have to happen in a secure environment during manufacturing. Also your over-the-air (OTA) infrastructure and any rollback mechanisms should be set up before a device even leaves the factory floor

But even if you didn't implement security from the start, don't despair! All is not lost. However retrofitting security always comes with increased risks and complexity. You will need a secure update mechanism to patch any vulnerabilities and you may need to add support for key rotation or secure storage depending on what your hardware can actually handle.

Security strategies: Linux vs. RTOS/bare-metal

The approach and the challenges that come with it shift quite a bit depending on what kind of device you are working with.

Let’s consider Linux-based devices, including gateways, smart cameras and industrial PCs. The good news is, you have a rich OS environment, so there are mature security tools at your disposal – things like TPM support, secure boot loaders and even SELinux. It’s also generally easier to run software agents that can handle updates monitor the device and manage your credentials. However you're also looking at a larger attack surface, due to the open ports and complex software stacks. It can be tougher to be absolutely sure that you are in a known-good state. Package managers and kernel modules can introduce untrusted code, especially if you don’t control them meticulously.

Now let's switch gears to microcontroller-based devices, such as those running RTOS or bare-metal. The plus side here is that you have a smaller attack surface. Behavior is generally more predictable. The downsides? Well you won't have any OS-level protections like MMUs, process isolation, or filesystem encryption. Memory and power constraints often limit the complexity of cryptographic operations. And, it is a lot more challenging to add update mechanisms after the device is in the field.

Recommended security layers:

• Hardware-based secure boot preferably using a secure element.
• Unique device identity and protected key storage.
• Lightweight OTA with rollback support.
• Static analysis and control-flow protection to mitigate firmware bugs.

⚠️ The risk of delaying

Putting off security decisions until after a product's been designed, or even deployed, often leads to:

• Higher costs; patching issues is always more expensive than building it correctly from the beginning.
• Delays in achieving regulatory compliance.
• Potential hardware recalls or failures in the field.
• Damage to trust and your brand reputation.

🛡️ How a platform like Thistle helps

Security doesn’t have to be a major hurdle. With solutions like Thistle’s platform, developers can, essentially, build security in without having to start from scratch.

• Add secure boot and verified updates without needing custom firmware.* Easily integrate secure elements (like Optiga Trust).
• Support both Linux and RTOS-based devices with a single solution.
• Comply with those ever-evolving regulations (like the CRA) quickly and efficiently.

Whether you're securing a connected light bulb or a smart factory controller, putting security in from the get-go – and aligning it with your device’s architecture – is how you build trustworthy IoT.