MFA enforcement

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 <date>, 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_required events 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.