IoT OTA Update Stacks Compared: SUIT (RFC 9124), Uptane, Mender, RAUC and SWUpdate

Most teams pick an IoT OTA update tool by looking at the demo: a dashboard, a progress bar, a “deploy to 10,000 devices” button. The decisions that decide whether a recall costs you a weekend or a quarter sit lower down: what an attacker who owns your update server can do, whether a brownout halfway through a flash write leaves a brick, and what happens the day you must rotate a signing key that is burned into ten thousand devices.

The five names in this comparison do not even sit at the same layer. SUIT is an IETF manifest and architecture family. Uptane is a security framework for multi-ECU vehicles. Mender, RAUC and SWUpdate are installers and fleet tools for embedded Linux. Treating them as interchangeable products is the most common mistake in OTA selection, and it produces architectures that are either under-secured or over-built.

This post separates the layers, compares threat models and failure behaviour, and gives a decision matrix you can defend in a design review. All version and status facts were checked against primary sources in October 2026, and anything I could not verify is flagged.

What this covers: what each standard or tool actually specifies, the threat model each one answers, A/B partitioning and rollback mechanics, delta and key-rotation trade-offs, failure modes, and a selection matrix by device class.

Context and Background

A firmware update is, in the words of the IETF architecture document RFC 9019, essentially authorised remote code execution. Everything in OTA design follows from that sentence. If the signing key leaks, the update channel becomes the attacker’s deployment pipeline. If the device accepts any validly signed image, an attacker can replay last year’s vulnerable release. If a write is interrupted, the device may never boot again.

The industry converged on a common set of controls: signed metadata, monotonic version or sequence checks, redundant storage so a failed update cannot destroy the running image, and a bootloader that verifies before it jumps. What differs between stacks is how much of the threat model they address and for which class of hardware.

The standards picture is easy to get wrong, partly because the post title you probably searched with contains a common mislabel. RFC 9019, published April 2021 as an Informational RFC, defines the firmware update architecture for constrained IoT devices: the manifest, the status tracker, the bootloader role, and the stakeholders. RFC 9124, published January 2022, also Informational, is the information model: it lists 25 information elements a manifest must be able to carry, such as vendor and class identifiers, a monotonic sequence number, digests, and processing steps for compressed or encrypted payloads, and it uses STRIDE to derive them.

Neither RFC defines bytes on the wire. The wire format is the SUIT manifest specification, draft-ietf-suit-manifest, a CBOR-based serialisation. As of the datatracker record I checked on 4 October 2026 it was at revision 37 (dated 30 September 2026), approved for publication and sitting in the RFC Editor Queue, so it has no RFC number yet. Anything you read that calls the SUIT manifest “RFC 9124” is conflating the information model with the serialisation. I use “SUIT” for the family and name the document when precision matters.

Uptane comes from a different lineage. It adapts The Update Framework (TUF) to vehicles, where one car contains dozens of electronic control units (ECUs) from different suppliers, some with a full network stack and some with almost nothing. The current published standard line is 2.1.0; the 2.0.0 documentation page itself says it is no longer maintained. Uptane is governed as a Joint Development Foundation project by its community, and I could not find a publication date for 2.1.0 in the document text, so I do not state one.

Mender, RAUC and SWUpdate belong to the practical embedded Linux world, typically Yocto or Buildroot images on SoCs with an MMU. Mender adds a server and fleet management. RAUC is a client-side update controller built around signed bundles. SWUpdate is a flexible installer driven by a description file and handlers. Versions I verified against the projects’ release feeds: Mender client 5.1.0 (12 May 2026), RAUC v1.15.2 (27 March 2026), and SWUpdate 2026.05.1 (22 June 2026). Mender also publishes a separate MCU client for Zephyr, mender-mcu, at v1.1.0 (2 September 2026).

For the wider reference design of an update pipeline, including secure boot chains and staged rollouts, see our secure IoT OTA firmware update architecture guide. For the constrained end of the spectrum, where flash is measured in kilobytes, our Rust no_std firmware primer covers the code you will be updating.

Core Architecture: Four Layers That Every OTA System Must Fill

Direct answer: every IoT OTA update system has four layers: authoring and signing, metadata and trust model, transport and orchestration, and on-device install plus boot. SUIT and Uptane mainly define the second layer, Mender, RAUC and SWUpdate mainly implement the fourth, and only Mender ships the third as a product. Choosing one means choosing which layers you build yourself.

