Join the Waitlist
Guide · Admin and Governance

How to Configure MFA in DAVE

By DAVE by voolama5 stepsUpdated AUG 20266 min readAI

Summary

DAVE supports eight MFA provider types, from TOTP authenticator apps to hardware security keys and SMS codes. This guide walks through enabling MFA, choosing a provider, setting an enforcement policy, and configuring grace periods and trusted devices.

The steps

  1. Navigate to the MFA settings screen

    MFA configuration lives inside the Access tab of DAVE's Settings screen. Navigate to Admin, then Settings, then select the Access tab. Within the Access tab, locate the Two-Factor / Multi-Factor Authentication (2FA / MFA) section.

    The Access tab is only visible to users with the Admin role. If you do not see it, your account does not have the required role. Ask an existing Admin to assign the Admin role to your account at Admin, then Settings, then Users and Roles, then log out and back in for the change to take effect.

    Do this
    • Navigate to Admin, then Settings.
    • Select the Access tab.
    • Scroll to the Two-Factor / Multi-Factor Authentication (2FA / MFA) section.
    • Confirm the section is visible and the Enable MFA toggle is present.
    Example

    You open Admin, then Settings and click the Access tab. The page shows four sections: Passwords, Two-Factor / Multi-Factor Authentication, Login Security, and Session Management. You scroll to the MFA section and see the Enable MFA toggle in the off position.

    Best practice

    Before enabling MFA in a production tenant, review the enforcement policy options and grace period settings in steps 3 and 4 of this guide. Turning on the master switch with a mandatory enforcement policy and a zero-day grace period will require all users to set up MFA on their very next login, with no warning. Plan the rollout before flipping the switch.

  2. Enable MFA and choose a provider

    Click the Enable MFA toggle to turn multi-factor authentication on for your tenant. This is the master switch: when it is off, no MFA is required or offered to any user, regardless of the other settings in this section.

    With MFA enabled, select the provider or providers you want to make available to your users. DAVE supports eight MFA provider types:

    • Google Authenticator (TOTP): time-based one-time passwords via the Google Authenticator app.
    • Microsoft Authenticator (TOTP): time-based OTP with push notification support via Microsoft's app.
    • Authy (TOTP): multi-device TOTP with encrypted cloud backup.
    • Duo Security (Push / TOTP): enterprise MFA with push notifications, phone callback, and hardware token support.
    • YubiKey (Hardware, FIDO2/WebAuthn): a physical security key for phishing-resistant authentication.
    • Email OTP (Email): one-time codes sent to the user's registered email address.
    • SMS OTP (SMS): one-time codes sent via text message. Carrier charges may apply to users.
    • Custom (Configurable): a custom MFA provider where you configure the name, type, and setup instructions.

    Each provider card in the settings screen includes inline setup instructions and links to official documentation. MFA is a completely separate feature from SSO: DAVE's five SSO/OIDC providers (Google, Microsoft, GitHub, Okta, and custom OIDC) are configured on the OAuth sub-tab and operate independently of MFA.

    Do this
    • Click the Enable MFA toggle to turn it on.
    • Review the eight provider cards and select the provider or providers appropriate for your organisation.
    • Read the inline setup instructions on each provider card before proceeding.
    • For the Custom provider, enter the provider name, type, and setup instructions in the configuration fields.
    Example

    Your organisation uses YubiKey hardware tokens for privileged accounts and wants TOTP as a fallback for standard users. You enable MFA, then activate both the YubiKey card and the Google Authenticator card. Users with a YubiKey can register it; users without one can use Google Authenticator instead.

    Best practice

    Avoid enabling SMS OTP as the only MFA option for high-privilege accounts. SMS-based OTP is vulnerable to SIM-swapping attacks. For Admin role holders and other privileged users, prefer TOTP apps (Google Authenticator, Microsoft Authenticator, Authy) or hardware tokens (YubiKey, Duo Security). SMS OTP is a reasonable option for lower-privilege users where phishing-resistant hardware is not practical.

  3. Set the enforcement policy

    The enforcement policy controls whether MFA is required for all users, optional for all users, or configurable per user. DAVE offers three options:

    • Tenant-wide optional: MFA is available but not required. Users can choose to enroll in MFA from their account settings, but they are not prompted to do so and can continue to log in with a password alone.
    • Tenant-wide mandatory: MFA is required for every user in the tenant. Users who have not enrolled are prompted to set up MFA at their next login. After the grace period expires (configured in step 4), users without MFA cannot complete login.
    • Per-user optional: MFA enforcement is configured individually on each user account. Some users may be required to use MFA while others are not. This option gives the most granular control but requires more administrative overhead to maintain.

    For most organisations with a security or compliance requirement, tenant-wide mandatory is the correct choice. It ensures no user account is left without a second factor, which is the control that matters for SOC 2 CC6 and similar access control criteria.

    Do this
    • In the MFA section, locate the Enforcement Policy setting.
    • Select the policy appropriate for your organisation: Tenant-wide optional, Tenant-wide mandatory, or Per-user optional.
    • If selecting Per-user optional, plan which user accounts will require MFA and update those accounts after saving the settings.
    Example

    Your organisation is preparing for a SOC 2 Type II audit. You select Tenant-wide mandatory to ensure every user account has MFA enrolled. You will set a 14-day grace period in the next step to give the team time to enroll before the requirement is enforced.

    Best practice

    If you are enabling mandatory MFA for the first time on an existing tenant with active users, communicate the change to your team before saving. Users who log in after the grace period without having enrolled in MFA will be unable to complete login until they do. A brief announcement with setup instructions and a clear deadline reduces support requests and avoids disruption.

  4. Configure grace period and trusted device duration

    Two settings control the user experience around MFA enrollment and re-verification: the grace period and the trusted device duration.

    Grace Period (0 to 30 days): when MFA is set to mandatory, the grace period gives existing users a window to enroll in MFA before the requirement is enforced. During the grace period, users can log in without MFA but are prompted to set it up. Once the grace period expires, users who have not enrolled cannot complete login. A grace period of 0 days means MFA is required immediately on the next login, with no window to enroll first. A grace period of 14 days is a common starting point for a team rollout.

    Trusted Device Duration (0 to 90 days): after a user completes MFA verification on a device, that device can be marked as trusted for a configurable number of days. During the trusted period, the user is not prompted for a second factor on that device. A value of 0 days means the device is never trusted: MFA is required on every login. A value of 30 days means users are prompted for MFA once per month on each device they use.

    The right trusted device duration depends on your security posture. A shorter duration (0 to 7 days) is appropriate for high-security environments where frequent re-verification is acceptable. A longer duration (30 to 90 days) reduces friction for users who log in frequently from the same device.

    Do this
    • Set the Grace Period slider to the number of days you want to give existing users to enroll in MFA. Use 0 for immediate enforcement, or a value between 1 and 30 for a rollout window.
    • Set the Trusted Device Duration slider to the number of days a device remains trusted after MFA verification. Use 0 to require MFA on every login.
    Example

    You set the Grace Period to 14 days and the Trusted Device Duration to 30 days. Existing users have two weeks to enroll in MFA before it is enforced. Once enrolled, they will be prompted for their second factor once per month on each device they use regularly.

    Best practice

    For Admin role holders, consider setting a shorter trusted device duration than for standard users. Admin accounts have elevated permissions and are higher-value targets: more frequent re-verification is a proportionate control. If DAVE supports per-user trusted device overrides, apply a stricter setting to Admin accounts. If it does not, factor this into your choice of tenant-wide trusted device duration.

  5. Enable backup codes and save

    The final MFA setting is Backup Codes, a toggle that controls whether users can generate one-time backup codes for account recovery. Backup codes are single-use codes that allow a user to complete login if they have lost access to their primary MFA device, for example if a phone is lost or a YubiKey is misplaced.

    Enabling backup codes is recommended for most deployments. Without backup codes, a user who loses their MFA device cannot log in without direct Admin intervention to reset their MFA enrollment. With backup codes enabled, the user can use a previously generated backup code to regain access and re-enroll a new device.

    Once all MFA settings are configured, click Save Settings at the bottom of the form. A green confirmation banner confirms the save succeeded. The settings take effect immediately: users will be prompted for MFA on their next login if mandatory enforcement is active and their grace period has expired.

    Do this
    • Toggle Backup Codes on if you want users to be able to generate recovery codes.
    • Review all MFA settings one final time: Enable MFA (on), provider selection, enforcement policy, grace period, trusted device duration, and backup codes.
    • Click Save Settings at the bottom of the form.
    • Confirm the green success banner appears.
    • Communicate the change to your team, including the grace period deadline and instructions for enrolling in MFA.
    Example

    You toggle Backup Codes on, review all settings, and click Save Settings. The green banner confirms the save. You send a message to your team explaining that MFA is now required, that they have 14 days to enroll, and linking to the MFA setup instructions in their account settings.

    Best practice

    Advise users to generate and store their backup codes immediately after enrolling in MFA, not after they have already lost their device. A backup code stored in a password manager or printed and kept in a secure location is available when it is needed. A backup code that was never generated is not.

