Practical Security Habits

Firmware Updates and Why They Matter

Why devices need patching, what can go wrong when you update, and how to plan for hardware that no longer receives security fixes from its maker.

On this page
  1. What firmware is
  2. Why devices need patching
  3. The risks of updating
  4. Automatic or manual
  5. Libraries count too
  6. Planning for unsupported hardware
  7. A short routine

What firmware is

Firmware is the software stored inside a device that makes it work: the code on a router, a camera, a smart plug or a microcontroller board. Unlike an app, it often runs with full control of the hardware and is rarely seen by the owner. Because it is software, it contains mistakes, and some of those mistakes can be used by attackers.

Why devices need patching

Researchers, manufacturers and sometimes attackers continually find flaws in code. When a flaw is found in a device or in a library it uses, the maker may release an update that corrects it. Once a fix is public, the flaw is also public knowledge, and automated tools can look for devices that have not been patched. That is why running old firmware tends to become riskier with time, even if the device has not changed.

Updates also fix ordinary bugs and sometimes add features or compatibility. For connected projects, the security reason is usually the strongest, since a device reachable from a network is a candidate for automated scanning. Making the change early is generally easier than recovering from a compromise, though no update can promise complete safety.

The risks of updating

Updating is not free of risk, and a careful maker plans for that.

  • Interrupted updates. If power fails or the connection drops while the new firmware is being written, a device may be left unusable. Some devices keep a second copy of the firmware so they can fall back, and some do not.
  • Changed behaviour. A new version may alter settings, remove a feature or break something your project depends on, such as a protocol or an integration.
  • Bad releases. Occasionally an update introduces a new problem. Reading release notes and waiting a short while for early reports can help, balanced against the urgency of a security fix.
  • Untrusted files. Firmware downloaded from an unofficial source could be modified. Use the manufacturer’s own channel and, where offered, check the published checksum or signature. Signed updates and secure boot work together to make sure the device only accepts firmware from its maker.

For anything important, take a note of the current version and settings before you begin, keep a copy of your configuration, and use stable power. Avoid starting a manual update on a battery that is nearly flat. Follow the manufacturer’s instructions for your specific model; steps differ between products, and this article cannot cover them.

Automatic or manual

Many consumer devices can update themselves. Automatic updates mean fixes arrive without you having to remember, which suits most people and most devices. The trade-off is less control over timing: a device may restart during a moment you would prefer it did not. For things like a heating controller or an alarm, you may prefer to schedule updates at a quiet time or approve them yourself.

For your own builds, the question is how a patched version reaches the device at all. A board that can only be updated by plugging in a cable is hard to maintain once it is fixed to a ceiling or sealed in project enclosures. Over-the-air update support is worth considering at design time, together with a safe way to roll back, and it must itself be secured, or it becomes an attack route.

Libraries count too

A maker’s own firmware usually includes code from others: a Wi-Fi stack, a web server library, an encryption component. Flaws in those can affect your project even if your own code is flawless. Keeping dependencies current and using version control to note which versions you built with make it easier to see what needs updating when a problem is announced. Re-building and re-flashing is a form of patching, and it only happens if you track it.

Planning for unsupported hardware

Every product eventually stops receiving updates. The maker may drop it, go out of business, or never have released patches at all. An unsupported device that stays online is a growing liability. A reasonable plan has a few steps:

  1. Find out the support status before buying. Look for a stated support period or a record of past updates, and treat missing information as a warning sign.
  2. Reduce exposure. Keep the device on a separate segment using network segmentation, remove any port forwarding and disable remote features it does not need.
  3. Limit what it can do. If it only needs to talk to one local controller, restrict it to that.
  4. Check for alternatives. Some devices can run community-maintained firmware, which can extend life. Check it is actively maintained and compatible with your exact model, and understand that flashing it can void warranties and carries a risk of failure.
  5. Replace it when the risks outweigh the value, and dispose of the old unit responsibly, wiping any stored credentials first.

A short routine

Keep a simple list of connected devices with their model and firmware version. Check it every few months, or when you hear about a flaw affecting a product you own. Prefer parts from makers with a record of updates, and treat update support as a feature when choosing hardware. This takes little time and removes one of the most common ways devices become easy targets.

The complete guide to practical security habits

A Maker Guide to Securing Connected Projects
Read the guide

Keep exploring

Guides from other topics

All topics →