Figure 1: Generic IoT OTA update pipeline following the RFC 9019 roles. The server is treated as untrusted storage, and the device verifies everything itself.

The diagram shows the flow shared by all five stacks. A build system produces an image and signs a manifest that contains the image digest and constraints. An update server stores and distributes both. A status tracker on the device fetches them, checks the signature and the sequence number, writes the payload to an inactive location, and hands off to a bootloader that verifies and boots the new image. Finally something confirms health or triggers rollback.

The key architectural principle, stated in RFC 9019, is that the transport and the server are untrusted. Security comes from device-side verification of signed metadata, not from TLS to the server. TLS protects confidentiality and some availability, but a compromised update server behind a valid certificate must still be unable to push malicious code. Any design where the device trusts “whatever the server’s TLS endpoint hands me” has collapsed the model to a single point of failure.

Layer 1 and 2: signing and trust model

This is where the stacks diverge most. SUIT uses a single signed manifest, a CBOR structure that can be signed and authenticated with COSE, and encodes a sequence of commands for the device to execute: check vendor and class identifiers, check the sequence number, fetch the payload from a URI, verify its digest, install it, optionally invoke it. The interesting design decision is that the manifest is a small program, not a list of properties. That keeps the parser on the device simple and lets one manifest format describe a bootloader-only update, a multi-image update, and a dependency on another manifest.

Uptane splits trust across two repositories. The Image repository holds binary images and metadata signed with offline keys, changing rarely. The Director repository issues per-vehicle instructions, signed with online keys, based on an inventory of what each vehicle contains. A device with full verification compares both and refuses an image unless they agree. The consequence, per the Uptane standard, is that an attacker must compromise both repositories, or specific ECU combinations, to succeed. A stolen online Director key alone cannot install arbitrary software because the Image repository’s offline-signed metadata will not list it.

Mender, RAUC and SWUpdate take a more traditional approach: a signed artifact or bundle verified against a trusted certificate or key on the device. RAUC uses X.509 certificates and verifies bundle signatures. SWUpdate can sign the sw-description file and verify images when built with signing options. Mender artifacts are signed and verified with keys provisioned on the device. These are sound for a single image per device, but none offers the Uptane-style multi-repository compromise resilience out of the box, and the freshness and rollback story depends on how you configure and operate them.

Layer 3: orchestration

Only Mender, among the five, ships a complete orchestration product. Per its documentation it comprises build tooling for artifacts, a server that schedules deployments and monitors versions, and a client that polls. It supports managed mode, where a daemon polls the server, and standalone mode for local updates such as from USB. The docs also describe orchestrated multi-component updates with atomic rollback as an Enterprise feature.

RAUC explicitly says it is not a complete deployment application; it exposes D-Bus and expects you to integrate. SWUpdate includes a suricatta daemon that speaks to the hawkBit server, with other backends possible via an external parser or custom integration. SUIT and Uptane define no server product. For Uptane there are open-source implementations, and for SUIT there are reference libraries in RTOS ecosystems, but the fleet management backend is your decision.

Layer 4: install and boot

On-device install is where “brick or not” is decided, and the techniques are shared. A/B (dual-copy) rootfs, a bootloader environment that holds a slot choice and a try counter, and a health check that confirms the slot. SWUpdate documents both a double-copy with fallback strategy and a single-copy strategy that boots a minimal recovery system from RAM to rewrite the main storage, trading a smaller footprint for a longer outage window. RAUC supports symmetric A/B, asymmetric recovery layouts, and grouped partitions, with U-Boot, GRUB, barebox and EFI support. Mender uses dual partitions with automatic rollback if the new image does not commit.

The next sections compare how each stack behaves under attack and under failure.

Deeper Analysis: Threat Models, Rollback Mechanics, Deltas and Keys

What each stack defends against

The Uptane standard names five attack classes in its threat model: rollback, freeze, mix-and-match, endless data, and arbitrary software. These are inherited from TUF and are a useful checklist for any OTA system, because each maps to a concrete device-side control.

