How Do I Enforce Multi-Factor Authentication for My Team in Dave by voolama?

Summary

The steps

1. 1

   Navigate to the MFA settings and choose your provider type

   The MFA settings in Dave by voolama (hellodave.ai) are at Admin, then Settings, then Access, then 2FA. Only the Admin role can access this page. Sourced from the admin-settings help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

   Eight MFA provider types are available. The practical choice between them comes down to assurance level and device requirement. TOTP providers (Google Authenticator, Microsoft Authenticator, Authy) require a smartphone and a 30-second rotating code. Duo Security adds push notifications and phone callback. YubiKey requires a physical hardware key. Email OTP and SMS OTP require no additional device but provide lower assurance. Custom allows any provider with configurable setup instructions.

   The most common mistake at this step: selecting Email OTP or SMS OTP for a sensitive environment because they require no additional device. NIST SP 800-63B section 6.1.2 requires AAL2 for systems handling sensitive data. Email OTP and SMS OTP satisfy AAL1 only. If your compliance obligation requires AAL2, select a TOTP provider or YubiKey. The AAL level is not shown in the Dave by voolama UI: you must know it from the NIST standard itself.

   Provider	Type	Device required	NIST 800-63B AAL
   Google Authenticator	TOTP	Smartphone	AAL2
   Microsoft Authenticator	TOTP + push	Smartphone	AAL2
   Authy	TOTP + cloud backup	Smartphone	AAL2
   Duo Security	Push / TOTP	Smartphone or hardware token	AAL2
   YubiKey	FIDO2/WebAuthn	Physical hardware key	AAL3 (phishing-resistant)
   Email OTP	Email	Email access	AAL1 only
   SMS OTP	SMS	Mobile phone	AAL1 only
   Custom	Configurable	Depends on implementation	Depends on implementation

   Note: these are MFA providers only. SSO/OIDC providers (Google, Microsoft, GitHub, Okta, Custom OIDC) are a separate feature configured at Admin, then Settings, then Access, then OAuth. Never conflate the two counts: eight MFA types, five SSO/OIDC providers.

   Do this

   1. Navigate to Admin, then Settings, then Access, then 2FA.
   2. Read the eight provider cards. Each card includes inline setup instructions and links to official documentation.
   3. Identify which provider type matches your compliance requirement: AAL2 (TOTP), AAL3 (YubiKey), or AAL1 (Email/SMS OTP).
   4. Do not enable MFA yet. Configure the four enforcement settings in step 2 first.

   Example

   A team handling EU personal data under GDPR Article 32 needs 'appropriate technical measures.' The Admin reads the eight provider cards. Email OTP is available but satisfies AAL1 only under NIST SP 800-63B section 6.1.1. The Admin selects Google Authenticator (AAL2 TOTP) for standard users. The inline setup instructions link to the official Google Authenticator documentation. The Admin reads the instructions before proceeding to the enforcement settings.

   Best practice

   The admin-settings help documentation states: "Each provider card includes inline setup instructions and links to official documentation to help the admin configure the service." Read the inline instructions for your chosen provider before enabling MFA. Enabling MFA with a Grace Period of 0 before completing provider setup will lock users out at their next login. Complete provider setup first, then set the enforcement policy.

