Update trust lifecycle
Every tenant has an independent TUF root lineage. A root change for one tenant does not change what another tenant's devices trust.
Meshanics-managed cloud trust
For managed cloud tenants, Meshanics creates a separate set of non-exportable, software-protected Google Cloud KMS signing keys for each tenant. The private key bytes cannot be downloaded into the database, control panel, repository or service filesystem.
Automatic bootstrap is fail-closed. A new cloud tenant is prepared only while the managed trust service has recently validated its KMS access and is reporting ready. If that service is paused, the tenant remains pending instead of falling back to shared trust. A platform owner can prepare it after service recovery.
Renewal starts 90 days before either root or targets metadata expires. The
service creates root version N+1, signs it with both the current and next root
keys, and makes it available through the normal device heartbeat. Devices fetch
the new root at their own pace and apply TUF's forward-only verification rules.
The current root stays active while distribution is in progress. Activation happens only after every active device has reported the exact pending root and an agreement record has been stored. A device that is offline does not receive a pushed connection or a burst of requests. It keeps the rotation visibly waiting.
The Trust Center shows:
- active and pending root versions and SHA-256 digests;
- when the next root was prepared;
- agreement across active devices;
- current role expiry and public key identifiers;
- failed attempts and errors that need attention;
- recent scheduled, incident and drill jobs for platform operators.
Tenant administrators receive an email after activation. They are also warned if device agreement remains incomplete for 24 hours or if the bounded rotation worker stops after repeated failures. The existing active root remains selected when a rotation fails.
Customer-controlled trust
Customer-controlled root and targets private keys stay in the customer's KMS, signer or offline environment. Meshanics validates and distributes signed public metadata but never receives those private keys.
The platform validates the active metadata and sends expiry notices at 90, 60,
30, 15, 7, 5, 3, 2 and 1 day before expiry. Notifications stop as soon as a new
sequential root with a new validated expiry is active. Structured trust.*
events can be routed through the tenant's configured integration as well.
Urgent rotation
A platform-owner incident action can open an urgent managed rotation for an online-role exposure, root-threshold exposure or planned drill. It requires an incident reference and exact confirmation. Urgent changes still require a sequential cross-signed root and device agreement. The action does not install an unverified trust anchor or silently re-enroll devices.