Arbitrary software: the device installs an image nobody authorised. Control: signature over image digest.
Rollback: the device installs an older, validly signed, vulnerable image. Control: monotonic version or sequence number checked against device state.
Freeze: the attacker serves stale metadata so the device never learns about a fix. Control: expiring metadata plus a trustworthy time source. Uptane requires ECUs to receive time or an attestation of sufficiently recent time at manufacture, and Primaries to load time from a secure source.
Mix-and-match: the attacker combines individually valid files from different releases. Control: a snapshot that pins versions of all targets metadata.
Endless data: the attacker streams unbounded content to exhaust storage. Control: signed length limits.

Here is how the five stacks line up. The SUIT column reflects the information model and manifest draft; Mender, RAUC and SWUpdate columns reflect what the projects document, and where a control is configurable rather than built in I say so.

Threat	SUIT	Uptane	Mender	RAUC	SWUpdate
Arbitrary software	Signed manifest with payload digest	Signed targets metadata, two repos	Signed artifact	X.509 signed bundle	Signed sw-description when signing enabled
Rollback	Monotonic sequence number is a required element	Version checks in metadata	Not a core guarantee in docs I reviewed, verify per deployment	Handled via bundle version and compatibility checks, policy is yours	Version comparison is configurable in sw-description
Freeze	Manifest sequencing, expiry handling is implementation detail	Timestamp role with expiry, time source required	Server-driven, client polls	Not addressed by the client itself	Not addressed by the installer itself
Mix-and-match	Dependencies expressed in manifest	Snapshot role	Artifact is a single unit	Bundle is a single unit	`.swu` is a single unit
Compromised server	Device verifies, server untrusted	Needs both repos compromised	Depends on signing key custody	Signature check on device	Signature check on device
Multi-ECU consistency	Multiple components in one manifest	Native, Primary and Secondary ECUs	Orchestrated updates, Enterprise	Out of scope	Out of scope

Read the “not addressed” cells carefully. They do not mean the tool is insecure; they mean the control lives elsewhere, typically in your backend, your key policy and your boot chain. A single-image bundle sidesteps mix-and-match by construction, which is why TUF-style snapshot machinery is overkill for a gateway with one rootfs but essential for a car.

Uptane in practice: why two repositories

Figure 2: Uptane verification. The Primary ECU cross-checks both repositories; constrained Secondary ECUs verify Director metadata only.

The flow in Figure 2 shows the structural trick. The Director knows which vehicle has which ECUs and tells each one exactly what to install. Because the Director is online and per-vehicle, its keys must live on a networked system, which makes it the high-value target. The Image repository is signed offline, rarely touched, and lists everything that has ever been approved.

A Primary ECU performs full verification: it fetches Targets metadata from both repositories and requires them to match. A constrained Secondary may perform partial verification, checking only the Director’s Targets metadata. The honest trade-off is that partial verification weakens the guarantee for that ECU alone, since a compromised Director could then instruct it. The Primary’s full check protects the path to the Secondary only if the Primary itself is honest. Uptane acknowledges this by recommending full verification for Secondaries wherever resources allow.

Reporting closes the loop. Per the 2.1.0 standard, each ECU produces a version report containing its identifier, the filename, length and hashes of its installed image, a latest verifiable time, and a nonce or counter that must change each cycle. The Primary bundles reports into a vehicle version manifest. This gives the Director authenticated ground truth about fleet state, and it is also an attack detector: an ECU that reports an unexpected hash is flagged.

A/B partitioning and what “atomic” really means

Figure 3: A/B slot update with trial boot. A power loss during the write leaves the active slot untouched; a failed health check exhausts the counter and the bootloader falls back.

All of Mender’s OS updates, RAUC’s symmetric layouts and SWUpdate’s double-copy mode follow the pattern in Figure 3. The updater writes the inactive slot while the system runs from the other. Only after the write completes and verifies does it flip a bootloader variable to try the new slot. The bootloader decrements a counter on each boot attempt. If userspace does not mark the slot good before the counter reaches zero, the bootloader switches back.

The critical property is that the “commit” is a single small write to the bootloader environment, and that write must be atomic or at least recoverable. U-Boot environment redundancy, EFI variables and the barebox state framework exist for exactly this reason. If your board stores the environment in a single copy on a flash sector that can be half-erased by a brownout, your A/B scheme has a hole no updater can close.

