Security & recovery

Encryption happens in the client

The app encrypts record contents, custom fields, and group names before saving or syncing them. Each resource has its own random encryption key. Group keys protect inheriting resource keys; independent roots and restricted groups form separate boundaries.

A random master key protects your identity bundle and local keys. The current Windows native library uses Argon2id for password-based key derivation, XChaCha20-Poly1305 for authenticated encryption, Ed25519 signatures, and X25519-based encrypted sharing offers. The local password-derived protection also uses a device-held account secret.

Your master password, master key, recovery key, and plaintext vault contents are not sent to the server. The server still sees operational metadata such as identities, membership, permissions, resource relationships, ciphertext sizes, and timing.

Authentication is a separate layer

Server enrollment and sign-in use signed device proofs and MFA. Your master password unlocks the identity locally; it is not submitted as a server login password. Each organization has its own device approval and short-lived session.

Windows Hello can unlock the local identity and can be enrolled separately for each organization. Windows controls the offered verification method, which may be biometrics or a PIN. The current system does not promise biometric-only use or remotely attest that every device has TPM protection.

Keep the right recovery materials

Material	What it is for
Encrypted backup + separate recovery key	Restore the saved identity and personal snapshot. Preserve both, in separate places.
Server MFA recovery codes	Emergency server/control sign-in. They do not decrypt a vault or replace ordinary organization unlock.
Accepted organization recovery custody	Let authorized custodians recover and rotate covered organization resources. Provision and test this before an incident.

Organization contents are not included in personal identity backups. Changing a master password does not invalidate old backups or erase access through the recovery key. Local Windows Hello enrollment stays on the device and must be set up again after identity recovery.

What a compromised server can still do

Client encryption keeps stored password contents unreadable to a server that lacks the client keys. It does not prevent denial of service, deletion, metadata exposure, or every replay of valid old state.

Clients verify signed access history and pin evidence they have seen. A fresh or disconnected device cannot yet independently prove that the server supplied the globally newest history. Existing ordinary revocations also lack complete ordered-journal coverage. These are documented release limitations, not solved by transport encryption.

What a compromised client can do

Passwords must be plaintext in memory while you use them. Malware controlling an unlocked client can read that data. Clipboard history, screenshots, exported data, and copies held by an authorized recipient cannot be remotely erased.

Key rotation protects new encrypted versions after access changes. It cannot invalidate an already copied website password or API token: replace the actual credential at its source. Administrative recovery also needs an eligible unlocked client and trustworthy usable source keys.

The implementation is a development release, not independently audited software. Review the current release limits before relying on it for sensitive credentials.