What MFA does, and what it does not do

Multi-factor authentication requires users to verify their identity with a second factor, in addition to their password, when they log in. The second factor is something the user has (an authenticator app, a hardware key, or a phone number) rather than something they know (a password). This means that a stolen or guessed password alone is not sufficient to access a DAVE account: an attacker also needs the second factor.

MFA in DAVE does three things:

  • It adds a second verification step to the login flow for enrolled users.
  • It allows Admins to require MFA for all users (mandatory), offer it optionally, or configure it per user.
  • It gives users a recovery path via backup codes if they lose access to their primary MFA device.

MFA does not do these things:

  • It does not replace SSO. DAVE's five SSO/OIDC providers (Google, Microsoft, GitHub, Okta, and custom OIDC) are a separate feature configured on the OAuth sub-tab of the Access settings. SSO and MFA are independent controls. You can run SSO without MFA, MFA without SSO, both together, or neither.
  • It does not change what a user can do inside DAVE. Permissions are still governed by the roles assigned to the user's DAVE account, regardless of how they authenticated.
  • It does not protect against a compromised session after login. Session security is governed by the Session Management settings (session timeout and refresh token rotation), which are configured separately in the Access tab.

The eight MFA provider types compared

Choosing the right MFA provider depends on your organisation's security requirements, the devices your users have access to, and the level of phishing resistance you need. Here is a practical comparison of all eight supported types.

  • Google Authenticator (TOTP). A widely used, free authenticator app. Generates a new 6-digit code every 30 seconds. No network connection required to generate codes. Does not support cloud backup: if a user loses their phone, they need backup codes or Admin intervention to re-enroll. Good for most standard users.

  • Microsoft Authenticator (TOTP). Similar to Google Authenticator but adds optional push notification support. Supports cloud backup via a Microsoft account. A good choice for organisations already using Microsoft 365.

  • Authy (TOTP). Supports multi-device use and encrypted cloud backup, making device recovery easier than Google Authenticator. A good choice for users who frequently switch devices.

  • Duo Security (Push / TOTP). An enterprise MFA platform with push notifications, phone callback, and hardware token support. Duo provides a management console for Admin-level visibility into MFA enrollment and authentication events across your organisation. A good choice for larger teams with centralised MFA management requirements.

  • YubiKey (Hardware, FIDO2/WebAuthn). A physical security key that plugs into a USB port or taps against an NFC-capable device. Phishing-resistant: the key cryptographically verifies the origin of the login request, so a phishing site cannot capture and replay the second factor. The strongest option for Admin accounts and other high-privilege users. Requires users to have a physical YubiKey device.

  • Email OTP. A one-time code sent to the user's registered email address. No additional app or device required. Convenient for users who do not have a smartphone. Weaker than TOTP or hardware options because it depends on the security of the user's email account.

  • SMS OTP. A one-time code sent via text message. Widely accessible but vulnerable to SIM-swapping attacks, where an attacker convinces a mobile carrier to transfer the victim's phone number to a SIM card the attacker controls. Acceptable for lower-privilege users; not recommended as the sole option for Admin accounts. Carrier charges may apply.

  • Custom. A configurable provider for organisations with a proprietary or non-standard MFA solution. You supply the provider name, type, and setup instructions. Use this option when none of the seven named providers match your existing MFA infrastructure.

