Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.summand.com/llms.txt

Use this file to discover all available pages before exploring further.

Summand has MFA in two places: at sign-in (handled by WorkOS) and at sensitive operations like accessing private shared datasets (handled by Summand).

​
Sign-in MFA via WorkOS

Org admins can require MFA for every user in the organization, enforced at the WorkOS layer. This applies to email + password sign-ins, SSO sign-ins where the IdP doesn’t already enforce MFA, and the Continue with Google / GitHub paths.

​
Enforcement

Two modes:
ModeBehavior
RequiredEvery user must enroll a TOTP factor on first sign-in. No factor = no access.
OptionalUsers may enroll a factor; access is granted with or without it.
Configure in the WorkOS Admin Portal — Settings → Organization in Summand → click into the WorkOS-hosted org settings.

​
Enrollment flow

A new user with MFA required:
  1. Signs in with email + password (or SSO).
  2. Hits the MFA enrollment screen with a QR code and a manual entry secret.
  3. Scans the QR with Google Authenticator, 1Password, Authy, or any TOTP app.
  4. Enters the 6-digit code to confirm.
  5. Future sign-ins prompt for the 6-digit code after credentials.
The enrollment UI lives in web/components/features/auth/LoginForm.tsx — same screen flow whether the user signed in via SSO or password.

​
Recovery

If a user loses their device:
  • Self-recovery: WorkOS supports backup codes (issued at enrollment). The user enters a backup code instead of the 6-digit TOTP.
  • Admin reset: An org admin resets the user’s MFA from Settings → Organization → Members → Reset MFA. The user re-enrolls on next sign-in.
Hardware keys (FIDO2 / WebAuthn) are on the WorkOS roadmap; today, MFA is TOTP-based.

​
Per-operation MFA in Summand

Independently of sign-in MFA, Summand requires re-authentication for two sensitive operations:
  • Accessing a private dataset shared with you — proves ongoing possession of the second factor, not just an active session.
  • Granting share access to a teammate — for grants on private or sensitive datasets.
This is enforced regardless of how the user signed in. If they’re MFA-enrolled, they enter their TOTP code; if they’re not enrolled and the operation is hit, they’re forced to enroll on the spot. This is an intentional layer beyond sign-in MFA — long-lived sessions are cheap to compromise via cookie theft, but a fresh second-factor challenge isn’t.

​
Recommendation

For most enterprises:
  • Require sign-in MFA at the IdP. This is the strongest layer — your IdP enforces it for every login attempt across every SaaS, including Summand.
  • Require sign-in MFA in WorkOS as a backstop for sources where the IdP doesn’t enforce it (e.g. social login).
  • Leave per-operation MFA on. It’s the protection that catches stolen-cookie scenarios.
For HIPAA-regulated data, all three layers are recommended.

​
Audit

Every MFA enrollment, factor verification, and reset is logged. Events are visible in Audit Logs in the WorkOS Admin Portal and forwarded to your SIEM via Log Streams. See Audit logs.