Administer an organization

Keep administration and vault access separate

After unlocking an organization, open its administration area. Owners control protected policies, ownership, recovery provisioning, and restoration. Administrators handle routine management and permitted containment. Server administrators manage the installation. None of these roles supplies a vault decryption key.

Security changes require a fresh authenticator code. You can enable a two-owner policy for sensitive operations such as recovery provisioning, owner promotion, restoration, and protected policy changes. A different active owner approves the exact proposal before it is executed.

Know who you are sharing with

Use Members to search names, usernames, or full Identity IDs; filter by role, verification, status, team, and recorded activity. Organization usernames and display names are unique within that organization. Changing a local display name does not replace an established organization name.

An owner can compare a person's Identity ID through a trusted channel, approve their organization names, and lock them. The green verified badge indicates this owner-approved identity/name binding. It does not certify the person's device. An optional policy limits new shares and pending acceptances to verified members.

Inspect and review access

The access explorer answers both “What can this member access?” and “Who can access this resource?” It distinguishes direct, inherited, pending, historical, and recovery paths. Names appear when your client can already decrypt them; otherwise it shows resource IDs.

• Teams: organize members independently of the folder hierarchy. Adding a person to a team does not silently create their encrypted key access.
• Permission templates: reuse a deliberate set of record or group rights.
• Temporary access: set expiry and justification. Expiry blocks new authorized operations and schedules necessary rotation; it cannot retract copied data.
• Access reviews: assign reviewers to a snapshot, record retain/revoke decisions, and resolve required revocations and rotations before closing.

Prepare recovery before an incident

1. Open Recovery and provision independent trusted custodians for each root or restricted boundary that needs coverage.
2. Have each custodian accept the encrypted recovery offer in their own unlocked client.
3. Run the local decryption readiness check. Configured, accepted, and actually usable coverage are different states.
4. Aim for at least two independent approved custodians and review coverage when people or devices leave.

Recovery custody permits reading and recovery for its covered data. It is a real secret-access privilege, not just an administrative contact. Initial recovery rights do not automatically include normal editing or sharing. After a proven takeover, an owner can explicitly restore resource ownership to that current custodian under the approval policy.

Respond to a compromised account

1. Suspend the member in the affected organization. Containment ends scoped sessions, disables organization device approvals, and revokes applicable access. Use device and session controls for narrower incidents.
2. Inspect the incident's captured exposure and rotation tasks. An eligible unlocked client with usable trusted keys processes the encrypted key changes and resumes interrupted work.
3. Track replacement of the actual website passwords, database credentials, tokens, or keys separately. Vault-key rotation does not replace them.
4. Resolve blocked recovery items and credential tasks before closing the incident. Restoration is explicit and does not revive old grants or device approvals.

If all eligible custodians are offline, encryption work waits. If usable custody or authentic source revisions are unavailable, items stay blocked rather than trusting arbitrary server data.

Use audit reports accurately

Filter and export metadata reports for administrative changes, access decisions, incidents, and server-observed activity. These reports contain no password values. A server observation is not proof of every offline view, and a compromised server can suppress unseen events.

Read Security & recovery for the protections and limits behind these administrative workflows.