Jump OS is built so the platform operator cannot casually see your secrets.
The security model assumes infrastructure can fail. Vault encryption, key derivation, and device verification are designed so sensitive data remains protected even when the server is not trusted with plaintext.
End-to-end encrypted vault
Sensitive vault data is encrypted on device before it leaves the client. Connection details, credentials, private keys, snippets, and related vault content are stored as ciphertext on the server.
Jump OS uses XChaCha20-Poly1305 for authenticated encryption. The goal is straightforward: if our infrastructure is compromised, the attacker still does not get readable vault contents.
Zero-knowledge sync layer
The server stores encrypted payloads, device identities, and sync metadata. It does not have the keys needed to decrypt vault contents.
Account login and vault encryption are intentionally separate concerns. Your account authenticates you to the platform. Your vault passphrase derives the keys that unlock the vault locally.
Modern key derivation
Vault keys are derived with Argon2id using memory-hard parameters so offline guessing is materially more expensive than with older password-based derivation approaches.
A unique salt is stored per vault. Rotating passphrases re-derives key material without weakening the encryption model.
Device verification and revocation
Each device has its own key material. New devices are verified from an existing trusted device, and revoked devices can be removed without trusting them to behave after removal.
This lets operators control which surfaces can participate in sync and session continuity while keeping the trust boundary explicit.
- Vault items and secrets are encrypted before sync.
- Device authorization is explicit and revocable.
- Session control and approvals stay part of the platform model.
If you find a vulnerability, contact the security team directly. We prefer responsible disclosure and aim to respond quickly.