Security and compliance

Because Pantavisor owns PID 1, it is held to a higher trust bar than a deletable updater — these pages spell out the trust model and how its guarantees are tested.

Pages

• Trust model — what Pantavisor protects, the trust boundaries from secure boot to per-container integrity, and the end-to-end verification chain.
• Atomicity and trust evidence — a documented, reproducible power-fail and rollback test methodology (results forthcoming).
• Secure OTA updates — content-addressed object integrity, PVS signatures over the state JSON, x5c (JOSE/JWS) certificate chains, and the tamper-evident audit trail.

Runtime reference

The trust/signing model these pages describe is built on primitives defined on the pantavisor/ side, not repeated here:

• Revisions — what a revision actually is (the unit every signature covers).
• Objects and storage — the "Integrity" section has the full signing scheme: algorithms, verification points, and the disabled/audit/lenient/strict severity levels. Read this before concluding signing is optional — the state-format reference marks the signature manifest "Mandatory: No" because validation strictness is configurable, not because unsigned states are always accepted; lenient (the default) still fails a revision whose signature doesn't validate once present, and strict requires one.
• Claiming a device — the registration/claim flow that binds a device to a Pantahub account.
• pvr sig — signing commands and key flags.
• Licensing — what's open source (on-device code, MIT) vs. the commercial relationship (managed Pantahub service), and that Pantahub itself is self-hostable.

Planned coverage

Future pages will cover secret handling, SBOM generation and the CVE/update workflow, the recertification model (a frozen, certified base/BSP plus app-only container updates that preserve the safety case), Cyber Resilience Act readiness, and IEC 62304 / IEC 62443 positioning.