Zero-Knowledge for Teams

Rolling zero-knowledge custody out to a team is a ceremony between two people, and the steps only work in one order. This page is the team side; Zero-knowledge custody covers setting it up for yourself.

What a team key is for

Without a team key, content can be reopened from the app only by whoever created it — a colleague's encrypted share is opaque to everyone else in the app, including the team's owner. (Anyone holding the link can still open it; the link carries the key.) A team key changes that: team content is wrapped to a single keypair for the whole team, so access is granted once per member instead of once per item, and adding or removing a member never re-encrypts anything.

The team key is generated in an admin's browser. CredenShare never holds it, which is why every step below has to be performed by a person rather than by us.

Zero-knowledge custody requires the zero_knowledge entitlement, which is on Business and Enterprise only. The panel resolves that from the team's subscription, not from the admin's personal one — so a team on Business gives its admins the feature even if they hold no plan of their own. A seat member with no subscription can set up a passphrase for the same reason: the seat carries the entitlement.

Where it lives

My Teams → the team → the Zero-knowledge for this team panel at the foot of the team page. The heading carries an On or Off badge.

Every member sees the panel. Only an owner or admin sees the controls. While the team key is off, a member who is not an admin reads "Only a team admin or owner can enable this." where the button would be — unless they have no passphrase of their own, in which case the passphrase notice takes that spot instead. Once the team key is on, a plain member sees no controls at all.

The order

1. The admin sets up their own passphrase. In Account → Security. A team key can only be created and handed out by someone who holds their own key. Skip this and the panel replies "You need your own encryption passphrase first — set it up in Account → Security." and offers no button.
2. The admin turns it on for the team. Enable for this team, on a device that is activated — the admin's own grant is created in the same request, and a team key nobody holds could never be granted from. If the device is locked, the Activate this device dialog opens first; activating reloads the panel rather than resuming the action, so press the button again afterwards. On success: "Zero-knowledge enabled for this team".
3. Each member sets up their own passphrase. Until a member does, they sit in the panel under Waiting for the member, annotated "needs to set up their passphrase", with no button beside them. That is not a fault to report; it is the queue saying whose move it is.
4. The admin grants each member access. Members who have enrolled move to Waiting for you to grant access, each with a Grant access button. Granting means unwrapping the team key, so it also requires an activated device — otherwise the panel shows "Activate this device to grant access — granting requires the team key, which only your own passphrase can unlock." Activating from there reloads the panel, so press Grant access again.

Once everyone is through, the panel reads "Every member has access."

Between steps 2 and 4, members can see that team items exist but cannot open them. They get the notice "A team admin has not granted you access to this team's encrypted content yet. You can see that items exist but cannot open them until they do." That is expected, and only an admin can clear it.

An invitation that has not been accepted cannot be granted. Membership has to be confirmed first.

What counts as team content

A share, paste or secure request is team content when it was created while that team was selected in the team switcher. Personal-context items are never wrapped to a team key, whoever created them.

Three conditions all have to hold at creation time for a team wrap to exist:

• the team key was enabled;
• the item was created in the team's context;
• the creator had their own passphrase set up, on a plan that included custody.

If any one of them was false, no team wrap was written, and nothing done afterwards goes back and fills it in.

Enabling is forward-only

Turning the team key on wraps new team content only. Everything created before is untouched and keeps working exactly as it did.

Turning it off is the mirror image and destroys nothing: "Existing team content still opens. New content will not be added to the team key." The keypair stays in place, every existing wrap keeps being served, and members keep their grants. Turning it back on resumes wrapping new content, and nobody needs re-granting.

Enabling is refused on a plan without the entitlement — "Zero-knowledge custody requires a Business or Enterprise plan". Turning it off is deliberately not gated, so a team whose plan has lapsed is never trapped with a switch it cannot flip. Enabling a team that already has a key gives "Zero-knowledge is already enabled for this team"; acting on a team that has none gives "Zero-knowledge is not enabled for this team".

Granting and revoking

Grants are per member, listed under Has access, each with a Revoke button. Revoking needs no activated device — it deletes a stored wrap rather than producing one.

Removing someone from the team has the same practical effect without touching their grant: every team-key endpoint checks confirmed membership first, so once they are out we will not serve them the team key at all. Their grant row survives, which means re-adding them later restores access with no second ceremony. If you want the grant itself gone, revoke it before removing them.

Resetting a team key

Reset this team's key exists for one situation: an admin created a new encryption key without their old passphrase, so the wrap that gave them the team key was addressed to an account key they no longer hold. The panel names that state — "This team's key can no longer be opened with your account key" — and offers the reset only to an owner or admin, because a member's answer is to ask for a re-grant instead.

Personal copies survive a reset. Each member's own items still carry a wrap to their own account key, and links already sent to recipients keep working, because their key travels in the link rather than through the team.

What the organisation can and cannot recover

The question this usually comes down to: someone has left — can we retrieve a credential they shared?

Sometimes. An owner or admin holding a team-key grant can rebuild the link for a departed member's team share, from the Shares list in that team's context. Admins and owners see every member's shares and secure requests for the team; a plain member is scoped to their own regardless of what they ask for. What decides it is whether a team wrap was written when the item was created.

Two practical notes for an offboarding run:

• Rebuild a colleague's link from the Shares list. That page's copy and QR actions pass the team context, which is what makes the team wrap usable; the dashboard's Recent Shares card and the share Info dialog resolve only your own account's copy of the key.
• Do the recovery before you reset anything. A reset performed to rescue a stranded admin also destroys the team's route into everything the departing employee left behind.

Submissions to a secure request follow the same rule. A request created in the team context carries a team wrap, so an admin can open its submissions; one created personally can be opened only by its owner, or by whoever holds the owner's access link.

When it does not behave

Related: Zero-knowledge custody for passphrases, device activation and what each way of replacing a key costs, and Encryption for what is encrypted where. If something here does not match what you see, write to support@credenshare.io.