Organization vaults & policies

Organization vaults are shared vaults that stay with the company when the person who made them leaves. Each vault has its own data encryption key (DEK); sharing a vault re-wraps that DEK for each recipient using their RSA public key, so the server never sees a secret in plaintext or a raw key. Admins govern all of this from Organization → Vault governance → Organization vaults and Organization → Vault governance → Sharing policies.

"Organization vault" does not mean the organization can open it#

This is the single most important thing on this page, and it surprises almost everyone.

PulsVault holds no organization key. There is no master key for your company, none on our servers, and none we could give you. A vault key is wrapped for one person at a time, and being an administrator does not conjure one — if you are not a custodian of a vault, you can see that it exists, see who is responsible for it, and read nothing inside it.

So what makes a vault organizational is not a key. It is a guaranteed set of people:

Every organization vault has at least two custodians — real members who each hold a copy of its key. That is what lets the vault survive one of them leaving.

A second holder, never a second copy on a server. It is the same shape as every other recovery path in the product.

Custodians#

Rule	Why
At least two, always	One holder is a vault that leaves when they do — the exact problem this solves
Both are chosen when the vault is created	Creating it first and adding the second later leaves a window where it has one holder
A custodian cannot be removed below the minimum	The removal is refused and names the number
A custodian's access is changed only from the custodian list	Editing it as an ordinary share would let the person who created the vault demote or remove the company's own key holder
Ownership can only pass to a custodian	Handing a vault to somebody with no key produces a vault nobody can open
Removing a member who is a last custodian is blocked	Everything else about offboarding can be undone later; this cannot

Who is on the roster#

Custodianship is the business:vault:custodian permission, granted to one person at a time and never through a role. That is deliberate: a custodian holds a key to every vault your members create from then on, so it should be a decision somebody made, not something that arrives with a promotion.

The organization's owner is granted it when the organization is created. They are on the roster because of that grant and not because they are the owner — so you can see it in the access report, and you can move it to somebody else.

It used to be neither. The owner was on every roster automatically, by virtue of being the owner: standing access to every credential in the company that appeared in no list and that no screen could take away. Making it a grant changes nothing about who holds what today, and makes it something you can look at and change.

A custodian can add people to the vault#

A custodian holds the vault's key, and can add other members to it — subject to your organization's Allow Re-Sharing policy, which still applies. If you do not want key holders staffing vaults, that switch is where to say so.

This follows from what a custodian already is. They can open the vault and copy anything in it, so stopping them from sharing it would not keep the contents in fewer hands — it would only move the copying somewhere your audit trail cannot see. A share is recorded; a copy-paste is not.

Custodian access is not an ordinary share#

A custodian appears in the vault's member list marked Custodian, and their row is read-only — no access-level dropdown, no remove button. The server refuses both actions, so the screen does not offer them.

That is not a technicality. A custodian's copy of the key is what lets the vault survive the person who made it leaving — and the person who made it is the vault's owner, who would otherwise be able to demote or remove the company's key holder. One click before resigning, and the company is locked out of its own vault with nobody able to restore it.

Remove a custodian from the custodians list instead. That path checks that enough key holders remain, refuses if it would take the vault below its minimum, and tells you a key rotation is owed.

Transferring ownership takes two steps#

An owner's copy of the key is wrapped under their own master key; a custodian's copy is wrapped under their public key. They are not interchangeable, so an administrator cannot simply hand ownership to somebody:

1. An owner or admin offers ownership to a custodian. No key moves.
2. That person claims it from their own device, which is the only place the new key copy can be made.

When they claim it they choose whether the outgoing owner stays a custodian. If not, the vault is flagged for a key rotation — the outgoing owner has held the key, so a rotation is owed whatever the paperwork says, and only somebody holding the key can perform one.

The Organization vaults screen#

Organization → Vault governance → Organization vaults lists every organization vault and who is responsible for it. Anyone with permission to manage organization settings can open it; what you can do on it depends on your subscription and on whether you are a custodian.

At the top, New organisation vault creates one. It is hidden — not greyed out — when your subscription is read-only, because the create would be refused. If you can read reports, a Who can reach these button opens the access report: this screen says who holds a key, the access report says who can reach a vault by every path, and the two answer different questions.

Create an organization vault#

1. Select New organisation vault.
2. Enter a Name, and optionally a Description.
3. Choose a Second custodian from your colleagues. You are the first. The vault cannot be created without a second, because a vault with one holder is the problem this feature exists to prevent.
4. Read the warning under the picker: your colleague receives a copy of the vault's key, which means full access to everything in it, and they can be made its owner later.
5. Select Create vault.

The table#

