Skip to content

Sharing Keys Across Organizations

Sharing a device with an organization makes its public key visible inside that org’s vault builder. Other members of the org can then select your device when constructing a multisig vault. The device — and the private key on it — never leaves your possession.

This is the mechanism that lets Sigvault build vaults from keys belonging to people across multiple organizations and households.

What “sharing a device” actually means

Section titled “What “sharing a device” actually means”

A device share is a small relationship in the database: “User X has made Device Y visible to Organization Z.” That’s it. Specifically:

  • Sigvault stores only the public key of the device (the extended public key, or xpub). The private key never leaves the hardware wallet — sharing the device does not change that.
  • You retain ownership of the device. You can rename it, unregister it, or revoke the share at any time.
  • The org gets visibility, not control. Members of the org can propose using your device in a vault — but a vault is never created with your key without your explicit per-vault consent.
  • Signing always requires the device. Even after the vault exists, your physical device must be present and approve every transaction it participates in.

For background on how Sigvault treats device-held keys in general, see User Managed Keys.

You must be a member of the org you’re sharing into, and you must own (be the registered user of) the device you’re sharing.

  1. Open the organization from Organizations → (your org).
  2. Go to Settings → Device Shares.
  3. Click Share device and pick one of your registered devices from the list.
  4. Confirm.

The device immediately appears in the org’s device pool. Other members with wallet:create permission can now select it when building a multisig vault.

You can share the same device with multiple organizations simultaneously. Each share is independent — revoking one doesn’t affect the others.

Because any member of an org can share any of their personal devices into that org, vaults can naturally span organizational boundaries:

  • Alice belongs to Org A (her company) and shares her BitBox02 there.
  • Bob belongs to Org A and Org B (his consultancy). He shares his Coldcard with Org A and his Ledger with Org B.
  • Carol belongs to Org B and shares her Trezor there.

If Alice’s company wants a 2-of-3 vault co-signed by Alice, Bob, and an external advisor who happens to be Carol, the org admin can build a multisig in Org A using Alice’s BitBox02 + Bob’s Coldcard + Carol’s BitBox02 — provided Carol first shares her device into Org A as a guest member.

The same pattern works the other way: keys held by users primarily based in different orgs can be brought together into one vault as long as every contributing device is shared into the organization that will operate the vault.

When you share a device with an org, the following becomes visible to other members of that org:

Visible to other org membersNot visible / not exposed
Device nameYour seed phrase
Device model and fingerprintYour private key material
The device’s extended public key (xpub)Your other devices that aren’t shared
Derived addresses for any vault the device is inYour personal wallets outside the org
Who shared the device (your user account)Devices you’ve shared with other orgs

The xpub allows the org to derive receive and change addresses for any vault containing the device. This is necessary for the vault to function — the same xpub would be exposed in a personal multisig wallet too.

You can revoke a share at any time from Settings → Device Shares → (the share row) → Revoke. Org admins with the device:share permission can also revoke a share on your behalf (useful if you’ve left the team and forgot to clean up).

Revoking a share does not break existing vaults. The vault descriptor was already created and contains the public key — the org can still build PSBTs and receive funds at vault addresses. What revoking does prevent:

  • Building new vaults that include the device
  • Future re-discovery of the device in the org’s pool

If a vault that includes the device is still active when you revoke, you remain a signer on it. To stop participating in transaction signing for an existing vault, the vault itself needs to be rotated — there’s no way to retroactively remove a key from a multisig descriptor that’s already protecting funds on-chain.

  • Coordinate with the vault operator before revoking. If you’re a required signer on a vault, revoking the share leaves the descriptor intact but signals that you’re stepping back. Plan a vault rotation if your departure is permanent.
  • Use one device per role. It’s tempting to share the same device into multiple orgs, but if that device is lost or compromised every vault that uses it is affected. For higher-value setups, use a dedicated device per organization.
  • Audit periodically. Review Settings → Device Shares on each org you belong to and revoke shares you no longer need.
  • Learn how an org admin actually builds a vault from contributed devices and what the per-vault consent flow looks like.
  • Review the broader Threat Model for how Sigvault protects keys and what assumptions it makes about device security.