Skip to main content
MFA adds a second step — a 6-digit code — between identity verification (password or OAuth) and full session access. Users choose their second factor in their profile’s Two-step verification section: email codes, an authenticator app (Google Authenticator, 1Password, and similar apps — the standard TOTP codes that change every 30 seconds), or both. Enrolling an authenticator app also issues a set of one-time backup codes as a safety net. MFA is currently opt-in, with a post-login nudge for admin accounts and self-serve controls in every user’s profile.
MFA is enabled at the platform level. If the two-step verification options described here don’t appear in your deployment, contact the Praxis AI team at humans@praxis-ai.com.

​
How it works

The diagram shows the email flow. Users who have enrolled an authenticator app are asked for their app’s current code instead (no email is sent); from the verification screen they can switch to a one-time backup code — or to an email code, when that factor is also turned on. Key choices:
  • 6-digit numeric code (matches every other auth code users see — banks, Google, etc.)
  • Emailed codes are valid for 5 minutes; authenticator-app codes follow the standard 30-second rotation
  • Trusted devices skip the code for 7 days by default (the window is configurable between 1 and 30 days at the platform level)
  • A device only counts as trusted when both its trust cookie and its network (roughly, the same local network or provider block) match the original verification — someone who moves to a different network is asked for a code again
  • Enrolling an authenticator app issues one-time backup codes (each usable once) for when the app is unavailable
  • LTI, SDK, and API-key sign-ins are exempt — they have their own identity proofs

​
Managing MFA per user

From Admin → Users, click a user’s row to open the editor, then switch to the Security tab. The Two-step verification block exposes:
  • Require email MFA for this user — toggle that enables / disables MFA on the target account. Disabling also resets any authenticator-app enrollment and backup codes, so a user who lost both can recover and re-enroll cleanly
  • Enabled <date> caption when MFA is on
  • Revoke trusted devices — invalidates every browser the user has previously verified. The next login from any of those browsers will re-prompt for a code
Turning MFA off does not sign the user out. Their current sign-in stays valid until it expires on its own (about six hours). Disabling only clears the devices they had marked as trusted, so the user’s next fresh sign-in proceeds without MFA. If you need to force an immediate logout, use the Sessions panel separately.

​
When to disable a user’s MFA

  • The user is locked out (lost email access, lost their authenticator app and backup codes, new email address pending, mailbox bounced)
  • A security incident requires temporarily reducing friction so the user can recover their account
  • A standard user opted in voluntarily and changed their mind

​
When to revoke trusted devices

  • The user reported a device lost or stolen
  • A shared / public computer was used during a recent session
  • After a suspected password compromise (combined with a password reset)

​
Audit trail

Every MFA event is recorded in an audit trail: enabling or disabling MFA (whether the user did it themselves or an admin did it for them), each code issued, resent, verified, or failed, lockouts, trusted devices added or revoked, and dismissals of the opt-in prompt. If you need an audit extract for a security review, contact the Praxis AI team at humans@praxis-ai.com.

​
Brute-force protection

Two layers, both enforced server-side:
  1. Per-code: 5 attempts. The 6th wrong submission invalidates the challenge — the user must click Resend for a fresh code. Resends are cooldown-limited to once per 30 seconds.
  2. Per-account: 5 burned codes in 1 hour. “Burned” means invalidated and had at least one wrong attempt (so a user spam-clicking Resend without submitting wrong codes doesn’t trip the lock). After 5 burns the account is locked out of MFA verification for 10 minutes. If the user can’t wait, an admin can disable MFA for them from the Security tab.

​
Exempt paths

The MFA gate is bypassed for sign-ins that already have a strong alternate proof of identity:
  • LTI launches — the LMS (Canvas / Moodle / Brightspace) has already authenticated the user
  • SDK launches — the embedding application’s launch token proves identity
  • API-key sign-ins — the API key itself is a strong credential, intended for server-to-server use
Standard password and OAuth (Google / GitHub / Facebook / generic OAuth2 SSO) flows all go through the MFA gate when the user has it enabled.

​
Frequently asked questions

Not in this phase. MFA is opt-in per user. The post-login nudge encourages admin accounts to enable it (with a 7-day “Remind me later” cooldown), but enforcement is the user’s choice. Mandatory MFA is on the roadmap.
Their current JWT stays valid until natural expiry (default 6 hours). Their trusted-device cookies are revoked. So the user keeps working through their current session, then re-signs in normally without MFA. If you need to force an immediate logout, terminate their session from the Sessions panel separately.
Yes. The verify form uses the autocomplete="one-time-code" attribute, so iOS Safari surfaces the 6-digit code from the Mail app directly in the keyboard suggestion bar — one tap to fill all six boxes. Android Chrome and Firefox have equivalent suggestions when SMS Retriever-style attributes are honored.
Yes. When a user enrolls an authenticator app, Pria generates a set of one-time backup codes, shown once with a download option. Each code works exactly once and substitutes for the app when the phone is lost or unavailable. If a user burns through both the app and every backup code, recovery is admin-assisted: disable MFA from the Security tab (this also resets the enrollment) and have them re-enroll. If no other admin is available, contact the Praxis AI team at humans@praxis-ai.com.
Supported. Users enroll from their profile’s Two-step verification section by scanning a QR code (or entering the setup key manually) with any standard TOTP app — Google Authenticator, 1Password, Authy, and the like — then confirming with a live code. Once enrolled, the app becomes the preferred factor at sign-in. WebAuthn / passkeys remain on the longer-term roadmap.