7 Tips for Securing an Embedded System

Security, just like quality and many other embedded system attributes must be considered at the start of the development cycle. Developers can’t build their system and then add security at the end. With more and more systems starting to connect to the internet, there are more than a dozen best practices that developers should follow to start securing their systems. In this post, let’s explore several that any team can implement.

Tip #1 – Start using ARM TrustZone

ARM TrustZone has been available on application processors for quite some time and it has been announced that ARM TrustZone will be available on new microcontrollers coming soon. While we may not be able to use TrustZone right now in a microcontroller environment, developers should be starting to explore its implications and how it can be used to write more secure software. If you have an ARM application processor, now is the time to start putting TrustZone to work.

Tip #2 – Follow language and industry best practices

There are several programming language and industry best practices standards that embedded software developers should be using. Using MISRA-C/C++ can ensure that best practices are followed that use a subset of the chosen language. MISRA should be used regardless but from a security standpoint and if developers are using C, then becoming familiar with and following the best practices in Cert-C is highly recommended. Cert-C is designed to provide recommended coding practices that prevent security vulnerabilities in software.

Tip #3 – Digitally sign and encrypt firmware updates

Any device that is connected to the internet is going to need feature updates and bug fixes pushed to it. In order to prevent unauthorized firmware updates, developers should consider digitally signing and encrypting their firmware images. Many systems that I encounter simply accept any new software it encounters. Developers should make sure that images are authenticated before ever touching them.

Tip #4 – Validate the application at start-up

Would be hackers may try to inject new software onto the system during start-up. It’s always a good idea to use the bootloader to validate that the current image stored in ROM and the code running in RAM is what should be there. There are many ways to do this but a very simple check would be to place a CRC that is validated on start-up. It’s better than nothing!

Tip #5 – Monitor stack and buffer for overflow

Overflowing the stack or a buffer can be a great way to start injecting malicious code into a system. Developers should monitor their buffers and stack space to ensure that they are not able to overflow. This can be done manually by monitoring the position pointer or creating guard zones that warn of an impending overflow. Most RTOSes also include a stack overflow monitor. Make sure that it is not only turned on but that there is code to handle the system when this state occurs.

Tip #6 – Lock Flash Space

It certainly is not tamper proof but one extra hurdle to throw in front of a hacker is to lock the flash program space. Locking the flash at end-of-line will help prevent someone who has physical access to the device from being able to read out the application code and reverse engineer it. With enough time, they could find a way but the point is that they will have to work harder to get access to the code and that may be enough to discourage them.

Tip #7 – Hire a security expert

I’m not a security expert (disclaimer), but I will advocate using a security expert to help put a security strategy in place for a device or product. Systems have become so complicated that it is impossible for any single person to be an expert in anything and if we want to build robust, secure systems, developers need to leverage each other strengths. For small businesses, having a security on payroll probably doesn’t make sense but using a consultant or outside company to provide direction when it is required is a great step towards having a secure system.


While most developers, managers and companies want to ignore security, it is perhaps one of the greatest challenges embedded system developers will face. Let’s be honest. No one wants to have to pay for or believes that they need to worry about security. We believe that we couldn’t possibly be targeted. I once accidentally put an unprotected Linux machine beyond my firewall so that I could have access to it over the weekend. Out of the billions of machines connected to the internet, what would be the odds that this machine would be discovered in a few days? Within 24 hours it had been hijacked by some really cool Chinese malware. How long do you think your embedded system will last?

4 thoughts on “7 Tips for Securing an Embedded System”

  1. Tip#1 will be valid if ARM delivers on it’s promise to make TrustZone for micro-controllers as advertised, the rendition of TrustZone on the 32-bit microprocessors is somewhat cumbersome, people usually pick and choose bits which make sense, a full-blown implementation requires a substantial software component which is not trivial and has to be securely done, it is also likely to impact adversely the Real-Time, if such is required.

    I can only agree with Tip#7. If not hiring a security expert, then better conduct a proper security requirements assessment, if you know how to do it, if not: back to the Tip#7!
    Do not assume that what you hear from the client is what they really want and/or need, everybody think they know what “security” is when it comes to computing system, but in practice majority of people have their notions greatly confused.

    1. Thanks for the comment. TrustZone will appear in time. It’s not so much a matter of arm making them but their licensees actually producing the parts. arm only creates the IP it’s up to the vendors such as Nuvoton, Texas Instruments, Renesas and so forth to produce the parts. I definitely agree that most embedded developers don’t really understand what is needed for security.

  2. Hi Jacob,

    Great Article! (As Always)

    Going by the grammar of Tip #6, did you mean to say “It certainly is *not* tamper proof”.

Leave a Reply

Your email address will not be published. Required fields are marked *