TUF verified at the edge

Fleet updates without the leap of faith.

Meshanics ships containers, configs, service binaries and ML models to industrial device fleets - TUF-signed, verified on-device, and handled through typed recovery adapters. CRA evidence workflows are built into the release path. Zero integration for your application and model code.

our cloud · your cloud · fully air-gapped on one on-prem node

TUF

signed metadata and target verification on supported device update paths

<60s

measured model hot-swap on the reference device, with the prior model retained

1cmd

from factory-fresh device to certificate-enrolled fleet member

24h

CRA early-warning deadline manufacturers need to plan for

SEC 01Product

Release controls for production fleets

Built on proven open standards - The Update Framework (TUF) for update security and OCI for container images, with models, configs and service binaries delivered as verified TUF targets through one control plane.

01

Signed end to end

Containers, ML models, configs and service binaries are published through TUF. Supported device paths verify metadata and target integrity against a pinned root before activation.

02

Recovery is part of the adapter

Supported adapters retain prior state and evaluate a health probe before reporting success. Recovery guarantees depend on the payload type and device boundary, so the delivery matrix states the limit.

03

Evidence from the release path

Every state change - publish, rollout, approval, device update, rollback - enters an append-only hash chain. Evidence reports read the database record through an explicit verified sequence.

From signed artifact to rollout evidenceA signed artifact passes admission, canary and rollout waves before producing an evidence record. A failed health probe halts progression and invokes the recovery supported by the selected adapter.ARTIFACTTUF targetdigest pinnedADMISSIONSBOM + CVEdecision recordedCANARY 1%first cohorthealth probeWAVES 10/50%halt thresholdsapproval gatesFLEET 100%targeted deliverydevice resultsEVIDENCEaudit scopeCRA recordPROBE FAILS  ->  HALT + ADAPTER RECOVERY
1

Connect your devices

A single static agent (<15 MB, arm64/amd64) registers over mutual TLS and reports its hardware profile. Identity lives in the device certificate - never in a payload.

2

Publish signed artifacts

Push a model, container, config or service binary with one call. It is published through the signed update repository before rollout.

3

Roll out with confidence

Pick a fleet, wave strategy and health probe. Watch devices verify, activate and report results, with recovery handled according to the selected adapter.

Onboarding

Factory-fresh to fleet in one command.

The device generates its own key - it never leaves the device - exchanges a one-time token for a signed identity and the root of update trust, then appears in your console within seconds. How it works →

any linux device · arm64 / amd64key stays on-device
$ curl -fsSL https://meshanics.com/install.sh | sudo bash -s -- --token mesh_…
SEC 02Edge AI

ML models as first-class deployable units

Treat a model as a first-class deployable unit: deploy and canary vision models (ONNX, TensorRT, TFLite) across device fleets with signed targets, typed metadata and retained model-slot recovery.

  • [✓]Verified hot-swap on the reference path - a new model can become live in under a minute on the measured device, with integrity checked first
  • [✓]Canary cohorts for models - try the new weights on 5 devices before the other 500
  • [✓]Model-slot recovery - a failed health check can restore the retained prior model before the result is reported
  • [✓]Signed model metadata - optional manifest fields and the rollout-checked target hardware profile travel with the artifact
SEC 03The alternative

What the DIY update stack actually costs

Every OEM has shipped updates with scripts and good intentions. It works - until the one time it doesn't, in front of a customer, or an auditor.

Update signing

DIY · Optional, hand-rolled, easy to bypass under deadline pressure

Meshanics · TUF-published targets with device-side metadata and digest verification on supported paths

Failed update

DIY · Bricked unit, truck roll, angry plant manager

Meshanics · Health-probe result and adapter-specific recovery are recorded

ML models

DIY · scp and a prayer

Meshanics · Signed model targets with optional manifests, target-profile gating, canary cohorts and retained model slots

Device onboarding

DIY · Manual key ceremonies per device

Meshanics · One command - key generated on-device, never leaves it

Your container registry

DIY · Custom scripts pushing images to each device; credentials copied onto devices

Meshanics · Connect GHCR, ECR, Artifact Registry, JFrog or Harbor; pull through by digest, credentials stay in the control plane

Known vulnerabilities

DIY · Find out from the news, then grep which devices are affected

