Security mechanisms and assurance boundaries.
We build update infrastructure, which means we are part of your supply chain. This page describes the mechanisms that protect it - stated plainly, and measured live inside the platform rather than asserted.
TUF-published targets
Every artifact - container, model, config or service binary - is published through TUF; devices verify the metadata chain against a root pinned on the device.
Supply-chain integrity
Mutual TLS device identity
Devices hold per-device X.509 identities; private keys are generated on the device and never leave it.
Device identity
Tenant-isolated roots of trust
Managed cloud tenants use separate non-exportable KMS keys; customer-controlled and air-gapped tenants can keep root and targets keys offline. Online publishing uses a scoped delegated role.
Key management
Hash-chained audit log
Every recorded state change enters a database hash chain. Verification walks every page through a disclosed high-water sequence.
Evidence
Active artifact re-measurement
The Linux agent periodically compares supported active files and managed container images with the last-known-good result recorded after rollout.
Installed state
Encrypted secrets at rest
Registry credentials are AES-256-GCM encrypted in the control plane and never reach a device.
Data protection
argon2id passwords, scoped API keys
Passwords are argon2id-hashed; API keys are stored only as SHA-256 and cannot manage users or other keys.
Access control
Tenant-authorized target delivery
A target download must match the active certificate identity, tenant, logical artifact path and digest before bytes are served.
Delivery authorization
Air-gap deployable
The entire control plane runs on a single on-prem node with no cloud dependency in the core path.
Deployment
Assurance levels
| Area | Current state | What supports it | Limit |
|---|---|---|---|
| Artifact authenticity | TUF-verified | The device verifies signed metadata, target hash, length, version and freshness against its pinned root. | TUF role custody follows the tenant trust model. Target-byte authorization is tenant-scoped. |
| Device access | Certificate-authorized | Repository reads require an active device identity derived from mutual TLS. | Software-generated device keys do not imply hardware key protection. |
| Installed result | Device-signed | Customer-authorized releases produce a receipt signed by the enrolled device identity. The agent also re-measures supported active files and managed containers after rollout. | The signing key is software-held. Compose, OS images and package-manager state are not measured by this scanner. |
| Device operational context | Bounded device report | Linux heartbeats can include local assigned addresses plus interval-based CPU, memory, data-disk and uptime values with exact observation time. | This is not host monitoring or attestation. It excludes processes, users, routes, neighbors, sockets, files and payload contents. |
| Multi-component release | Signed and transactional | A customer-signed release fixes the complete member set and activation order. Devices stage every member, keep a crash journal and produce one ordered transaction receipt. | Available for containers, models, placed configs and systemd service binaries. Compose, OS images and DEB/RPM packages are refused in this path. |
| Audit integrity | Database-verified | Every tenant event is verified through an explicit high-water sequence; exports can be signed when a key is configured. | The database chain is not an external transparency witness or independent timestamp. |
| Rollback | Adapter-enforced | Current handlers retain previous state and use health probes to decide whether to restore it. | Rollback guarantees depend on the payload adapter and device recovery boundary. They are not universal transaction guarantees. |
| CRA workflow | Evidence available | Reports map recorded update, SBOM and vulnerability facts to reviewed framework profiles. Article 14 cases retain assessment outcomes, regulator-submission revisions and attachment digests. | Meshanics does not declare conformity, submit to ENISA, or replace the manufacturer's legal and product-security process. |
Delivery support
| Area | Current state | What supports it | Limit |
|---|---|---|---|
| OCI containers | Available | Digest-pinned image descriptors, constrained runtime arguments, health checks and rollback. | The customer supplies and operates the container runtime and application health contract. |
| ML models | Available | Signed model targets with optional manifest metadata, target-profile gating and health-driven rollback. | Quality statistics are operational evidence, not proof that a model is safe or accurate for its intended use. |
| Configs and service binaries | Available | Allowlisted placement, typed systemd activation, readiness checks and restoration of the prior file. | The service unit and allowed destinations are configured on the device; arbitrary remote execution is not provided. |
| Zephyr firmware | ESP32-S3 profile | Signed compact manifests bind tenant, product, profile, release digest and rollout to verified firmware bytes, customer health authority and MCUboot confirmation rules. | The default monotonic counter is software-held in NVS. Production use requires qualification of the exact board, flash layout, boot policy and automatic revert behavior. |
| ESP-IDF / FreeRTOS firmware | ESP32-S3 profile | The ESP32-S3 component self-enrolls with an on-device key, verifies schema-v2 signed release bindings, streams and hashes the candidate, persists anti-rollback state and uses ESP-IDF A/B confirmation. | Other FreeRTOS BSPs are outside this profile. Production use requires protected provisioning storage and qualification of update and revert behavior. A second customer-owned image signature requires Secure Boot v2. |
| Linux A/B system images | Qualified RAUC profiles | Customer-signed RAUC bundles are TUF-verified, inspected and installed through the native system D-Bus service with boot evidence in the device receipt. | The product image must provide a working A/B layout, RAUC keyring and bounded bootloader policy, qualified on the exact hardware profile. |
| DEB and RPM transactions | Not available | No package-manager rollout path is exposed. | Package delivery needs an immutable dependency snapshot and a credible recovery boundary before release. |
Certifications
Meshanics does not currently hold ISO 27001 or SOC 2 certification. This page lists the implemented controls and their limits. The console reports live state where the platform can measure it. Found something? Write to hello@meshanics.com (see security.txt).