Two release boundaries that now verify more

A rollout is not trustworthy just because its artifact has a signature. The system also has to answer two practical questions:

1. Is this device allowed to receive these exact bytes?
2. Does the exported record cover the full history it claims to cover?

This release tightens both boundaries.

Target delivery is tied to device identity

Devices connect to the update repository with their own X.509 certificate over mutual TLS. Meshanics now applies that identity again when serving TUF metadata and target bytes.

The device must be active in the tenant named by its certificate. For a target download, three values must then agree before the file is opened:

• the certificate-derived tenant
• the logical artifact target recorded for that tenant
• the SHA-256 digest in the TUF consistent-snapshot path

A missing, inactive or decommissioned device is denied. A malformed identity, unknown target, cross-tenant target or digest mismatch receives no artifact bytes. The tenant is never taken from a query parameter or request body.

This is a serving-boundary authorization check. The device still performs its normal TUF verification before accepting the artifact, so authorization at the server does not replace cryptographic verification at the edge.

Audit verification no longer stops at a fixed window

An append-only hash chain is useful only if the verifier reads all of the record it claims to verify. Checking the first 100,000 events can produce a valid result for that prefix while saying nothing about later events.

Meshanics now fixes a tenant-local high-water sequence at the start of each verification. It then reads the audit history in pages and carries the prev_hash relationship across every page boundary. Verification fails if a page is missing, a row is out of scope, the chain starts incorrectly, or the walk ends before the high-water event.

The same complete walk is used by:

• the Trust Center audit view
• JSONL audit exports, with signing when configured
• evidence-readiness calculations
• CRA evidence reports

The control panel shows the exact database sequence through which the chain was verified. The JSONL trailer and evidence report carry the same high-water sequence, so a reviewer can see the scope instead of relying on a generic green badge.

We test this path beyond 100,000 events and separately test interrupted page reads. There is no product-level event ceiling in the verifier now.

What the result proves, and what it does not

The result proves continuity of the database-resident tenant record through the reported high-water sequence. It detects changed events and missing events inside that scope.

It does not claim that the database is an external transparency service. A separate witnessed checkpoint is needed to prove that a privileged rewrite did not remove a valid suffix and present a lower high-water mark. We keep that distinction visible because "database chain verified" and "externally witnessed" are different assurance levels.

It also does not turn a CRA evidence report into a compliance verdict. The report records what Meshanics can demonstrate about publishing, rollout, rollback, vulnerability handling and incident work. The manufacturer and its assessors remain responsible for product scope, risk decisions, submission and conformity.

Why these details matter

Most release failures happen between the headline controls. The artifact may be signed, but the serving path is too broad. The log may be hash-chained, but the verifier reads a convenient prefix. Both can look reassuring in a diagram.

Release assurance is the less glamorous work of making the scope explicit and checking it at each boundary. That is what these changes do.

You can inspect the database verification scope in Trust Center - Audit & evidence, or download the JSONL record and inspect its _chain trailer.