KeyvaciBlog · Fundamentals · 16 August 2026
Team credential vault: how shared secrets should actually work
Personal password managers solved remembering. Shared company credentials are a different problem: several people need the same secret, with different rights, and the set of people keeps changing. Here is what the mechanics should look like when they are done honestly.
Why sharing breaks the personal-manager model
A personal manager has one owner, one master password, one device set. A team credential vault has to answer questions a personal tool never faces: how does a secret reach a colleague without the server being able to read it in transit or at rest? How do you prove the recipient is really your colleague and not an attacker who slipped a public key into the directory? What happens to the secret when someone leaves? Copy-pasting from a personal vault into chat answers none of these, which is how most teams actually operate today.
The mechanics, step by step
1. Each vault has its own key
Entries in a vault, including the vault's name, are encrypted with a key that exists only on members' devices. In Keyvaci that is XChaCha20-Poly1305 with keys ultimately derived from each member's master password through Argon2id, entirely in the browser.
2. Sharing is public-key cryptography, not a database row
Granting access encrypts the vault key for the recipient's public key. The server relays ciphertext; it cannot open what it relays.
3. Identity is countersigned by a human
The dangerous moment in any sharing system is trusting a public key. Keyvaci requires an administrator to verify each member's key fingerprint over a separate channel and countersign it with the organisation signing key. Devices check that signature before any share. An attacker now has to fool a person, out of band, not a lookup table.
4. Roles are enforced twice
Reader, writer, and admin roles are checked by the server and reflected in what cryptographic material each member actually holds. The database being wrong is not enough to leak a secret.
5. Revocation re-encrypts
Removing someone rotates the vault key and re-encrypts every entry on your device. What their laptop remembers stops mattering. This is the property to demand in any product you evaluate; the details are in our offboarding guide.
What the server should know
Almost nothing: who is in the organisation, which vaults exist, who holds a grant to each, and an append-only log of security events. Names of vaults, contents of entries, and every key stay ciphertext. We publish the exact inventory on the security page, because a team vault that cannot show you this table is asking for trust it has not earned.
Try a vault built on these mechanics
14 days, every feature, no credit card. Sign in with company SSO or a plain email address.