Before you enable MFA: three things to confirm

Enabling MFA, especially with a mandatory enforcement policy, affects every user in your tenant. Confirm these three things before saving the configuration.

  1. All active user accounts have valid email addresses. If a user loses their MFA device and needs to use backup codes, or if you need to reset their MFA enrollment, their registered email address is the recovery path. An account with an invalid or inaccessible email address has no recovery option if MFA is lost. Review user accounts at Admin, then Settings, then Users and Roles before enabling mandatory MFA.

  2. At least one Admin account will not be locked out. If you are enabling mandatory MFA with a zero-day grace period, ensure your own Admin account is enrolled in MFA before saving. If you save mandatory MFA with a zero-day grace period and your account is not yet enrolled, you will be prompted to enroll on your next login. This is recoverable, but it is better to enroll first. Ensure at least one other Admin account can authenticate successfully in case your own enrollment has a problem.

  3. Your team has been informed. Users who log in after the grace period without enrolling in MFA will be unable to complete login. A brief communication to your team, with the enrollment deadline and setup instructions, prevents support requests and avoids disruption. The grace period slider (0 to 30 days) gives you the flexibility to set a rollout window that matches your team's capacity to respond.

MFA alongside password policy and login security

MFA is one of three access security controls in DAVE's Access settings. The other two are password policy and login security. Each addresses a different threat, and all three work together.

