Devices & sharing
Because secrets are encrypted per device, managing devices is managing access. This page covers pairing, revoking, and sharing entries with other people.
Pair a new device
Pairing adds a device to the set that can decrypt your vault.
Start on the new device
Install the extension or open the web app on the new device. It generates its own keypairs and displays its public keys as a scannable QR code and as copyable JSON.
Authorize from an existing device
On a device you've already got, open Add device and either scan the QR code with its camera or paste the JSON. It registers the new public keys and signs an attestation vouching for them.
Backfill happens automatically
Existing entries get re-sealed to the new device so it can read your history, not just future entries.
The keys are post-quantum hybrid pubkeys, too large for a single QR, so the new device cycles through a short sequence of frames. Hold the scanning device steady until it has collected every frame; it reassembles them automatically. The payload is only public keys (the same data the JSON carries), so it's safe to display.
A second device is a convenient way back in, alongside the backup file you downloaded at setup and any operator backup. You only need one of them, but more than one is comforting.
Revoke a device
Lost a device, or retiring one? Revoke it from the device list (web app or popup). Revocation:
- drops the device from the recipient set, so new entry versions are no longer sealed to it;
- rejects that device's next login and any further authenticated request, the interceptor's per-request device-active check takes effect immediately, not after the token's lifetime;
- leaves its past signatures valid, so versions it legitimately signed before revocation still verify.
See Authentication & sessions for the exact revocation timing.
Delete vs. revoke a device
Revoking keeps the device row, it stays a valid signer so the versions it signed in the past still verify. Deleting removes the device entirely, which is stricter and guarded so it can't break verification or the trust chain. The server refuses a delete when:
- it's the device you're currently signed in on (you can't delete the ground you're standing on);
- the device still signs at least one current entry version, you're told to re-sign those from another device first, otherwise readers could no longer verify them;
- another device names it as its attestation parent, those children must be deleted first, so the trust chain never dangles. Revoking child devices is not enough, they must be fully deleted.
In short: revoke is the everyday "this device is gone, stop trusting it for new writes" action; delete is a clean-up that only goes through once nothing else depends on the device. For a lost or compromised device, revoke is what you want.
Share an entry with another user
Sharing grants another open-secret user's devices read access to an entry:
Look up the recipient
The owner looks the recipient up by email to get their user id.
Seal to their devices
The owner fetches the recipient's device public keys and seals a ciphertext of the entry for each of those devices, then adds them as a recipient.
Updates keep everyone covered
Every later edit must seal a share for every active device of every recipient, the server enforces that a write covers the whole recipient set, so no device is silently left on a stale version.
Removing a recipient stops sealing future versions to their devices. (As with revocation, it cannot retroactively un-share versions they already decrypted, practice the same hygiene you would when sharing any secret.)