Evidence & reports
Availability: Compliance reports, report history, and issued evidence dossiers require the optional Compliance & Evidence module. Core signed release receipts remain available on every plan.
Everything the platform records - enrollments, publishes, rollouts, rollbacks, incident steps, vulnerability triage - feeds a small set of exports you can hand to an assessor, a buyer, or a regulator. Each one is computed from the recorded audit log and registry, never asserted ahead of it.
The audit log
Every meaningful action is written to an append-only log where each entry is hash-chained to the one before it. Altering any stored row - even by a database administrator - breaks the chain, and the break is detectable.
You can export the full log as line-delimited JSON. The chain is verified during export and the verdict travels with it: the export states how many events it covers, whether the chain verified, and the head hash. When export signing is configured, a detached signature over the whole export is appended, and the verifying public key is published so a notified body or auditor can check it without trusting the inline copy.
Framework readiness report
The readiness report evaluates a framework's requirement set against your recorded facts and renders the result as a branded PDF - the document an assessor or buyer files. Each requirement carries an honest status:
| Status | Meaning |
|---|---|
| Evidenced | The named sources provide evidence for the stated scope and freshness. |
| Review required | Recorded evidence or a customer decision still needs review. |
| Gap | Required evidence is not currently recorded for this scope. |
| Not applicable | A reviewed decision says the row does not apply to this scope. |
| Out of platform scope | The manufacturer or another party must perform this work outside Meshanics. |
Each row names its sources, freshness, product or tenant scope, and reviewer state. The report includes the underlying evidence counts - devices under management, artifacts published, rollouts performed, automatic rollbacks, SBOM coverage, audit events recorded and chain integrity, plus overdue incident steps. The EU CRA profile is the default; the same recorded reality renders against the other supported frameworks too.
When signing is configured, the report carries a provenance page: the evidence is bound into a canonical payload, and the report identifier and signature derive from its digest, so a tampered fact no longer matches the signature.
Vulnerability report
A companion PDF summarises the current vulnerability posture across your artifacts - open findings, severity breakdown, and the per-artifact picture drawn from the vulnerability watch. Like the readiness report, it can be signed.
Article 14 case record
Each Article 14 case has a JSON download containing the current case facts, every assessment conclusion, every regulator-submission revision, every impacted-user notification revision, and metadata plus SHA-256 digests for its bounded attachments. The consolidated CRA evidence report includes the same case records. Assessment, submission, attachment, and notification revisions are append-only in the service database.
The direct JSON download and consolidated JSON report are preview snapshots. They are not labelled as issued or immutable evidence. Issue case evidence creates a separate package containing deterministic case JSON and every attachment byte. Meshanics verifies each attachment's stored length and SHA-256 digest before sealing. A missing, substituted, or changed attachment stops issuance. Where configured, the issued package also receives the locked-storage witness receipt described below.
Product-scoped CRA dossier
The product register can preview and issue a dossier for its current immutable product revision. The dossier contains that revision and its declared versions, reviewed risk and signed-release change decisions, dependency and RDPS reviews, exact-finding vulnerability decisions, linked update and end-of-support evidence, the matching signed release archive, and explicit gaps. Historical product revisions are preserved in the register and can become separate issued snapshots; they are not silently combined into the current revision's scope.
The dossier assembles evidence. It does not determine legal scope, declare conformity, or submit a notification to a regulator or CSIRT.
Preview reports and issued evidence
Reports reflect a moment in time, and your fleet keeps moving. Two mechanisms keep the evidence honest:
- Freshness tells you whether the live evidence still matches the last issued artifact, or whether it has drifted and is due for a refresh.
- Issuance seals the report only when the underlying evidence changed. It creates a signed manifest and verifies every delivered byte. A deployment configured with retention-locked storage can additionally retain the exact content-addressed core and issue an independent witness receipt.
The PDF and JSON views are previews until you issue them. An issued artifact is not edited in place. A correction must become a new artifact linked to the prior digest.
The console reads the server capability before naming this action. A deployment without retention-locked storage and an independent witness shows Archive preview, not Issue evidence. That archive supports historical comparison, but it is not immutable managed evidence.
What the customer download contains
The downloaded .evidence.zip file contains:
evidence.zip, the deterministic signed core;witness.json, the independent storage and retention receipt;VERIFY.txt, short verification instructions.
Inside the core, manifest.json lists every report object with its media type,
length, and SHA-256 digest. manifest.sig.json binds that manifest to the
evidence signing key. New manifests also bind the expected evidence and witness
key IDs and public material. The verifier rejects a valid receipt from a
different witness key. Missing, added, substituted, or changed bytes fail
verification.
Use the Open Source verifier without a network connection:
go run ./cmd/meshanics-evidence verify \
-key-history meshanics-evidence-verification-keys.json \
ME-EXAMPLE.evidence.zip
Download the verification-key record from Evidence - Issued evidence -
verification key history before moving the package offline. The record is
scoped to your tenant and contains the current keys plus every key previously
used for its issued packages. Save the PEM values matching the package key IDs
as evidence.pub and witness.pub when verifying manually, or pass the history
JSON directly with -key-history. The verifier selects the exact IDs recorded
by the package and rejects history from another tenant. It distinguishes a
cryptographically valid inline key from a signer identity checked against a
public key you already trust. Rotating an active key does not remove the public
material required to verify older packages.
Immutability boundary
Meshanics cannot prevent a recipient from editing a local file. It makes an edited copy fail verification. When the managed service is configured with a locked retention policy, the ordinary application identity cannot overwrite the authoritative core, shorten its retention, or delete it early, and the customer download carries that storage receipt.
An evaluation deployment using ordinary mutable object storage does not meet
this managed-copy immutability boundary and must not label its reports
issued - externally witnessed or immutable managed evidence.
A note on framing
These reports assemble and evidence; they do not certify. Submission and certification remain the manufacturer's act, and each report says so plainly. Evidence packages contain the report objects and supporting product-security metadata selected for that report. Application payload contents are not added to a dossier unless the report explicitly includes them as an evidence object.