Evaluation guide - reviewed 3 September 2026

Compare the update boundary, not the feature count

Mender, balena, hawkBit, Memfault, RAUC and Meshanics solve overlapping but different problems. This comparison states where each product is a sensible choice and links to the primary documentation used.

Meshanics

Meshanics security boundary
Best-aligned boundary
Signed application, model and multi-component releases on existing Linux fleets
Device side
Static arm64/amd64 agent included
Trust
TUF metadata rooted on the device plus per-device mTLS
Recovery
Typed adapter recovery; RAUC for qualified A/B system images
Evidence
Signed releases, device receipts, SBOM/CVE correlation and issued CRA evidence

Mender

Mender Artifact documentation
Best-aligned boundary
A/B system updates plus extensible application updates
Device side
Mender client and Update Modules
Trust
Signed Mender Artifacts with checksums; evaluate key workflow for your edition
Recovery
A/B OS rollback and module-specific behavior
Evidence
Deployment and device records; confirm compliance-export scope with Mender

balena

balena update strategies
Best-aligned boundary
Container application management on balenaOS fleets
Device side
balenaEngine, supervisor and balenaOS
Trust
Platform and registry controls; evaluate the exact artifact trust boundary
Recovery
Application update strategies and host OS rollback
Evidence
Fleet and application operations; confirm compliance-evidence scope with balena

Eclipse hawkBit

hawkBit DDI API
Best-aligned boundary
Open-source rollout-management backend
Device side
Device-side client and installer selected by the implementer
Trust
Transport and artifact validation depend on the integrated client and repository design
Recovery
Activation and recovery belong to the device integration
Evidence
Rollout state and action history; product compliance workflow is an integration concern

Memfault

Memfault Linux OTA
Best-aligned boundary
Device observability with OTA release distribution
Device side
SDK or Linux integration; supports SWUpdate, hawkBit-compatible and generic flows
Trust
Depends on the selected device update integration
Recovery
Depends on the selected Linux installer and partition design
Evidence
Fleet diagnostics and release operations; confirm CRA dossier scope with Memfault

RAUC

RAUC basic concepts
Best-aligned boundary
Signed, robust A/B system-image installation on embedded Linux
Device side
RAUC installer integrated into the target OS
Trust
Signed bundles and a device-configured keyring
Recovery
Boot-slot fallback with bootloader integration
Evidence
Device installer state; fleet, vulnerability and compliance systems sit above it

This is a first-party evaluation guide, not an independent benchmark. Product editions and behavior change. Verify current scope, licensing and recovery behavior with each vendor using your own image and failure cases.

Proof exercise

Questions every evaluation should answer

  1. 01What root of trust is present before the first network enrollment?
  2. 02Which component decides that a candidate is healthy, and what state can it actually restore?
  3. 03What happens on power loss between staging, activation and result reporting?
  4. 04Can one release bind several components and produce one device result?
  5. 05Can the system show which devices still run a vulnerable artifact version?
  6. 06Can an exported evidence package be verified without access to the vendor account?
  7. 07Does air-gap mode preserve end-to-end device verification or terminate trust at the gateway?
Run a Meshanics evaluationAsk about a migration boundary