Shared Vaults: How Family Sharing Actually Works
Shared vaults are usually explained with the reassuring version: everyone in the family gets the same passwords, and if you forget something, someone else can get it for you. That is true, and it leaves out the part where the shared vault is also the place where a compromised family member account becomes a route into everything else. This guide covers what the sharing feature actually does, what the recovery and emergency-access mechanisms are for, and how to set sharing up so that losing one person does not mean losing access.
Table of contents
- The two models of sharing
- Recovery versus emergency access
- How a grant actually works
- Scope: what a shared member can reach
- Setting up sharing without creating a single point of failure
- Revoking, and what revocation does not undo
- FAQ
- Bottom line
The two models of sharing
Password managers offer sharing in one of two fundamentally different ways, and the difference is not cosmetic.
Shared vault. A container that several people can access, usually with per-person permissions. Everyone in it can see the items the permissions allow. The advantage is convenience: the family plan, the shared login for a streaming account, the set of recovery codes for a domain. The cost is that the boundary is the container, so a container that accumulates a hundred shared items across six people is a container where every member can read a hundred things.
Item-level sharing. A single item is shared with a named person, without opening the rest of the vault to them. This is the more granular model and the one that scales: sharing one recovery code does not require sharing the vault it lives in.
Which one a provider supports, and whether it supports sharing to people who are not account holders, varies. [VERIFY the current sharing model for any provider you are considering, including whether external recipients are supported at all.]
Recovery versus emergency access
Two features that are frequently confused solve different problems, and confusing them produces bad setups.
Recovery is about restoring your own access. You set a method — a recovery kit, a recovery code, a trusted device, a designated contact — so that if you lose your master password, access can be restored. The key property is that recovery works when you are unavailable, and it is therefore designed to bypass the normal lock.
Emergency access is about someone else getting in when you cannot. You nominate a person and set a waiting period. If you do not cancel the request within that period, the nominated person is granted access. The waiting period is the whole design: it exists so that the feature cannot be used against you while you are present and unable to object.
The practical difference shows up in failure. If you lose your master password, recovery restores you alone. If you are incapacitated, emergency access lets the nominated person in — and because the waiting period has elapsed, it does so without your participation. Setting up recovery and assuming it covers the emergency case is a common and consequential mistake.
How a grant actually works
Emergency access in most implementations follows a recognisable sequence, and the details are worth knowing because they determine what a request can and cannot do.
- You nominate a contact and choose a waiting period. The contact usually has to accept, so the arrangement requires two people to act.
- You trigger a request, or the provider's monitoring triggers one after a period of inactivity.
- The request opens a countdown of the waiting period. During it, you can cancel.
- If it is not cancelled, the contact gains access to the vault — sometimes immediately, sometimes after they set up their own credentials.
- Access granted this way is ordinarily permanent until it is revoked.
Two details vary and are worth checking: whether the waiting period can be shortened after the fact, and whether the granted access is to the whole vault or to a subset. A provider that lets the nominee choose which items they take, rather than receiving everything, is meaningfully safer to nominate someone in.
Scope: what a shared member can reach
Before sharing anything, it is worth being precise about what the other person will actually be able to do, because the answer varies more than the interface suggests.
- Read, or read and edit. Some setups let a member see an item without being able to change it, which matters if the item is a credential you might need to rotate.
- Edit without seeing the current value. A shared member can be permitted to update an entry without ever seeing the password itself, which is the right shape for a shared account where one person is the operator and another is the owner.
- Export rights. The question that matters most: can that member export the whole vault, or just the shared items? An export permission on a shared vault can turn a convenience feature into a leak channel.
- Revocation speed. If you remove a member, what happens to anything they had already seen? Nothing can un-see a password, but the ability to keep working with it should end.
Setting up sharing without creating a single point of failure
A shared vault that everyone relies on, with no second route in, is a single point of failure with extra steps. A workable arrangement has redundancy built in deliberately.
- Use item-level sharing where you can. Sharing one item is safer than sharing a container, and the work saved compounds across a family.
- Nominate more than one emergency contact if the provider allows it. Two people who can both respond means one person's absence or loss of access does not close the route.
- Keep an offline recovery method somewhere physically secure. A printed recovery kit in a safe, or sealed with the documents it relates to, is the one route that survives a dead phone and a locked account.
- Separate the shared account from the shared secrets. A streaming service shared by a household is one item. The login for the email address that receives the password-reset message for everything else is a different category, and it should not sit in the same place.
- Review who is in it every few months. People leave households and families. Shared access has no natural expiry, so it needs a scheduled review rather than an event-driven one.
Revoking, and what revocation does not undo
Removing a member is straightforward. What it does not do is take back what they already had. A password they had seen, a recovery code they had copied, a session they had already authenticated, all of that knowledge persists outside the system. This is not a flaw in the product; it is how knowledge works.
What revocation does handle is the live access: active sessions end, the ability to view or edit shared items ends, and the account can no longer authenticate. That is why revocation pairs with rotation. If a credential was shared with someone who should no longer have it, changing the credential is the part that actually removes the risk. The framework in choosing a password manager covers how to think about where each credential should live.
FAQ
Is a shared vault safer than sharing passwords over a chat app?
Considerably, and for reasons beyond encryption. A chat message is a permanent copy in a conversation that may be forwarded, exported or backed up. A vault share is revocable, auditable and carries no copy of the secret itself — the shared member sees the item through the provider's access control rather than holding a string they were sent.
What happens to the shared items if I stop paying for the family plan?
It varies and it is worth checking before you rely on it. Some providers keep shared access working for members who were part of the plan, some downgrade it, and some remove it. [VERIFY the current behaviour with your provider, and check it before a billing cycle rather than after.]
Should I use the same emergency contact for everything?
There is a case for one trusted contact and a case for separating by vault. A single contact across all vaults means one person's account compromise reaches everything, and one nominated person is a single point of failure for access. Splitting by vault limits both blast radius and dependency, at the cost of asking someone to hold several arrangements.
Does sharing weaken the encryption?
The underlying encryption model is unchanged — your master password still decrypts the vault, and that is what the emergency contact's access ultimately rests on. What sharing adds is an access path around the master password, with a waiting period on it. That path is the thing to understand and configure, rather than a change in how the data is encrypted at rest.
Bottom line
Shared vaults work well for the thing people actually want them for: a few household credentials that more than one adult needs, and a route back into the account if something goes wrong. They work badly when they become the place everything lives. Prefer item-level sharing over container sharing, keep a physical recovery method that does not depend on any account, nominate emergency access deliberately rather than reflexively, and give a shared member the narrowest permissions that still let them do the job. And treat revocation as the start of a cleanup rather than the end of it: rotate anything that was shared and should no longer be.
If you have decided which features you need and want to compare current pricing, the link below goes to our own page for the category.