With IoT devices typically being built with low profit margins and low power specifications, functionality is typically limited to that which is needed. But for a device that is expected to last a number of years, there will be security vulnerabilities and issues that need fixing (see the Mirai botnet as an example)

As an IoT manufacturer, how can I enable patching or upgrading of encryption algorithms or security protocols remotely, or simply ensure that the device is kept secure? What standards should I follow?

  • 2
    I fear the answer is most of the time 'using proprietary solutions'.
    – Helmar
    Commented Nov 5, 2017 at 11:47
  • While an interesting and relevant topic, this question cannot have the type of specific answer for which SE sites are reserved. It's also likely to quickly veer into the territory of opinion. Commented Nov 5, 2017 at 15:22
  • 1
    Thanks @Gilles - that brings the question properly on topic.
    – Rory Alsop
    Commented Nov 5, 2017 at 16:39

3 Answers 3


How do IoT manufacturers enable patching or upgrading of encryption algorithms or security protocols remotely or simply to ensure that the device is kept secure?

A large number of IoT manufacturers have a simple solution to this: "don't bother". These tend to be the same developers who add default (or even unchangeable) passwords to their devices, which led to Mirai in the first place.

As mentioned in Rory's answer, there are sizeable costs to providing both the mechanisms and the actual development time to design and deploy the fixes. I strongly suspect that without regulatory pressure (or consumer demand, which doesn't seem to be the case), there will be no incentive for a manufacturer to raise their product's prices for added security. Australia seems to be taking this step by considering a mandatory security rating system for all IoT devices.

I think that for most manufacturers, the best idea is to get someone else to handle security. Just as most web developers use established frameworks like Django and Ruby on Rails to avoid making the same mistakes over and over, IoT developers should do the same. There are several options, depending on the complexity of your device:

  • Higher-end devices could use operating systems like Ubuntu IoT or Windows 10 IoT Core where security updates are done by the OS developer and pushed automatically. Much of this isn't IoT-specific, but it is far preferable to each IoT device using a custom, in-house operating system that is unlikely to receive any maintenance.

  • Low-end devices such as ESP8266 modules are perhaps more limited, as they aren't able to run such complex operating systems and tend to run code developed specifically for that device. There are still options such as Mongoose OS which offer over-the-air firmware updates

IoT manufacturers generally should take advantage of existing solutions where available. Web developers don't usually recreate a web framework for each new website, so why should IoT be substantially different? Rory's answer offers an excellent list of features that should be implemented by a good operating system for the IoT, and just using an "IoT OS" won't fix all your problems. As this Windows IoT guide explains, one must take steps to ensure the hardware and firmware are secured as well as the OS itself. The ideas in Rory's answer are pretty comprehensive in this regard.

Here are some examples from the operating systems I suggested about what systems they use to upgrade security:


Moran posted this IETF draft titled A Firmware Update Architecture for Internet of Things Devices on the 30th of October 2017.

A key summary outlined over at Bleeping computer is

  • The update mechanism must work the same even if the firmware binary is delivered via Bluetooth, WiFi, UART, USB, or other mediums.
  • The update mechanism must work in a broadcast type of delivery, allowing updates to reach multiple users at once.
  • End-to-end security (public key cryptography) must be used to verify and validate firmware images.
  • Rollback attacks must be prevented.
  • All information necessary for a device to make a decision about the installation of an update must fit into the available RAM of a constrained IoT device. This prevents flash write exhaustion.
  • A power failure at any time during the update process must not cause a failure of the device.
  • The firmware update mechanism must not require changes to existing firmware file formats.
  • The new firmware update mechanism must be able to operate with a small bootloader, specific to most IoT devices.
  • The update mechanism must account for multiple permissions. For example, a firmware update for critical infrastructure equipment will have to be signed by both the firmware author and the equipment's owner/operator.
  • The new IoT firmware update architecture must support manifest files.

This is very much a draft, as this is a new area. My expectation is that it will be driven more by regulation than by consumer demand, as consumers really don't care about updates or security unless they directly impact them. Any improvements in this area will impact the cost of devices.


If the firmware of your device can be made less complex than the bootloader required for a secured remote update, then do not implement remote update.

I know the consensus is to have a secured and robust bootloader, with strong public crypto authentication, safe rollover mechanisms, maybe a basic network stack, and then put on top of that a RTOS, with a full IP+TLS network stack, then add on top of that your application. This is pure insanity for a low-cost low-power device. IMHO, this leads to products that are updated every week or so, which tend to bother users because sometimes updates start at the wrong moment, fail or break something. Updates drain a lot of power too, so user have to charge more often. And security is still far from guaranteed as the attack surface is large.

Your device is doing basic sensing/actuating, maybe some local triggering/displaying but not much? Skip all that.

Write bare metal code, use a very basic stack, audit it thoroughly, do some formal verification if possible. And then you can be relatively confident that your device will not have security issues for the next decade.

If all you have is a hammer, everything looks like a nail. And that's why most coder try to write code to secure their unsecured existing code. Writing less code doesn't always come naturally.

  • Sadly that is a fallacious view, if you look at all the evidence. You cannot rely on security for any length of time. And what makes you think decades will be enough? And even when you are relying on something like SSL for comms, and you think it is secure, you find flaws that have been in for years. You need a strong comms stack (like BearSSL for small embedded platforms) which should be fine, but it will still need to be updateable. So, the question asked about standards for this - a post stating that it isn't necessary is just not an answer.
    – Rory Alsop
    Commented Nov 18, 2017 at 22:30
  • 2
    This is a moderately valid view if you're using a limited, flash-based MCU with at most an RTOS, and are confident you won't have any need to add functionality or fix functional bugs after shipping. But once you start using a full-fledged operating system the attack surface is just too large to assume that there won't be issues found that you were unaware of at the time of shipping. Commented Nov 19, 2017 at 3:57
  • 2
    Another necessary condition for not needing code update is: if your device doesn't ever listen to packets from the Internet, including replies to its own packets. In other words, if your device doesn't have an Internet connection. As soon as you connect to a network, you need to update against network attacks that will be discovered. Commented Nov 19, 2017 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.