Meshanics · Continuous SBOM × CVE matching with affected-fleet evidence for review

A poisoned build

DIY · Signed or not, it ships to every device the moment someone hits deploy

Meshanics · Admission policy can block open critical CVEs; the decision and override are recorded

CRA evidence

DIY · Reconstructed from logs the week before the audit

Meshanics · Append-only database record verified through a disclosed sequence and available for export

Air-gapped sites

DIY · Cloud-only tooling stops at the firewall

Meshanics · Entire control plane runs on one on-prem node

SEC 04Security architecture

We assume the supply chain is the target

Update infrastructure has a wide blast radius, so Meshanics isolates trust per tenant, scopes online signing and verifies every release at the edge. Managed cloud roots use non-exportable KMS keys; customer-controlled roots can remain offline.

S1

Tenant-isolated root keys

Managed cloud tenants receive separate non-exportable KMS keys. Customer-controlled and air-gapped tenants can keep root and targets keys offline. Online publishing remains scoped to a delegated namespace.

S2

Untrusted transport

CDNs, registries and storage are treated as hostile. Devices verify signatures, hashes, lengths, versions and freshness - anything tampered, stale or replayed is rejected on-device.

S3

mTLS device identity

Every device holds its own X.509 identity. Repository access is tied to the active device and tenant from that certificate, never a request payload.

S4

Air-gap & on-prem ready

The whole control plane runs on a single on-prem node with no cloud dependency - built for defense and critical infrastructure.

S5

Target bytes stay scoped

A target download must match the certificate-derived tenant, logical artifact path and signed digest before bytes are served. Unknown or cross-tenant requests receive no target.

S6

Attack-tested updates

The device client ships with negative tests for the attacks that matter - tampered artifacts, frozen metadata, rollback replays, wrong-key signatures. Rejection is the default.

SEC 05Compliance evidence

Evidence for compliance work, not a compliance verdict

The EU CRA requires secure update mechanisms, vulnerability handling and supporting records. Meshanics collects verifiable release evidence as updates ship. The manufacturer and its assessors decide whether that evidence is sufficient.

  • [✓]Product-scoped records - version product scope, support periods and market-placement facts against the same Product ID used by signed releases
  • [✓]Secure-update evidence - show the signed and verified path plus its adapter-specific recovery boundary
  • [✓]Verifiable database history - validate every recorded event through a disclosed high-water sequence
  • [✓]Vulnerability handling records - promote a recorded SBOM finding into a linked assessment case, then record decisions and incident work
  • [✓]Article 14 case records - record assessment outcomes, calculate stage-specific deadlines and preserve submissions plus attachment digests
  • [✓]Reviewed product operations - preserve product risk revisions, signed-release change decisions, dependency and RDPS reviews, and vulnerability-handling decisions
  • [✓]Product-scoped dossiers - issue a revision-scoped package with its source records, review state, explicit gaps and customer-owned obligations
  • [✓]Portable signed evidence - verify complete report packages offline; locked managed retention remains an explicit deployment option
  • [✓]Honest assessment boundary - provide recorded facts and explicit gaps without calling the product compliant
One evidence engine · many frameworks
EU CRA
Cyber Resilience Act
Products with digital elements, EU
IEC 62443
Industrial automation & control
OT / industrial security
UNECE R156
Software update management
Automotive / vehicle type-approval
US FDA
Premarket cyber (524B)
Medical devices, US
UK PSTI
Product Security regime
Consumer connectable products, UK

CRA is the first workflow. The same append-only audit log, SBOM vulnerability watch and evidence-readiness engine can be mapped to other frameworks - select a framework, review the recorded facts and gaps, then export the report for assessment.

Reporting obligations begin · 11 Sep 2026
-days-hrs

From this date, actively exploited vulnerabilities and severe incidents must be reported through the applicable CRA and ENISA stages. Trigger dates and final-report timing depend on the event and corrective-action record. Full conformity follows 11 Dec 2027.

Maximum exposure under CRA Art. 64
maximum fine
€15 M

The higher of €15 M or 2.5% of worldwide annual turnover, for non-compliance with essential cybersecurity requirements - secure updates among them.

Onboarding design partners

Put your fleet on rails.

Industrial OEMs, device makers and teams shipping regulated products to real hardware - define the product boundary and prove the update path on your fleet.

Become a design partner