Skip to content
SVHSoftware

Zero Trust, from silicon to record.

SVH assumes the network is hostile, the gateway can be compromised, and third-party code will misbehave — and is architected so that none of those events becomes an incident.

  1. Hardware root of trust

    Device identity lives in a TPM 2.0 and never leaves it. Devices prove identity — and on TPM hardware, boot integrity — through remote attestation.

  2. Mutual TLS everywhere

    Every connection is mutually authenticated with per-device X.509 certificates and pinning. The network is never trusted, inside the hospital or out.

  3. Server-signed commands

    Commands to devices carry their own signatures, verified on the device. A compromised gateway cannot forge an instruction.

  4. Sealed payloads

    Sensitive payloads are encrypted end to end — platform infrastructure moves them without seeing plaintext. For medical devices, patient identity is structurally isolated from analytics and telemetry.

  5. Least-privilege sandboxing

    Every module on the device runs with only the permissions its signed manifest declares, enforced by the operating system. Default-deny.

  6. Tamper-evident audit

    Every privileged action, sensitive-data access, and configuration change lands in a cryptographically chained, append-only, exportable audit trail.

Defense in depth is the point: identity, transport, authorization, data, runtime, and audit each hold on their own. No single layer is load-bearing.

The trust chain

Every certificate and signature traces back to one root that SVH keeps in a hardware security module. Each partner gets its own branch, so partners stay isolated from each other.

The SVH trust root, held in an HSM, signs each partner's trust list. Each partner has a device certificate authority that issues factory birth certificates, and signing keys for updates and catalogs. Each site has its own certificate authority that swaps a device's birth certificate for an operational certificate. Partner A and partner B are isolated from each other. SVH trust root in an HSM, at SVH Partner trust list one per partner Site CA one per Fleet Server Device certificate operational, auto-renewed Partner device CA issues factory birth certificates Partner signing keys birth certificate is swapped for an operational one Partners are isolated: a site trusts only its own partner's devices and releases.

You can see everything we ship.

Supply-chain evidence comes with every release, not on request.

SBOM with every release

A CycloneDX software bill of materials ships with every image and agent release — served from a live endpoint, not attached to an email.

Signed and pinned

Container images are cosign-signed and digest-pinned; device modules are signed and verified before they run. Nothing unsigned executes anywhere.

Memory-safe core

The device agent is written in Rust with unsafe code banned outside audited hardware interfaces, and builds reproducibly.

Designed to support your submission.

What our documentation gives your regulatory team.

IEC 62304 Software lifecycle discipline; the device platform is kept free of clinical logic to support SOUP and design-control scoping.
IEC 81001-5-1 Security activities in the software lifecycle, designed in from architecture down.
FDA premarket cybersecurity guidance (2023) SBOM with every release, secure update with rollback, attestation, and anomaly reporting.
HIPAA / GDPR Encryption in transit and at rest, PHI-access audit logging, structural de-identification of analytics.

SVH is designed to support these programs — it does not by itself constitute clearance, certification, or legal compliance. When in doubt, the platform prefers the stricter option.

Bring your security team.

Answer six short questions. Within two business days we reply with the path for your device. Then we book a demo with your engineers.

What kind of device?

Prefer to talk first? Book a demo