The authentication policy is the tenant-wide control plane. Many of these knobs have dedicated topics elsewhere; this page is the single edit surface for all of them.
Open the policy
Section titled “Open the policy”Settings → Authentication policy. A single long form with sections.
Sections + knobs
Section titled “Sections + knobs”Identifier
Section titled “Identifier”What users sign in with:
- Email — the default. Users sign in with their email address.
- Username — for tenants where users don't have email (unusual).
- Either — users can pick. Adds a small UI complexity.
Sign-in methods
Section titled “Sign-in methods”Which methods are offered on the sign-in page. Each toggleable:
- Password
- Email OTP
- Magic link
- Social providers (Google, GitHub, Microsoft, Apple)
- SSO / SAML connections
Each method has its own configuration in Authentication.
MFA enforcement
Section titled “MFA enforcement”Coverage of MFA enforcement — duplicated here as a one-line dial:
- Off / Optional / Required
- Plus per-group + per-application overrides (jump to the dedicated page for the matrix view)
MFA enrolment timing
Section titled “MFA enrolment timing”When Required:
- First sign-in.
- On next sign-in after policy change.
- Within a grace period (configurable days).
Allowed factors
Section titled “Allowed factors”Which factors can satisfy MFA. Pick from:
- WebAuthn
- TOTP
- SMS
- Backup codes
- Custom factors you've defined
Lockout
Section titled “Lockout”Per-user + per-IP failed-attempt thresholds:
- N failures in M minutes → lockout for P minutes.
- N failures in M hours → lockout for P hours.
Defaults are sensible; tighten for high-security tenants.
Risk-based controls
Section titled “Risk-based controls”Coverage of Adaptive step-up:
- Risk thresholds — score X demands MFA; score Y blocks.
- Per-trigger policies for event-based step-ups.
Captcha
Section titled “Captcha”When + where to demand captcha:
- After N failed sign-ins from the same IP.
- For sign-ups from suspicious IPs.
- Always for password-only sign-in (rare; high friction).
Session policy
Section titled “Session policy”How long sessions live + how aggressively they're revoked:
- Idle timeout — kill the session if no activity for N minutes / hours / days. Default 14 days.
- Absolute timeout — kill the session after N hours / days regardless of activity. Default 30 days.
- Concurrent sessions — maximum number of simultaneous sessions per user. Default unlimited; constrain for high-security tenants.
Admin step-up
Section titled “Admin step-up”Whether admin operations require step-up:
- Toggle to demand MFA for the admin themselves before performing destructive operations (delete user, force MFA reset on another user).
We recommend on. Defends against compromised admin sessions.
Save propagates immediately to the next sign-in / next session creation. Existing sessions are NOT auto-revoked when policy changes; they retain their previous state until they naturally expire.
For immediate effect (e.g., "every session must now be MFA"), pair the save with a tenant-wide session revocation:
Users → Actions → Revoke all sessions tenant-wide. Heavy-handed but immediate.
Per-application overrides
Section titled “Per-application overrides”Most policies CAN be overridden per-application. The application's authentication-policy tab carries the overrides.
A typical pattern:
- Tenant default: Optional MFA, 14-day refresh.
- "Cymmetri Finance" application overrides: Required MFA, 7-day refresh, demand step-up on every payout.
Per-app overrides are powerful; document them so future admins know why a specific app's behaviour differs from the tenant default.
Every save records admin.policy_updated with:
- The actor (you).
- The diff (every changed field).
- The timestamp.
Audit log → filter on admin.policy_updated to see policy history.
Common patterns
Section titled “Common patterns”"Rollout to MFA-required"
Section titled “"Rollout to MFA-required"”- Today: Optional.
- Set enrolment timing to "within grace period 14 days".
- Communicate to users; encourage early enrolment.
- After 14 days: change Optional → Required. Users without a factor get the enrolment prompt on their next sign-in; users with a factor are unaffected.
"Tighten for an incident"
Section titled “"Tighten for an incident"”- Lockout: tighter thresholds.
- Risk-based controls: lower the "demand MFA" threshold.
- Captcha: enable always.
After the incident subsides, revert. Audit retains the history.
"Loosen for a known maintenance window"
Section titled “"Loosen for a known maintenance window"”Rare; usually you tighten, not loosen. But for a planned mass-onboarding, you might temporarily disable captcha for a known IP range. Use sparingly.