Security

The same honesty standard we apply to what each platform actually enforces, we apply here: real practices already in place, described plainly, with no claims we can't back up.

Data in transit and at rest

• All traffic between your devices, the dashboard, and our servers is encrypted in transit (TLS).
• SMS message body content — the single most sensitive field in our schema — is encrypted at rest with AES-256-GCM, independently of database-level encryption.
• Passwords are never stored in a recoverable form — we hash them with Argon2id.

Device credentials

A device is enrolled using a short-lived, single-use pairing code (not a long-lived secret) entered on the device itself. Once paired, the device holds a long-lived credential that we only ever store as a hash — never the raw value — the same principle used for password storage. Pairing codes are also rate-limited, so a short human-readable code can't be brute-forced against our pairing endpoint.

Sessions

Access tokens are short-lived; a longer-lived refresh token is used to obtain a new one without asking you to log in repeatedly. Device sessions use a separate, short-lived device token distinct from your own parent login.

Payments

We use Stripe for payment processing. Card details are entered on Stripe's own hosted checkout page and never touch our servers — we only ever see a subscription status and plan identifier, never a card number.

Server-side enforcement

A device can never claim a capability its platform doesn't actually have — every device-facing write is re-checked against the server-stored capability flag for that platform, never trusted from the request body alone.

Responsible disclosure

If you believe you've found a security issue, please email us before disclosing it publicly — we take real reports seriously and will respond promptly. security@myguardian.fyi.