A device you cannot update safely is a device you cannot fix.
Security and update paths for connected products: secure boot, signed firmware, key management, resilient over-the-air updates and the provisioning that makes them possible.
Two problems that are really one
Every deployed device will eventually need new firmware, to fix a defect, close a vulnerability or add what a customer now requires. If updating means sending an engineer to each unit, the true cost of any change becomes prohibitive and problems go unfixed.
But an update channel is also the most direct route into your product. An update mechanism without authentication is a way for somebody else to install their firmware on your fleet. The two problems have to be solved together, and both are architectural decisions that are painful to retrofit.
What a workable update path requires
- Enough storage. Space for a second image, or a scheme that tolerates interruption, decided when the memory map is designed.
- Atomic switchover. Power loss mid-update must not leave a device that will not boot, which is the failure that turns an update into a site visit.
- Automatic rollback. If new firmware fails to run correctly, the device returns to the previous version by itself.
- Signature verification. The device installs only firmware signed by a key you control, checked before the image is trusted.
- Version reporting. Knowing what each device is actually running, which becomes essential the moment a fleet is not uniform.
- Staged rollout. Updating a small group first, so a bad release reaches a handful of devices rather than all of them.
Security beyond the update channel
- Secure boot. A chain of trust from a root the device cannot be talked out of.
- Device identity. A unique credential per device, provisioned during manufacture, so devices authenticate individually rather than sharing one secret that leaks once.
- Key management. Where signing keys live, who can use them, and what happens if one is compromised. This is a process question as much as a technical one.
- Transport security. Authenticated, encrypted communication with certificate validation actually enabled.
- Debug interfaces. Deciding what happens to JTAG and serial consoles in production units.
- Data at rest. What the device stores and what an attacker holding one would obtain from it.
How we help
- Threat assessment. Proportionate to your product. A sensor reporting temperature and a device controlling machinery do not warrant the same measures.
- Architecture. Memory layout, bootloader design, secure boot and the update scheme, decided early enough to be implementable.
- Bootloader and update implementation. Including interruption and rollback behaviour, tested by deliberately interrupting updates.
- Provisioning. Getting unique credentials into devices during manufacture without exposing them in the factory.
- Backend. The update service, version tracking and staged rollout control.
- Key management process. Practical custody and revocation arrangements your team can actually follow.
What we do not claim
We implement recognised practice and test what we build. We are not a certification body, and we do not issue security certifications or assurance statements. Where your market or customers require formal security certification or independent penetration testing, that is specialist accredited work and should be planned as a separate activity. We can design with those requirements in view if you raise them at scoping.
What you receive
The bootloader and update implementation, provisioning tooling, backend update service, documentation of the security design and the key management process, and evidence from interruption and rollback testing.
Related
Embedded firmware development, IoT development, industrial product development.
How do you update devices today?
Tell us what the product is, how many are deployed or planned, and whether updating currently requires physical access.
What clients ask before starting
What happens if power fails during an update?
A correctly designed update survives it. That requires either space for a second image or an interruption-tolerant scheme, atomic switchover, and automatic rollback if the new firmware does not run correctly. We test this by deliberately interrupting updates.
Can over-the-air updates be added to an existing product?
Sometimes. It depends on available memory, the existing bootloader and whether the hardware can support a second image. Where it cannot, adding it means a hardware change, which is why the decision belongs early in a design.
Do you provide security certification?
No. We implement recognised practice and test what we build, but we are not a certification body and we do not issue assurance statements. Formal certification and independent penetration testing are accredited activities and should be planned separately.