Two other limits apply. First, A/B doubles the storage for the updated component. As an illustrative calculation: a 200 MB rootfs with a 50 MB kernel and 10 MB bootloader environment region needs roughly 2 x 250 MB plus shared data, about 500 MB of raw flash before wear margin. Second, A/B only protects what it covers. If the bootloader itself is updated in place, or if a data partition schema migrates irreversibly on first boot of the new slot, rolling back the slot does not roll back the damage. RFC 9019 recommends keeping minimal bootloader code immutable in ROM for this reason.

The single-copy alternative, documented by SWUpdate, boots a recovery image into RAM and rewrites the system. It halves storage needs, which matters on small NAND parts, but the device is offline for the full write, and a power loss leaves the recovery partition as the only path forward. That recovery partition must itself be treated as critical, immutable code.

Delta updates

Full-image updates are simple and robust but costly on cellular links. Mender’s documented delta support uses its mender-binary-delta tool, which builds on xdelta, and requires two OS artifacts to compare, the generator on your build host, and a device whose local state was initialised by a bootstrap artifact or a previous OS update. The device must hold exactly the base image the delta was generated against, otherwise the delta cannot apply.

That constraint is the real cost of deltas, and it applies to every tool: you must track which base each device runs, generate a delta per base, and keep a full-image fallback. With a fleet fragmented across five releases, you may generate four deltas per release. SWUpdate supports delta approaches through its handler framework, and SUIT’s information model includes processing steps for compressed payloads and a differential concept, but the details depend on the implementation and I have not verified a standard delta algorithm in the manifest draft, so I make no claim there.

An illustrative bandwidth calculation, with made-up figures: a 120 MB image where 6 percent of blocks change gives a delta of roughly 7 to 10 MB depending on how compressible and aligned the changes are. Across 50,000 devices that is about 350 to 500 GB instead of 6 TB. The saving is real, but a rebuild that reorders a filesystem can wreck delta efficiency, so measure on your own artifacts.

Key rotation and revocation

Key rotation decides whether your OTA system survives its first incident. The patterns differ:

Uptane has an explicit root role that distributes public keys for the other roles and manages revocation. The standard even specifies cleanup, for example deleting previous Timestamp and Snapshot metadata after those keys rotate.
SUIT supports multiple signatures and delegation through its trust model, but the root of trust and its rotation policy are the deployer’s responsibility. Provisioning a second trust anchor at manufacture is the cheap insurance.
RAUC verifies against keyrings of X.509 certificates, so you can ship a keyring with multiple trusted certificates and rotate by signing bundles with the new one. Revocation lists are possible but must be provisioned.
Mender and SWUpdate verify against provisioned keys or certificates; rotation means updating the on-device key through a signed update signed by the old key, which is itself a risky operation.

Plan the order: ship the new trust anchor in an update signed by the old key, wait for fleet saturation, then switch signing. Devices that miss the window need a recovery path, which is a manual or physical process.

Figure 4: Selection tree by device class and operating model.

Decision matrix

Criterion	SUIT	Uptane	Mender	RAUC	SWUpdate
Layer	Manifest and architecture	Security framework	Installer plus server	Installer	Installer plus agent
Target hardware	Constrained MCUs upward	Multi-ECU vehicles	Embedded Linux, plus MCU client	Embedded Linux	Embedded Linux
Fleet server included	No	No, implementations vary	Yes	No	Via hawkBit integration
Compromise resilience	Per implementation	Highest, two repos	Key custody dependent	Key custody dependent	Key custody dependent
Multi-component updates	Native	Native	Enterprise orchestration	Manual grouping	Handlers and scripts
Licence	IETF documents, implementations vary	Community standard	Client Apache-2.0, some features commercial	LGPL-2.1	GPL-2.0 per repository metadata
Maturity signal	Manifest draft 37 in RFC Editor Queue	Standard 2.1.0	Client 5.1.0	v1.15.2	2026.05.1

Trade-offs, Gotchas, and What Goes Wrong

Power loss during write. With A/B this is the benign case: the inactive slot is half-written, the active slot is intact, and the bootloader variable still points to the old slot. The dangerous cases are the ones A/B does not cover: a bootloader update in place, a firmware update that also rewrites a shared configuration partition, and a flash controller that corrupts neighbouring pages on brownout. Test by cutting power at randomised points in the write, not only at the end, and run it several hundred times per hardware revision.

