Veeam Backup & Replication Security Best Practice Guide
Granular Roles / Restricted Backup Admin
Least privilege applied to backup infrastructure means each account holds only the permissions its function requires. This is not a general aspiration - it maps to specific, enforceable settings in VBR and VSA, not to policy documents that assume good behavior.
Restricted Backup Admin
On VBR deployed over Windows, the local Administrator account is automatically a Veeam administrator the moment Veeam Backup & Replication is installed, because the BUILTIN\Administrators group is mapped to the Backup Administrator role by default.
Using this accounts leads to two potential problems. First, “Administrator” is not mapped to a specific person, so any action taken through it cannot be attributed to an individual - auditing becomes meaningless. Second, an attacker already knows half of the credential pair: the username is a known constant, not something that needs to be discovered.
The fix consists of removing the BUILTIN\Administrators group from the Backup Administrator role mapping inside VBR. Since the group itself is no longer mapped to any Veeam role, none of its members retain Veeam access - including the Administrator account. The account remains fully available for other OS-level administrative tasks; only its automatic access to Veeam is removed.
Roles best practices
The correct approach is to create personal, named administrative accounts first, assign them to the appropriate role, and only then disable the built-in Administrator account.
Zero Trust in practice:
VBR ships with several distinct roles
- Backup Administrator
- Backup Operator
- Backup Viewer
- Incident API Operator
- Restore Operator
- Security Administrator
- Tape Operator
not just one all-or-nothing admin role. VBR on Windows does not have its own internal user store: it relies on the underlying OS or AD accounts and maps them to a Veeam role. This means you can take a plain Windows or AD account, one with no elevated permissions at the OS or domain level, and assign it a specific Veeam role. For larger environments with multiple operators, it is usually better to map a group rather than individual users - this keeps the mapping between people and roles clear over time as staff changes (more on this in IAM Best Practices).
Beyond the built-in Administrator account, the same principle applies to every admin: one dedicated account per person, never shared, never reused from a general office account. This keeps actions traceable to an individual and makes adding or removing access a matter of managing one account, not untangling shared credentials.
Access to the Veeam Console itself should be limited to the smallest group of people who need it. Every additional person who can log in is another path an attacker can use once they compromise that person’s credentials.
Veeam Software Appliance Host Management Console users and roles
Veeam Software Appliance also has distinct roles: Host Administrator, Security Officer, User, and Service Account, each with a different scope of permissions. The same least privilege principle applies here - assign the role that matches only the operations a user actually needs to perform, not a broader role for convenience. For further detail on each role and how to configure users, see the Veeam Software Appliance user guide.
Roles and scope
A role assigned to a user defines what that user can do in Veeam Backup & Replication. The role’s scope is what turns least privilege from a principle into an enforced boundary: a user assigned a narrow role cannot perform operations outside that role, regardless of what they know or what they are asked to do.
Beyond the default roles, VBR also supports custom roles with narrower, purpose-built scopes. For how to create and configure them, see the official documentation.
Required permissions
The accounts used for installing and operating Veeam Backup & Replication should be granted only what the official permissions guide specifies for that use case, not broad administrative rights taken as a shortcut.
When VMware vCenter Server is added to the backup infrastructure, an account with reduced permissions can be used instead of a full administrator account. Permissions should match the actual use case: for example, Hot-Add backup requires the “delete disk” permission specifically, not a general elevated role. Restore operations may require additional permissions beyond backup; these should be granted only when restores are being performed, not left standing by default. Details are available here.
Naming privileged accounts
Naming conventions for privileged accounts are not a security control. A prefix like “adm_” makes accounts easy to manage for IT, but the same pattern is just as easy for an attacker to search for. The actual protection against a compromised privileged account comes from MFA and password rotation, not from how the account is named. Whether to obscure administrator account names is a matter of organizational preference - it does not replace either control.
Related controls
This page covers roles, scope, and account structure. Related controls are covered elsewhere to avoid repeating them:
- Multi-Factor Authentication - see Multi-Factor Authentication
- Four-Eyes Authorization - see Segregation of Duties
- Password rotation and Group Managed Service Accounts - see Time-Bound Defense
- Password management policy, lockout policy, and account hygiene - see IAM Best Practices