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
Settings → Authentication policy. A single long form with sections.
Sections + knobs
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
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
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
When Required:
First sign-in.
On next sign-in after policy change.
Within a grace period (configurable days).
Allowed factors
Which factors can satisfy MFA. Pick from:
WebAuthn
TOTP
SMS
Backup codes
Custom factors you've defined
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
Coverage of Adaptive step-up:
Risk thresholds — score X demands MFA; score Y blocks.
Per-trigger policies for event-based step-ups.
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
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
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
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
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.
Audit
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
"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"
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"
Rare; usually you tighten, not loosen. But for a planned mass-onboarding, you might temporarily disable captcha for a known IP range. Use sparingly.