Every small team has logins that belong to the company rather than to a person: the ad platform, the domain registrar, the client’s CMS, the router in the office. Somebody has to share them. The question is not whether to share but how, and most teams answer it with a pinned chat message or a spreadsheet called passwords-final-v2. This guide is the alternative.
Why chat and spreadsheets fail
A password in a chat thread is readable by everyone who was ever in the channel, is indexed by the chat provider’s search, and outlives the person who pasted it. A spreadsheet is worse: it is copied to laptops, attached to emails, and has no idea who opened it. Neither can answer the two questions that matter after an incident — who could see this and who did.
There is also the founder problem. In many companies the "shared" credentials live in one person’s personal password manager, which works until that person is on a flight and the payment provider needs re-authorising.
What zero-knowledge actually means
A zero-knowledge vault encrypts every item on your device, before it is sent, using a key derived from a passphrase the server never receives. The server stores ciphertext. If the server is breached, the attacker gets random-looking bytes; if the vendor is subpoenaed, the vendor cannot read your data either. Decryption happens in your browser, when you unlock the vault.
Sharing in a zero-knowledge system is therefore not "give the server permission to show it to Bob". It is "encrypt this item for Bob’s key as well as mine". Bob can decrypt it, the server still cannot, and unsharing means re-encrypting without Bob’s key. This is more work for the software and far less trust required of the vendor.
Recovery without a back door
The honest weakness of zero-knowledge is the forgotten passphrase. If nobody can decrypt your vault but you, and you forget the passphrase, the vault is gone. For a personal vault that is an acceptable trade. For a company vault it is not — a leaver or a lost laptop must not take the client credentials with it.
The answer is escrow: when a member sets up their vault, a recovery key is encrypted for the organisation’s administrators and stored alongside. An admin can reset a member’s vault access without ever seeing the member’s passphrase, and the action is recorded. The vendor still holds only ciphertext; the ability to recover stays inside your organisation, with the people you already trust to run it.
What the audit log must record
- Every read, not just every change. The value of a log after an incident is knowing who saw the credential, and most tools only record edits.
- Sharing events: who granted whom access to which item, and when it was revoked.
- Recovery events: every admin reset of a member’s vault, because that is the most powerful action in the system.
- Who, not what: the log names people and items, never the secret itself.
A sharing model that matches how teams work
Individual sharing scales badly: a client with fifteen credentials and an account team of four is sixty share decisions. Group the items into a collection per client or per system, and share the collection with named teammates. When a new account manager joins the client, one share gives them everything they need; when the client leaves, one unshare removes it. Keep folders inside a collection for structure, not for access.
This is how Orbiz Vault is designed: client-side encryption, collections and folders, sharing with named teammates, escrow-based recovery run by your own admins, and an audit log of every read and change. It sits behind the same login as the rest of the platform, so removing someone from the organisation revokes their vault access in the same action — one of the hidden costs we count in the hidden cost of eight SaaS subscriptions.
Rules for the team, not just the tool
- Every shared login goes in the vault the day it is created. If it is in chat, it is not shared — it is leaked slowly.
- One collection per client or system. Share collections, not items.
- Use the audit log at offboarding: read what the leaver accessed in their last month and rotate anything sensitive.
- Rotate a credential when the set of people who can read it changes, not on a calendar.
- Enrol an administrator in escrow before anyone needs it, and write down who holds the recovery key: today one administrator is the holder, so plan for their absence.
Agencies juggling a dozen client ad and social accounts and software teams holding server and API keys are the two groups that tell us this changed how they work — mostly because the audit log ended the "who changed the password?" thread for good.
Built for your industry
