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.