Rollback protection that rolls back too well. A monotonic counter stored in tamper-resistant memory is the strong defence against downgrade attacks, and the SUIT information model makes the sequence number a first-class element. The cost is irreversibility. If you ship a bad release with a high sequence number and cannot reuse that number, your fix must carry a higher one, and a device that burned a hardware anti-rollback fuse cannot return to an older known-good image at all. Separate the security version, which gates downgrade and is rarely bumped, from the release version, which changes every build.

Health checks that lie. Rollback only triggers if something fails to confirm. If your health check only asks “did the service start”, a build that boots, connects, and then silently stops reading sensors will commit. Make the confirmation depend on a real end-to-end signal such as a successful authenticated message to the backend, and keep the trial window long enough for slow-failing faults, balanced against how long you can tolerate a bad slot.

Time and freeze attacks. Metadata expiry only protects you if the device has a trustworthy clock. A device with a battery-less RTC that boots at epoch zero will either reject all metadata or, if you disable expiry to cope, lose freeze protection. Uptane’s requirement that time be supplied at manufacture and refreshed from a secure source exists because of exactly this problem.

Parser and size bugs in the verifier. The verifier is part of your attack surface. RAUC v1.15.2, released 27 March 2026, rejects bundles in the plain format whose payload exceeds 2 GiB, to fix an integer overflow affecting signature verification tracked as CVE-2026-34155. I cite this not as a criticism, since the fix was prompt, but as a reminder that signature checking code needs patching like anything else, and that your update client needs its own update path to receive those fixes.

Key custody dominates. For Mender, RAUC and SWUpdate the question is where the signing key lives. A key on a build server reachable by CI is a key an attacker can use. HSM-backed signing, a separate release approval step, and multi-signature policies, which SUIT’s model explicitly supports, reduce that risk. Uptane’s offline Image repository keys are the same idea formalised.

Over-engineering. Uptane brings real cost: two repositories, an inventory database, ECU version reporting, and time handling. For a fleet of single-image gateways it is more machinery than the threat model demands. Equally, adopting a SUIT manifest parser on a Linux gateway that already runs RAUC adds complexity for no gain. Match the control to the exposure.

Standards churn. The SUIT manifest has been in draft form for years and is only now in the RFC Editor Queue. Implementations track draft revisions, and the final RFC could still change details during editing. Pin to a specific draft revision in your device and your signing tools, and plan an interoperability test when the final RFC lands. I have not verified which open-source implementations track revision 37, so check before assuming compatibility.

Vendor edition boundaries. Per Mender’s documentation, orchestrated multi-component updates are an Enterprise feature. Verify which capabilities you need are in the edition you are buying, including delta updates, whose edition availability the docs I read did not state.

Practical Recommendations

Start from the device, not the tool. If you ship Zephyr or RTOS firmware on microcontrollers with limited flash, the SUIT family is the standards-aligned direction, with Mender MCU as a vendor-backed route for Zephyr, and you will own the backend either way. If you ship Linux gateways or industrial PCs, Mender, RAUC and SWUpdate are all production choices, and the decision is mostly about operating model: Mender if you want a ready fleet server, RAUC if you build on Yocto or PTXdist and want a tightly scoped signed-bundle client you integrate yourself, SWUpdate if you need flexible handlers, scripts and a hawkBit connection. If you build vehicles or equipment with many supplier ECUs, evaluate Uptane first, because its two-repository model addresses a threat the others leave to you.

Do not choose on features alone. Write down the three attacks you most need to survive, such as signing-server compromise, downgrade to a known-vulnerable image, and a bricking power cut, and map each to a specific control and a test. If a tool leaves a control to you, budget the work.

Then fix the unglamorous parts: a redundant, atomic bootloader state, a security-version counter separated from the release version, a health check tied to real backend traffic, an HSM or equivalent for the signing key, and a documented key rotation rehearsal.

Checklist before you ship an update channel:

[ ] Threat model written, covering arbitrary software, rollback, freeze, mix-and-match and server compromise.
[ ] Device verifies signed metadata itself; the server and transport are treated as untrusted.
[ ] Monotonic version or sequence check enforced, with a separate security version.
[ ] A/B or recovery layout tested with randomised power cuts, hundreds of cycles per hardware revision.
[ ] Bootloader environment or state is redundant and atomically committed.
[ ] Health check confirms an end-to-end signal, with a bounded trial window.
[ ] Trusted clock source defined, and metadata expiry behaviour decided.
[ ] Signing keys in an HSM or separate approval flow, with a second trust anchor provisioned.
[ ] Key rotation rehearsed on a test fleet, including a device that misses the window.
[ ] Update client and verifier patched through the same channel, with a security advisory feed watched.
[ ] Delta base tracking and full-image fallback in place if you use deltas.

