No invented cryptography
All cryptographic operations use standard-library primitives or well-maintained, widely reviewed libraries. Nothing hand-rolled — no custom signing scheme, key derivation, or bespoke authentication token.
Security model
A management plane that touches every host in an estate is a high-value target. These are the principles Vitrinode is built against. Where a principle is a current design goal rather than shipped behaviour, it's labelled as such below.
On this page: Principles·What this isn't
Client-generated device identity
A device's long-term private key is generated on the device itself during provisioning and never transmitted. The control plane signs certificates from submitted CSRs; it never holds or sees device private key material.
Separate keys for separate roles
The server TLS identity, device certificate authority and job-signing role use separate key material. SSH certificate issuance is planned to use its own independent key too, held on a dedicated hardware device (Vitrinode-HSM) rather than on the server; that role does not exist in the shipped product yet.
Mutual TLS, checked continuously
A successful TLS handshake proves a certificate chains to Vitrinode's own certificate authority — it doesn't prove that specific certificate or device hasn't since been revoked. Revocation and device trust state are checked against every authenticated request, not assumed from the handshake alone.
Passwordless human authentication
Administrators authenticate with WebAuthn/FIDO2 only. There is no password path in normal operation, and an account can register more than one hardware key so a single lost key isn't a lockout.
Step-up for sensitive actions
Sensitive actions require a recently-completed FIDO ceremony, and that check is enforced server-side — a client claiming to be "recently authenticated" is never trusted on its own. An unrestricted shell, root SSH issuance, agent replacement, and device revocation/rotation are all treated as step-up-gated by design; device revocation and attestation re-baselining are wired to it so far.
Authentication is not attestation
A valid device certificate proves which enrolled device is talking, not that it's currently in a trustworthy runtime state. The design keeps those separate, and this is now implemented: where a hardware TPM is available, attestation means a genuine vTPM quote over PCR state; hosts without one get an explicitly weaker software-evidence check that is never presented the same way. The result is held as a device trust state, and a stale or failed attestation degrades it.
Hardware custody for the SSH CA keyprototype
The SSH certificate authority key is the one secret whose compromise would let an attacker mint access to every host. It is being built to live on a dedicated device (Vitrinode-HSM) that generates it on-board and never exports it, and that only issues OpenSSH user certificates inside a fixed policy — there is no raw signing operation and no PKCS#11 interface to misuse, and certificate lifetimes are bounded by the device's own clock. So far the security boundary and the certificate path are verified on real silicon issuing genuine OpenSSH certificates; the key is still regenerated on every boot and the device is not yet connected to a server.
Least privilege by process
The network-facing agent runs unprivileged. Operations needing elevated local rights are dispatched to a separate, narrowly-scoped executor over a permission-checked Unix socket with a fixed, typed operation set — so compromising the network-facing process doesn't, by itself, grant arbitrary root execution.
No arbitrary shell as the base protocol
Remote operations are a typed, validated set — never free-form shell text. Jobs are signed by the control plane, expire, carry a nonce for replay protection and produce an audit trail. A break-glass shell capability, if one is ever added, would be separately gated, heavily audited and step-up protected.
Authentication and current administrative actions are audited
Registration, login, logout, step-up, credential addition, device revocation and the remote-job lifecycle write insert-only audit records. This is application-level append-only behaviour, not tamper-proof storage; future security-sensitive operations must add their own audit events as they are implemented.
Limit control-plane blast radiusdesign goal
Separate keys, per-request revocation checks, signed typed jobs and agent-side privilege separation are implemented. These controls narrow what compromised components can do, but do not make the control plane or managed hosts immune to compromise.
What this isn't
Vitrinode has not undergone a third-party penetration test or a formal compliance audit, and holds no certifications. A dedicated hardware signing device (Vitrinode-HSM) is in active prototype development — it is not part of the deployed system, and the SSH certificate authority it is built to protect is itself still on the roadmap. If any of that changes, this page will say so specifically.