The enforcement dial sets whether MFA is mandatory, optional, or off. The simplest setting in the admin console; the biggest impact on the security posture.
The three settings
MFA → Enforcement.
Off — MFA is not part of sign-in at all. Users CAN enrol factors voluntarily and use them, but no challenge is required.
Optional — users are prompted to enrol on first sign-in but can skip. Once enrolled, they're challenged on every sign-in. Users without a factor enrolled aren't challenged.
Required — every user must enrol an MFA factor. Users without a factor can't complete sign-in beyond the enrolment step.
The default for a fresh tenant is Optional. We recommend Required for production tenants.
Enrolment timing
When MFA is Required, you also pick when enrolment happens:
First sign-in — the user enrols on their first sign-in. They sign in normally, then are routed to "set up MFA" before reaching the app.
On next sign-in after policy change — existing users (signed in before the policy changed) are enrolled the next time they sign in.
Within a grace period — users have N days to enrol before sign-in is blocked. Lets you turn on Required without disrupting current sessions.
The grace-period pattern is the production-safe rollout. Set N to 7-14 days; communicate the deadline to your users via your usual channels; the policy fully enforces at the end.
Per-group overrides
You don't have to apply the same enforcement to every user. MFA → Per-group enforcement lets you carve out per-group rules:
All users → Optional.
Members of "Administrators" group → Required.
Members of "Finance team" group → Required.
Members of "Beta Testers" group → Optional.
The most-restrictive applicable rule wins. Anita is in both "Beta Testers" and "Administrators"; Required applies.
This is the pattern for "we're moving to MFA-required, but starting with the highest-risk teams first."
Per-application overrides
An individual application can override tenant defaults:
Tenant policy is Optional.
Application "Cymmetri Finance" overrides to Required.
Users signing into Finance must complete MFA; users signing into other apps continue at Optional level. The override lives on the application's authentication policy tab.
This is the pattern for "most apps are casual; the finance app demands strong auth."
Allowed factors
Per-tenant policy + per-group + per-application can further restrict which factors are valid:
"Required, but only WebAuthn or TOTP — not SMS."
"Required, but only WebAuthn — no TOTP or SMS."
Tighter restrictions for higher-risk surfaces.
What happens on policy change
You flip from Optional to Required.
New users sign-up flow now includes MFA enrolment.
Existing users currently signed in stay signed in (their tokens carry their previous AAL).
Existing users on next sign-in after the change → routed through MFA enrolment per your enrolment-timing pick.
Existing tokens don't lose their session immediately. If you need immediate revocation, pair the policy change with a tenant-wide session revocation — but this is heavy-handed; most teams use a grace period instead.
What happens when a user can't enrol
A user signs in, can't enrol any available factor (no phone for SMS, no device for WebAuthn, no app for TOTP). They're stuck.
Two paths:
Backup codes as enrolment. Configure backup codes as a valid initial factor. The first-sign-in flow generates backup codes; the user copies them; they're "enrolled" with codes only. Tightly constrained — once the codes run out, they have to re-enrol with something else.
Admin force-skip. A tenant admin can disable MFA enforcement for a specific user (via the user's detail page → MFA tab → "MFA bypass enabled"). The bypass is audit-logged and expires after a configurable window. Use sparingly.
Both are pragmatic escapes; both should be temporary. Long-term, every user gets a proper factor.
Sessions + MFA
A session carries its MFA state (AAL — Authentication Assurance Level). When the session was minted with MFA: AAL 2. Without: AAL 1.
Some applications (or specific operations in them) demand AAL 2 even if the session is AAL 1. The platform's adaptive step-up handles this — see Adaptive step-up.
Roughly: enforcement-Required ensures AAL 2 sessions at sign-in. Adaptive step-up handles "did the user's circumstances change since sign-in, do we need to re-verify?"
Common rollout
A safe rollout path:
Today: enforcement Optional.
Pick a date N weeks out.
Communicate to users: "On , MFA becomes required. You can enrol now."
Day before: change enrolment-timing to "within grace period 1 day".
Day of: change enforcement to Required.
Monitor audit for
user.mfa_requiredevents that fail to complete; reach out to users who get stuck.
Don't go from Off to Required overnight without comms — your support queue floods.