Password policy (in the Passwords section of the Access tab) controls the minimum complexity and maximum age of passwords. DAVE offers five complexity levels: None, Basic (8 or more characters), Standard (8 or more characters, mixed case, number), Strong (12 or more characters, mixed case, number, symbol), and Enterprise (16 or more characters, mixed case, number, symbol, no common passwords). Password expiration can be set to apply to all users, all non-admin users, or no users, with an expiration window of 15 to 90 days.

Login security (in the Login Security section of the Access tab) controls rate limiting and CAPTCHA. Rate limiting locks an account after a configurable number of consecutive failed login attempts (1 to 20, default 3) for a configurable lockout duration (1 to 60 minutes, default 5 minutes). CAPTCHA can be added to the login form using reCAPTCHA v2, reCAPTCHA v3, hCaptcha, or Cloudflare Turnstile.

The combination of a strong password policy, rate limiting, and mandatory MFA addresses the three most common credential-based attack vectors: weak passwords (addressed by complexity requirements), brute-force attacks (addressed by rate limiting and lockout), and stolen passwords (addressed by MFA). Configuring all three is the recommended posture for any DAVE tenant handling sensitive data or subject to compliance requirements.

Frequently asked questions

Is MFA the same as SSO in DAVE?
No. MFA (multi-factor authentication) and SSO (single sign-on) are separate features in DAVE. MFA adds a second verification factor to the login process. SSO allows users to authenticate through an external identity provider such as Google, Microsoft, GitHub, Okta, or a custom OIDC provider. SSO is configured on the OAuth sub-tab of the Access settings. Enabling MFA does not configure SSO, and enabling SSO does not configure MFA. Both can be active simultaneously.

How many MFA providers can be active at the same time?
The settings screen presents all eight provider types as individual cards. Users can be offered multiple provider options simultaneously, for example both YubiKey and Google Authenticator, so that users without a hardware key can use a TOTP app instead.

What happens if a user loses their MFA device?
If backup codes are enabled, the user can use a previously generated backup code to complete login and re-enroll a new device. If backup codes are not enabled, or if the user did not generate codes before losing their device, an Admin must reset the user's MFA enrollment. The user can then re-enroll on their next login.

Can I require MFA for Admin accounts only?
Yes, using the Per-user optional enforcement policy. With this policy, you can configure MFA as required on Admin accounts while leaving it optional for other users. Navigate to Admin, then Settings, then Users and Roles and update the MFA setting on each Admin account individually.

Does enabling MFA affect existing user sessions?
Enabling MFA does not immediately invalidate existing sessions. Users with active sessions will not be prompted for MFA until their current session expires and they log in again. If you need MFA to apply immediately to all users, you can force session expiration by reducing the Session Timeout setting in the Session Management section of the Access tab.

Where is the Access tab in Settings?
Navigate to Admin, then Settings and select the Access tab. The Access tab contains four sections: Passwords, Two-Factor / Multi-Factor Authentication, Login Security, and Session Management.

How to Configure MFA in DAVE