Sign in to the console as a Veeam Backup Administrator, go to Users and Roles > Security, remove any user groups, select Enable multi-factor authentication (MFA) and click OK. Each user is then asked to set up an authenticator app at their next sign-in. Before you do that, make sure every administrator is listed as an individual user, move scripts and integrations onto service accounts, and check the server clock. MFA is not available in Community Edition.
What to sort out before you switch it on
Veeam's built-in MFA asks for a six-digit code from an authenticator app each time someone signs in to the remote console or web UI. Any app that supports the standard one-time password formats (RFC 4226 and RFC 6238) will do, which covers the usual authenticator apps. Push notifications are not supported, so the code is the only route.
Enabling it is a single tick box. That is exactly why it catches people out: the setting applies to every user account in the list, it does not work with groups, and several non-interactive connections cannot answer a code prompt. The real work is the preparation, and it is quick if you do it in the right order. This guide covers the console route on a Windows-based backup server.
As for how much protection to expect, app-generated codes are a genuine step up from a password alone. The NCSC ranks app-based code generators third of five MFA types and notes they are vulnerable to one-time-code interception phishing. Veeam's built-in MFA uses only this method, so treat it as a solid layer rather than the whole defence for your backup server.
- Edition: MFA is not supported in Veeam Backup & Replication Community Edition.
- Your access: only users with the Veeam Backup Administrator role can manage MFA, so sign in as one.
- Named users, not groups: MFA works only for individual user accounts. Anyone who currently gets in through a group needs their own entry first.
- Service accounts: the REST API, Enterprise Manager's connection to the backup server, the Veeam ONE agent connection, Veeam Backup Validator, the Veeam Backup PowerShell Module (or Windows PowerShell used with it) and configuration database restores cannot use MFA. Whatever account runs them must be marked as a service account.
- Devices: each person needs an authenticator app on a phone or other device they will have to hand when they sign in.
Prepare the accounts and the clock
This part is where you avoid the lockout. Removing a group before the people in it have named accounts is the quickest way to lose console access, so the order below matters. Time matters too: codes only validate when the authenticator device and the Veeam server agree on the time. Veeam's guide says to keep both synchronised to UTC.
- Sign in to the console as a Veeam Backup Administrator and go to Users and Roles > Security (the v13 guide writes it as Users & Roles). Note whether any administrators get in through a group rather than a named account.
- Add each person who needs access as an individual user in the same Users and Roles area, giving administrators the Veeam Backup Administrator role. Then sign in as each of them once, using their password, to prove the account works before anything changes.
- Identify every account used for non-interactive work, such as a REST API client, Enterprise Manager, the Veeam ONE agent, Backup Validator or a scheduled PowerShell task. For each one, select the account, click Edit, select This is a service account (disables two-factor authentication) and click OK. Keep these accounts for machines and scripts only. A service account skips MFA entirely, so it makes a poor everyday login for a person.
- On the backup server, open Command Prompt and check where Windows is getting its time. This only reads the clock configuration. Look at the Source and Last Successful Sync Time lines and confirm they are sensible, then check that the phones people will use are set to automatic time.
w32tm /query /status
Turn MFA on
This is a global switch. From the next sign-in onwards, every user in the list who is not a service account has to set up an authenticator app before they can get in. If you generate a new backup server certificate while MFA is enabled, restart any connected consoles afterwards.
- Sign in as a Veeam Backup Administrator and go to Users and Roles > Security.
- Remove any user groups from the list so that only individual users remain. Check first that the named administrator accounts from the previous section are present.
- Select the Enable multi-factor authentication (MFA) check box.
- Click OK. Leave this console session open for now and do your first test from a second one, so you still have a way in if something is wrong. That is our precaution rather than documented Veeam behaviour.
Enrol your first account and check it works
Veeam shows setup instructions the first time a user signs in after MFA is switched on. Start with one administrator account and prove the whole loop before asking anyone else to do it.
- Open the console a second time, on this machine or another, and sign in as one of the named administrator accounts. Because MFA is enabled but not yet configured for that account, the console shows setup instructions and a one-time secret key.
- In your authenticator app, add a new entry and enter that key. Veeam stores only a hash of the key, so it cannot show it to you again. If the entry is ever lost, the way back is an administrator reset rather than recovering the key.
- Enter the six-digit code the app displays. The console should open.
- Close the console and sign in again. This time you should be asked for a code every time, and entering the current one should get you in.
- Once that works, close the original session and ask each other administrator to sign in and enrol. Then confirm your service-account connections still work, for example a REST API client, Enterprise Manager, the Veeam ONE agent and any scheduled PowerShell task.
If it doesn't work
Most problems come down to the clock, a forgotten service account or a lost phone.
- Codes keep being rejected: check the time on the phone and on the backup server first. Even a small offset makes code validation fail. Fix the clock on whichever is wrong and try again.
- Locked out after repeated failures: after more than five unsuccessful attempts, close and reopen the console and wait at least one minute before trying again.
- Lost or replaced phone: another backup administrator can go to Users and Roles > Security, select the user and click Reset MFA. The user sets MFA up again at their next sign-in. If every backup administrator is locked out, Veeam's guide says to contact Veeam Support, which is one more reason to keep your first test session open and enrol more than one administrator.
- A script, integration or restore stopped connecting: the account behind it probably still needs the service account setting from earlier. Edit the account and select This is a service account (disables two-factor authentication).
- Need to back out: sign in as an administrator, go to Users and Roles > Security, clear Enable multi-factor authentication (MFA) and click OK.
- Linux-based backup server: Veeam's 13.0.2 guide says accounts using both the Host Management console and the remote console or web UI need two separate authenticator entries. Veeam's later 13.1 documentation is reported to change this, so read the MFA page for your exact build before you start.
Sources and further reading
- Multi-Factor Authentication - Veeam Backup & Replication User Guide (13.0.2)
- Multi-Factor Authentication - Veeam Backup & Replication User Guide (current)
- Multi-Factor Authentication - Veeam Backup & Replication User Guide (version 12)
- Veeam 12 Multi-Factor Authentication (MFA) - Mirazon
- Recommended types of MFA - NCSC