Design for IoT Security From the Start

Girl up late on a macbook

Security has been a hot topic for IoT devices. It gets the spotlight not only due to the ease of some of the exploits but the ubiquity of their use in all aspects of life. However, according to a 2018 survey by the Barr Group, 33% of respondents said they didn’t have any security requirements for their products. To avoid your product becoming the next big news story, you need to design with security in mind at all stages of product development. Thinking of it as a component you can bolt-on is a recipe for failure. You should also accept that no security is scheme is perfect, so a device that has taken security precautions at every layer is better than a big effort to make one measure perfectly impenetrable.

33% of respondents said they didn’t have any security requirements for their products

Today I’ll cover broad categories you need to consider when you build a device with security in mind:

  1. Authenticity
  2. The code it’s running
  3. The data on it


How do you know a device is one of yours vs an imposter? Through the process called provisioning. The biggest hacks have been companies putting default usernames and passwords on their devices or the same certificate for every device. With proper provisioning, each device has a unique certificate or key and is checked by a secured server or client before that device is allowed to communicate back to that gateway, either the first time it is turned on, or every time it connects, depending on the product. For a more in-depth discussion of how to do provisioning, see this article from DigiKey.

The biggest challenge with provisioning is finding a way to do it that balances security with end-user experience, especially when the end-user is a company with hundreds or thousands of devices. By coupling provisioning with end-user secure sign-in, you can better verify that devices are getting registered by the people you intended. Many consumer products have customers set up their device and then register it on the manufacturer’s website upon initial start-up using their phone and a BLE connection. But scale that to a business that may have hundreds or thousands of devices, and that becomes unwieldy. Processes such as just in time registration can make that process easier at scale. You also have to start thinking about how provisioning certificates will be managed not only on active devices, but those that are out of commission, removed for repair, or possibly have become compromised. A robust certificate management plan will take all of these conditions into consideration, as shown by this article by Nexus Group.

The code

Preventing security breaches is only half of the battle. The other is detecting them when they occur because no matter how thorough you are with your security, new exploits are being discovered every day. Engineers can put software tripwires in place that can alert, reset, or turn off the device when something that might have security implications happens so that compromised devices can be dealt with safely. In larger IoT systems, honeypots may also be employed to monitor and detect security threats to the overall system. Honeypots are devices that look real enough to outsiders but aren’t intended to have real traffic on them, so any activity on them will be a tip-off to unauthorized access.

Until recently, the code that was on the device when it was manufactured was the same code that would be on the device when it was thrown in the dumpster. Now many manufacturers and 3rd party vendors support over the air updates (OTA). So now you can update the devices you have already deployed as vulnerabilities are discovered.

The data

When it comes to security measures for IoT devices, encryption usually gets all the headlines.

You should consider what information might be compromised and what risk that entails if you don’t encrypt customer data. However, that should be balanced with the needs of real-time and low-power performance considerations. For real-time, low-power, or low-memory applications, there may not be resources for encrypting anything but the most sensitive data. A properly done security analysis will determine where to spend extra on better processors vs. reducing the risk of exposed data.

Even if your devices aren’t fully “internet things”, you may still need to secure data on the device. If the data is important enough, someone may attempt to intercept data between the microprocessor, its peripherals, and separate modules. If billed as a big enough risk, the engineer may also decide to encrypt this data, understanding that it also comes with similar performance and power trade-offs as encrypting transmitted data.

These aren’t the only aspects of IoT security. The IoT Security Foundation is a good source of reliable security information and practices for connected embedded devices.

Or if you’d like to make sure your IoT product is secure, reach out! At DojoFive, we have talented engineers on hand ready to help you with all aspects of your IoT journey. We are always happy to help with interesting problems that need solving, from security audits to firmware development. You can reach out at any time on LinkedIn or through email!

Leave a Reply