Secure OTA Updates:
How We Keep Every Device Current
An inside look at how Simplinx delivers encrypted firmware updates over-the-air, uses a dual-boot partition for safe rollback, and ensures every device in the field is always running the latest firmware — without any user action.
In traditional OT environments, firmware updates are something system integrators dread. They involve scheduling downtime, travelling to site, manually connecting to each device, and hoping the update goes cleanly. If it doesn't, recovery can mean hours of troubleshooting on a production floor where every minute counts.
We built the Simplinx update system to eliminate all of that. Every device in the field receives updates automatically, securely, and without interrupting production. Here's how it works.
Encrypted Delivery from the Update Server
When a new firmware version is published, it is signed and encrypted on our update server before it ever reaches a device. The device authenticates the package against a built-in public key before the update process begins — an unsigned or tampered package is rejected outright.
The download channel itself uses TLS. This means the firmware in transit is protected at two layers: the transport layer prevents interception, and the signature verification prevents any modified binary from being installed even if the transport were compromised.
The Device Stays Running During the Download
The update is downloaded and written to a separate partition while the device continues to operate normally. Remote connections remain active. Data collection keeps running. The firewall keeps enforcing rules. None of this is interrupted by the update download.
Only the final step — the switchover — requires a reboot. And that reboot is the same 30-second restart that would occur after a power cycle. On a factory floor, that's a known, manageable event, not an emergency.
Dual Boot: The Safety Net
Every Simplinx device has two firmware partitions — let's call them Slot A and Slot B. At any point, one slot holds the currently running firmware and the other holds the incoming update (or the previous version).
When the download completes, the device writes the new firmware to the inactive slot. On reboot, the bootloader switches to the new slot and starts the system. The old slot is left intact and untouched.
This is a well-established pattern in embedded systems — used in aerospace, automotive, and medical devices — precisely because it makes the update fully atomic: either the new firmware runs cleanly, or the device boots back from the known-good slot without any manual intervention.
Verify, Confirm, or Roll Back
After booting into the new firmware, the device runs a self-verification sequence. It checks system integrity, validates the running version against the expected hash, and confirms that core services have started correctly.
If verification passes, the bootloader marks the new slot as confirmed and the update is complete. If verification fails for any reason — a corrupted write, an unexpected crash on first boot, anything — the bootloader detects the failure on the next restart and switches back to the previous slot automatically.
The device comes back online on the firmware it was running before the update, with no data loss and no manual recovery procedure. The failed update is logged and reported to the update server for investigation.
Automatic — No User Action Required
We made a deliberate decision not to leave updates up to the user. When a new firmware version is published, devices receive it automatically. There is no "update available" notification that someone has to click. There is no update window that gets postponed indefinitely. There is no fleet of devices running six different firmware versions because some were updated and some weren't.
This matters for security. A known vulnerability in firmware version N is only a risk if devices are still running version N when the fix ships in version N+1. With automatic OTA delivery, the exposure window between patch release and deployment is measured in hours, not months.
It also means every customer — regardless of how actively they manage their installation — is always running the same current firmware. Support is simpler. Security posture is consistent. And the operational risk of running outdated firmware on a production floor is eliminated by design.
Update Process at a Glance
Want to Know More About How Simplinx Works?
Talk to our engineering team — we're happy to go deeper on any aspect of the platform.