2. 2

   Set Grace Period before enabling, not after

   The most operationally significant decision in MFA setup for Dave by voolama (hellodave.ai) is the Grace Period, not the provider type. Setting Grace Period to 0 on a tenant with existing users who have not yet enrolled locks every user out at their next login. The admin-settings help documentation states: "Number of days users have to set up MFA after it becomes mandatory." Sourced from the admin-settings help documentation, DEV v0.11.0, confirmed 2026-08-30.

   The lockout scenario plays out like this: Admin enables MFA, Grace Period 0, Enforcement Policy Tenant-wide mandatory. A Use-role user logs in 20 minutes later. The login form redirects to an MFA enrolment page. The user has no MFA device configured. The user cannot log in. The user contacts the Admin. The Admin navigates to Admin, then Settings, then Access, then 2FA, increases Grace Period to 14 days, and saves. The user can now log in and has 14 days to enrol. The admin-settings help documentation states: "Admins can manually unlock an account from Admin, then Settings, then Users and Roles before the lockout period expires. Lockout events are recorded in the audit log."

   Verify the Grace Period value is saved correctly: navigate to Admin, then Settings, then Audit Log immediately after saving. A settings change event appears with the updated Grace Period value in the payload. No vendor trust required.

   Setting	Options	Safe default for existing tenants	Maximum security value
   Enforcement Policy	Tenant-wide optional, Tenant-wide mandatory, Per-user optional	Per-user optional (phase rollout)	Tenant-wide mandatory
   Grace Period	0 to 30 days	14 days	0 (immediate, risky on existing tenants)
   Trusted Device Duration	0 to 90 days	30 days	0 (re-verify every login)
   Backup Codes	On / Off	On	Off (removes recovery path, increases lockout risk)

   NIST SP 800-53 Rev 5 IA-5 (Authenticator Management, section 5b) requires establishing lifetime restrictions for authenticators. Trusted Device Duration is the implementation of IA-5 section 5b for session-level MFA tokens: a value of 30 days means the MFA authenticator is re-verified every 30 days. A value of 0 satisfies the strictest interpretation of IA-5 section 5b by requiring re-verification on every login.

   Do this

   1. Set Enforcement Policy. For an existing tenant: Per-user optional to phase the rollout. For a new tenant with no users: Tenant-wide mandatory is safe.
   2. Set Grace Period. For existing tenants: 14 days minimum. For new tenants with no users: 0 is safe.
   3. Set Trusted Device Duration. 30 days balances usability and security. 0 requires MFA on every login.
   4. Set Backup Codes to on unless your security policy explicitly prohibits recovery codes.
   5. Do not click Save Settings yet. Toggle Enable MFA on first.

   Example

   An Admin is enabling MFA on a tenant with 12 existing users. The Admin sets Enforcement Policy to Per-user optional, Grace Period to 14 days, Trusted Device Duration to 30 days, and Backup Codes to on. After all 12 users have enrolled (confirmed in the Audit Log as 12 MFA enrolment events over the following 14 days), the Admin returns to the 2FA settings and changes Enforcement Policy to Tenant-wide mandatory. This two-phase approach prevents lockouts and satisfies NIST SP 800-53 Rev 5 IA-2 (section 2) for all users before mandatory enforcement begins.

   Best practice

   Notify your team before enabling mandatory MFA. The admin-settings help documentation does not document an in-app notification for MFA enforcement changes. Users who are not expecting the MFA enrolment prompt will contact the Admin. A brief internal message explaining the change and the enrolment deadline reduces support load during the Grace Period.

3. 3

   Enable MFA and verify with three independent checks

   After configuring the four enforcement settings in Dave by voolama (hellodave.ai), toggle Enable MFA on and click Save Settings. The green confirmation banner reads 'Settings saved successfully.' Sourced from the admin-settings help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Three independent verification steps confirm the MFA configuration is active. All three are observable in the UI without trusting the vendor. These are the same three checks that a security auditor would perform to verify MFA enforcement is active.

   Check 1: audit log event. Navigate to Admin, then Settings, then Audit Log immediately after saving. A settings change event appears with a timestamp matching the save. The event payload shows the MFA settings you configured. This event is the independently verifiable record that MFA was enabled at a specific point in time. No vendor trust required.

   Check 2: login page. Sign out. The login page shows MFA provider options alongside the standard email/password form. The provider cards are independently visible. No vendor trust required.

   Check 3: test user login. Log in with a non-Admin test account. If Enforcement Policy is Tenant-wide mandatory and Grace Period is 0, the test account is prompted to enrol in MFA immediately. If Grace Period is greater than 0, the test account sees the grace period countdown. Both outcomes are independently observable. No vendor trust required.

   GDPR Article 32 requires 'appropriate technical measures ensuring a level of security appropriate to the risk.' The three-check verification sequence produces independently observable evidence that MFA enforcement is active: the audit log event (timestamped record), the login page (UI evidence), and the test user login (behavioural evidence). Together they satisfy the Article 32 documentation requirement for technical measures.

   Do this

   1. Toggle Enable MFA on.
   2. Click Save Settings. Confirm the green banner reads 'Settings saved successfully.'
   3. Check 1: navigate to Admin, then Settings, then Audit Log. Confirm a settings change event is present with a timestamp matching the save.
   4. Check 2: sign out. Confirm the login page shows MFA provider options.
   5. Check 3: sign in with a non-Admin test account. Confirm the MFA enforcement behaviour matches the Grace Period you set.

   Example

   An Admin saves the MFA configuration with Enforcement Policy set to Per-user optional and Grace Period set to 14 days. The green banner confirms the save. Check 1: the Admin navigates to the Audit Log and confirms a settings change event is present timestamped within 2 seconds, with the payload showing Grace Period changed from 0 to 14. Check 2: the Admin signs out and confirms the login page shows Google Authenticator and YubiKey options. Check 3: the Admin signs in with a test Use-role account and confirms the MFA enrolment prompt appears with a 14-day countdown. All three checks pass. No vendor trust required.

   Best practice

   After enabling MFA, monitor the Audit Log for lockout events in the first 24 hours. The admin-settings help documentation states: "Lockout events are recorded in the audit log." If a user is locked out during the Grace Period, an Admin can unlock the account at Admin, then Settings, then Users and Roles. NIST SP 800-53 Rev 5 IA-2 (Identification and Authentication, section 2) requires multi-factor authentication for privileged accounts. Confirm the Audit Log shows MFA enrolment events for all Admin-role users within the Grace Period. If any Admin account has not enrolled before the Grace Period expires, that account will be locked out at next login.

What this guide does not cover