Multi-factor authentication policy

MFA turns every sign-in into "something you know + something you have". The AxisSynapse policy lets you decide whether MFA is required for everyone, which factor families are acceptable (e.g. only phishing-resistant), how long new users have to enroll before they're blocked, and what counts as recovery. Once the policy is set, the platform enforces it on every sign-in — through SSO, password, or passkey — without per-module rewiring.

TL;DR — Open Settings → Security → MFA policy, turn Require MFA on, pick Allow any factor for general workforces or Phishing-resistant only for executives + admin roles, give new users a 14-day grace period, click Save. Users get a soft prompt to enroll today and a hard requirement at the end of grace.

Before you start

• You must be a Workspace admin.
• Decide your acceptable factor set:
  • Allow any factor (TOTP, hardware key, passkey, recovery code) — friendliest, weakest.
  • Phishing-resistant only (passkey / hardware key) — strongest, requires every user to have a passkey or a YubiKey-class device.
  • TOTP + WebAuthn — middle ground.
• Decide your grace period: how many days a new user has between first sign-in and being blocked for not having MFA enrolled. Most workspaces pick 14 days; high-security workspaces pick zero.
• Have a rollout plan: communicate ahead of time to give users a chance to enroll before the policy hardens.

Set the MFA policy

1. 1

   Open Settings → Security → MFA policy

   From the workspace nav, click Settings, then Security, then MFA policy. The page shows the current policy + a preview of what users will see on their next sign-in.

2. 2

   Toggle "Require MFA"

   Off → users may enroll voluntarily but are not blocked. On → users must enroll within the grace period or be blocked from signing in.

3. 3

   Pick the acceptable factor set

   Choose from Allow any factor, Phishing-resistant only, TOTP + WebAuthn, or Recovery codes excluded. Each option shows a one-line description of which user behaviours change.

4. 4

   Set the grace period

   Slide between 0 and 30 days. The default is 14. The number applies to every newly created user — existing users are not subject to a fresh grace.

5. 5

   Optionally bypass for certain roles

   Expand Advanced. Add roles that are exempt (e.g. break-glass accounts). Exemptions are audited and surfaced in Security Console.

6. 6

   Click "Save"

   The new policy takes effect immediately. Active sessions stay alive; the next sign-in evaluates the new policy.

Acceptable factor sets

The grace period

When a new user is provisioned (via invite, SCIM, or SSO JIT) and the policy requires MFA, AxisSynapse counts the days from their first sign-in. During grace, the user sees a soft banner on every post-sign-in surface encouraging enrollment; on the day grace expires, the next sign-in is gated by an enrollment wall.

Every field, explained

What appears in the audit log

• TENANT_MFA_POLICY_UPDATED — every policy change.
• TENANT_MFA_ACCEPTED_FACTORS_UPDATED — the factor set was changed (e.g. switched to phishing-resistant only).
• TENANT_MFA_GRACE_GRANTED / ..._EXPIRED — per-user grace lifecycle events; aggregate to dashboard cards.
• ACCOUNT_MFA_DEVICE_ENROLLED / ..._REVOKED — every user-level factor change.
• ACCOUNT_MFA_DISABLE_BLOCKED — a user tried to disable MFA but policy refused. Investigate clusters of this code — they may indicate user confusion or attempted bypass.
• ACCOUNT_MFA_RECOVERY_CODE_USED — a recovery code was redeemed. Always review.

Common gotchas

• "Turning on Phishing-resistant only locked out my legacy accounts." Existing users with only TOTP enrolled don't have a valid factor anymore. Turn the policy back to TOTP + WebAuthn, give the team a deadline to enroll a passkey or hardware key, then tighten the policy after.
• "The grace timer didn't reset when I changed the policy." Grace is per-user, anchored on the user's first sign-in. Policy changes don't re-anchor it; if you want to give the team a fresh grace, use Force re-enrollment on policy change instead.
• "A user reports their authenticator app is out of sync." TOTP is time-bound. Have them resync the device's clock against network time (most apps have a sync option in their settings). Reissuing recovery codes is the last-resort fix.
• "We rotated MFA on a leaving employee, but they still signed in via SSO." SSO is authentication; MFA is a layered check. Disable the SSO account at your IdP as well, or rely on SCIM to deactivate the user.
• "The exemption list is growing — should I be worried?" Yes. Exemptions are operational tech-debt. Review the list quarterly and remove any account that doesn't need to be exempt.

Troubleshooting

| Error code | What it means | Fix | |---|---|---| | MFA_REQUIRED_NO_FACTOR | Policy requires MFA; user has no enrolled factor. | Sign in via the enrollment-required URL and follow the wizard. | | MFA_FACTOR_NOT_ALLOWED | The user's factor doesn't satisfy the current acceptable set. | Enroll a factor that does (passkey for phishing-resistant-only). | | MFA_RECOVERY_CODES_EXHAUSTED | All recovery codes have been used. | Regenerate a fresh batch from Account → Security. | | MFA_GRACE_EXPIRED | The grace window elapsed with no enrollment. | Re-grant grace from the user's row in Settings → Members, or the user enrolls now. |