Security posture

• A passkey is the preferred primary method.
• A verification app (TOTP) or a roaming hardware security key provides separate protection.
• Backup codes are emergency recovery codes, stored only as one-way hashes, and never count as an active second factor.
• SMS authentication is not supported and will not be added.
• Passwords must be at least 12 characters and mix upper case, lower case and a number or symbol.

Signing in authenticates the account. It does not unlock a vault, and it never will: vault access is designed as a separate act with separate material. In this build no vault, key or encrypted object exists at all.

Every application table has row-level security enabled. A signed-in account can read only its own rows. Anonymous visitors can read nothing. Sensitive tables — backup-code hashes, one-time authentication challenges, replay guards, rate-limit records and the bootstrap ledger — deny all browser access outright and are reachable only through audited server-side functions.

Roles live in a dedicated role table and are checked by a security-definer function. Exactly one Platform Owner may ever exist, and the one-time provisioning path closes permanently after use. No Platform Owner is provisioned today. There is no generic role-granting route, no impersonation, and no way for staff to read private user content.

Authentication and account-security events are recorded with an outcome and kept for 24 months; raw network identifiers are minimised after 90 days. Audit rows cannot be modified or deleted from the browser under any role.

Report a suspected vulnerability to alex@siteways.io. Please do not test against another person’s account.