Cloud backup and social recovery
Cloud recovery combines two separate controls: access to a previously linked account locates the encrypted backup, and a local decryption factor unlocks it. The restore walkthrough describes the user flow.
What Sigma stores
| Data | Purpose |
|---|---|
| Encrypted backup | Portable ciphertext uploaded after client-side encryption |
| Provider ID and provider account ID mapping | Locate the BAP identity's backup during authorized recovery |
| User/account/session records | Account login, ownership checks, and lifecycle |
| Linked-provider evidence and metadata | Account linking and supported credential eligibility |
This table describes recovery-related data, not an exhaustive privacy inventory. See the privacy policy. User identity keys and backup passwords are not sent as plaintext through the backup flow, but Sigma does operate with its own service credentials.
Identity and account linking
A provider login proves control of that provider account. It can establish a Better Auth session, support recovery, and provide evidence for eligible credentials. It does not prove possession of the BAP private key or decrypt a backup. A BAP identity and an OAuth provider account are distinct identifiers.
The durable mapping uses the provider's stable account identifier, not a display name or a user-editable profile email. Linking, uploading ciphertext, and creating a recovery mapping are separate operations; confirm each before depending on recovery.
Recovery resilience
Keep a strong, unique backup password and an offline encrypted copy. Preserve every format-specific field during export. A member backup does not contain the authority to reconstruct a master seed. Losing both the required key backup and its decryption factor cannot be fixed by support resetting an account password.
See Backup API for route-specific access and security for encryption details.