Multi-factor authentication
Multi-factor authentication (MFA) adds a second verification step to sign-in, mitigating the risk of credentials being compromised through phishing, reuse, or breach.
MFA factors supported
Section titled “MFA factors supported”| Factor | Supported | Notes |
|---|---|---|
| TOTP (authenticator apps) | Yes | Standard RFC 6238 TOTP — works with Authy, Google Authenticator, 1Password, Bitwarden, Microsoft Authenticator |
| Backup codes | Yes | Eight single-use codes issued at MFA enrolment for recovery |
| WebAuthn / passkeys | Roadmap | Hardware-key and biometric authentication; planned for late 2026 |
| SMS | Not supported | SMS is widely deprecated as a second factor due to SIM-swap and SS7 attack risk |
Who can require MFA
Section titled “Who can require MFA”| Role | MFA policy |
|---|---|
| Fanzava platform staff | Mandatory for all production access |
| Hub admins | Strongly recommended; required by default on Enterprise plans |
| Hub participants | Optional by default; can be required by hub admin on Enterprise plans |
Hub admins configure their hub’s MFA policy from Admin → Settings → Security → MFA. Three policy levels are supported:
- Optional — participants choose whether to enable MFA
- Strongly encouraged — participants are prompted to enable MFA at sign-in but can dismiss the prompt
- Required — participants must enable MFA on first sign-in after the policy is set
Enrolment flow
Section titled “Enrolment flow”- Participant goes to Profile → Security → Enable MFA
- Fanzava displays a QR code and a manual entry key
- Participant scans the code with their authenticator app
- Participant enters the current 6-digit code to confirm
- Fanzava issues eight backup codes — the participant downloads or copies them
- MFA is now active on the account
Backup codes should be stored securely (password manager, printed and kept somewhere safe). Each code is single-use and is consumed when used.
Recovery
Section titled “Recovery”If a participant loses access to their authenticator app:
- They can sign in with a backup code, then re-enrol with a new authenticator
- If backup codes are also lost, the participant contacts their hub admin
- The hub admin can disable MFA for the participant from Admin → Participants → [Participant] → Security, which sends the participant a notification and requires them to re-enrol on next sign-in
- Disabling MFA is recorded in the Audit log
For Enterprise hubs, MFA disablement by hub admins can be optionally restricted to require dual approval — contact your account manager.
MFA challenge frequency
Section titled “MFA challenge frequency”By default, MFA is challenged:
- On every fresh sign-in (new device or expired session)
- On any sensitive operation: changing email, changing password, disabling MFA itself, downloading data exports
Within an active session, repeated MFA challenges are not issued for normal operations. Session lifetime and re-authentication policy are documented on Sessions & tokens.
Staff MFA
Section titled “Staff MFA”All Fanzava platform staff with any access to production systems are required to use MFA. This requirement is enforced through Cloudflare Access and is non-negotiable. See Global Admin separation for the full staff authentication architecture.