Column	Shows
Vault	Name and description
Owner	The owner's email, with (you) if it is you
Custodians	How many custodians the vault has, against its minimum ("/ min 2"). At or below the minimum the count turns amber and the row says At the minimum — nobody here can be removed
Status	Badges, below
Actions	History, Custodians, and Cancel transfer when an ownership offer is waiting

Status badges:

Badge	Meaning
Key rotation owed	Someone who held the vault's key has left it (an outgoing owner, say), so the key should be replaced. Only the vault's owner can do that
Awaiting and an email address	An ownership offer has been made to that custodian and they have not yet claimed it
You cannot open this	You are not a custodian of the vault. You can see it exists and who is responsible for it, and nothing inside
—	Nothing needs attention

History appears only if you can read the audit trail; it opens the sharing activity report filtered to that vault. The list is paged.

The custodians panel#

Select Custodians on a row. The panel lists each custodian with Custodian since and their date; the owner is marked Owner, and you are marked (you).

• Offer ownership appears next to each custodian other than the current owner, when you are a custodian yourself and no offer is already waiting. It starts the two-step transfer. Cancel a waiting offer with Cancel ownership offer in the panel footer, or Cancel transfer in the table.
• Remove appears only while the vault has more custodians than its minimum, and never for the owner. At the minimum the panel says that none of them can be removed. This panel only offers removal and ownership offers; who is eligible to hold a key is decided by the custodian roster.
• If you are not a custodian, the panel says you hold no copy of the key and cannot give one to anybody else — ask one of the people listed. That is a limit of cryptography, not of permission.
• If your subscription is read-only, custodians can be viewed but not changed.

The organization circle#

Team, Business, and Enterprise plans form a strict organization circle: by default, no vault or item can be shared with anyone outside the organization. A member's primary vault is never shareable on any plan — sensitive personal data can't leak through a misconfigured share, and for the same reason a primary vault can never become an organization vault.

You can also require that shared credentials live in organization vaults, under Organization → Security policies → Access control. That switch makes each member's personal vault read-only, so new credentials go into organization vaults instead. It does not reach vaults they own outside your organization — you hold no key to those. See Access control.

Sharing policies#

Configure under Organization → Vault governance → Sharing policies (the page is titled Vault Sharing Policies):

Policy	What it does
Allow Vault Sharing	Master switch — if off, members cannot share vaults at all
Allow External Sharing	Permit sharing with users outside the organization (off by default)
Allow Re-Sharing	Let members grant re-sharing permission when they share
Allow Secure Links (Psst!)	Let members generate time-limited, view-only links for items
Require Admin Approval	Route every new share through the approval queue
Default Access Level	Access level pre-selected for new shares (Viewer by default)
Max Members Per Vault	Cap how many people one vault can be shared with
Enforce Share Expiry	Force every share to carry an expiration date
Default Expiry Duration (Days)	Days until an enforced share expires (e.g. 30)
Minimum custodians per vault	How many people must hold each organization vault's key. Cannot go below 2 — a lower number is clamped, not rejected
Approve external shares of organisation vaults	Narrower than Require Admin Approval: only sharing an organization vault outside the organization

Turning off Allow Vault Sharing disables the dependent controls; the other switches only apply while sharing is enabled. Policies are enforced by the server on every share request — a member whose share violates policy receives a clear rejection.

Holding the key is not the same as rotating it#

Minimum custodians per vault says at least two people can open the vault. It does not mean two people can do everything to it, and the difference matters when somebody leaves:

	Who	Set by
Open the vault	At least two custodians	The custodian list
Rotate its key	Only the vault's owner	Nothing — it cannot be granted

There is no "rotate keys" permission to give somebody, and that is not an omission. The vault's key is stored wrapped under its owner's master key, while a custodian's copy is wrapped under their public key. Only the owner can produce the owner's wrap, so only the owner can re-key the vault.

What to do about it: if the owner is leaving, transfer the vault's ownership to a custodian before they go — see Transferring ownership takes two steps. Otherwise the vault keeps working and stays readable by its custodians, but nobody can rotate its key until ownership moves.

Access levels#

Each share carries an access level; the vault creator is always the implicit Owner:

Level	Grants
Manager	Modify vault settings, add/remove members (cannot delete the vault)
Editor	Create, edit, and delete items in the vault
Viewer	Read items and copy passwords, no modifications
Limited	Autofill only — plaintext passwords stay hidden

See Access levels for the member-facing view.

How to update sharing policies#

1. Go to Organization → Vault governance → Sharing policies.
2. Toggle the capabilities you want to allow under Global Sharing Capabilities.
3. Set limits under Governance & Limits — approval, default access level, member cap, expiry.
4. Click Save Policies. Changes apply to new share requests immediately.

Related#

• Sharing overview — how members experience these policies
• Approval queue — reviewing shares that need sign-off
• Encryption policies — algorithms organization vaults may use
• Vault encryption — why no organization key exists