Multi-Factor Authentication

Authentication can rely on three independent categories of factors: something you know (a password or PIN), something you have (a hardware token or a mobile device generating a one-time code), and something you are (a biometric trait). Multi-Factor Authentication requires at least two of these categories together, rather than relying on a single one.

This matters specifically because a password alone is something you know, and anything you know can be stolen, guessed, or leaked without your awareness. Adding a second, independent factor means that a stolen password on its own is no longer sufficient to authenticate as that user.

MFA in Veeam Backup & Replication

Veeam Backup & Replication supports MFA, requiring a Time-based one-time password (TOTP) generated by an authenticator app in addition to the standard login and password. The choice of using a TOTP brings the advantage of working offline: the authenticator app doesn’t need to be connected to the Internet to generate the new token. This is useful in dark sites or datacenter rooms with no phone signal for example.

Larger organizations typically already use SAML (Security Assertion Markup Language) to authenticate users through their existing identity provider.

Where SAML is already in place, it can be worth extending it to VBR as well, rather than managing accounts directly in VBR. SAML by itself does not add a second factor to login - it is not inherently more secure, consistent with what is already noted for SAML / IdP authentication. If the identity provider behind SAML enforces MFA, however, using that integrated authentication is generally preferable to VBR’s native TOTP, and it also opens the door to stronger factors than TOTP alone - passkeys, biometric authentication, or hardware security keys such as Titan - depending on what the IdP supports.

MFA on Veeam Software Appliance Host Management

The Veeam Software Appliance introduces a host management layer that does not exist on Windows, where the operating system itself is managed directly. On VSA, Host Administrator and Security Officer are host-level accounts, separate from the VBR application users covered above. MFA behavior differs by role: a Host Administrator can enable or disable MFA for other users at any time, including MFA that was disabled during initial configuration. A Security Officer account cannot have MFA disabled once assigned - it is mandatory for that role.

Beyond login, MFA on VSA also gates specific sensitive operations on Host Administrator accounts: creating, editing, or removing users, assigning roles, or resetting MFA all require entering a one-time password first, regardless of whether the session is already authenticated. This authentication remains valid for 15 minutes.

MFA for the Veeam Backup & Replication console is disabled by default and configured separately from MFA for the Veeam Host Management console. Once enabled, the same authenticator code works for both.

Source: Veeam Software Appliance user guide - Configuring Users

Residual risk

MFA does not eliminate risk, only reduces it, consistent with the residual risk already discussed for Secure by Design and Segregation of Duties. A person can be coerced into revealing an MFA code they legitimately hold, in which case the second factor no longer provides independent protection - it only adds one more thing an attacker needs to obtain from the same individual.

Zero Trust in practice: We all know we always have our phones with us. So register MFA credentials in your favorite MFA app in your phone, and you’ll have your MFA key generator always with you too. Opening the app takes just a few seconds, and makes your Veeam environment much more secure.