Frequently Asked Questions

Is SUIT the same as RFC 9124?

No. RFC 9124, published in January 2022 as an Informational RFC, is the information model: it defines 25 information elements a manifest should carry and the threat model behind them. The architecture is RFC 9019. The actual CBOR manifest format is draft-ietf-suit-manifest, which at revision 37 on 30 September 2026 sits in the RFC Editor Queue without an RFC number. SUIT as a family therefore spans these documents plus companions on encryption and mandatory algorithms, and implementers should name the document they follow.

What is the difference between Uptane and TUF?

Uptane adapts The Update Framework to vehicles. TUF assumes a client that can fetch and verify several metadata roles; Uptane adds a Director repository that issues per-vehicle instructions, an Image repository signed offline, ECU version reports, and distinct handling for Primary and Secondary ECUs. Its aim is that an attacker must compromise both repositories, not just one, to install arbitrary software. Constrained Secondary ECUs may use partial verification, which verifies only the Director’s Targets metadata, a deliberate resource trade-off.

Should I use Mender, RAUC or SWUpdate for embedded Linux?

Choose by operating model. Mender bundles a server, client and artifact tooling, so it suits teams that want managed fleet deployments out of the box. RAUC is a focused client built around signed X.509 bundles and exposes a D-Bus interface for you to integrate. SWUpdate is a flexible installer driven by a description file, handlers and optional hawkBit connectivity. All three support redundant-slot patterns. The right answer depends on your backend, build system, licensing tolerance and how much integration work you can own.

Do A/B partitions protect against a bricked update?

They protect against a failed or interrupted write to the inactive slot, because the running slot is never modified. They do not protect against a bootloader overwritten in place, an irreversible data migration run by the new image, a corrupted bootloader environment, or a build that boots but misbehaves without failing the health check. Test power cuts at random points, make the slot-switch commit atomic, and tie confirmation to a real end-to-end health signal.

How do I prevent rollback attacks in an IoT OTA update?

Embed a monotonically increasing sequence or security version in signed metadata and have the device refuse anything lower than its stored value. Keep that stored value in tamper-resistant memory such as a secure element or fuses where possible. SUIT’s information model makes the sequence number a core element, and Uptane covers rollback in its threat model. Separate the security version from the release version so a bad release does not force a permanent anti-rollback bump.

Are delta updates worth the complexity?

They are worth it when bandwidth is expensive and the fleet is concentrated on few base versions. Mender’s delta tooling builds on xdelta and requires both artifacts plus a device whose state matches the base. Any delta system needs base tracking, per-base generation, and a full-image fallback. As an illustrative case, a 6 percent block change on a 120 MB image might yield a delta around 7 to 10 MB, but filesystem layout changes can erase the saving, so measure on real artifacts.

References

B. Moran, H. Tschofenig, D. Brown, M. Meriac, “A Firmware Update Architecture for Internet of Things”, RFC 9019, IETF, April 2021. https://datatracker.ietf.org/doc/rfc9019/
B. Moran, H. Tschofenig, H. Birkholz, “A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices”, RFC 9124, IETF, January 2022. https://www.rfc-editor.org/info/rfc9124
B. Moran, H. Tschofenig, H. Birkholz, K. Zandberg, O. Ronningstad, “A CBOR-based Serialization Format for the SUIT Manifest”, draft-ietf-suit-manifest-37 (RFC Editor Queue), IETF datatracker, checked 4 October 2026. https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/
Uptane Standard 2.1.0 and 2.0.0 documentation, Uptane Community. https://uptane.org/docs/2.1.0/standard/uptane-standard
RAUC documentation and release v1.15.2 notes (CVE-2026-34155). https://rauc.readthedocs.io/ and https://github.com/rauc/rauc/releases
SWUpdate overview and releases, 2026.05.1. https://sbabic.github.io/swupdate/overview.html
Mender documentation: overview and delta updates; mender and mender-mcu GitHub releases. https://docs.mender.io/

By Riju – about

SUIT (RFC 9124) vs Uptane vs Mender, RAUC and SWUpdate: IoT OTA Update Comparison