IAM Best Practices

Identity and access management is not a one-time setup. Roles and permissions can be scoped correctly on day one and still drift over time: credentials weaken, accounts of inactive users are not disabled, and lockout settings meant to stop attackers end up locking out legitimate operators instead. This page covers the ongoing practices that keep the identity system itself in good shape, rather than the roles and permissions covered in Granular Roles / Restricted Backup Admin.

Password policy

Enforce the use of strong, complex passwords. For user accounts, NIST guidance recommends a minimum of 15 characters. NIST no longer requires special characters and numbers, but combining upper and lowercase letters, numbers, and special characters still makes a password harder to guess. A passphrase, combining multiple real words, can make a long password easier to remember without weakening it. Even an entire phrase works: it’s really easy to remember but at the same time hard to guess since it’s made with a multitude of characters.

For service accounts, use 25+ characters combined with a password management tool, so the password never needs to be memorized or typed manually. The embedded password generators of these tools help in creating very complex passwords without the need to remember them.

Make sure default accounts and passwords have been changed on every asset.

Zero Trust in practice: For admin accounts, enable and enforce MFA in addition to a strong password - see Multi-Factor Authentication.

Do not lose access to your credentials

Losing access to backup infrastructure credentials can be as damaging as losing the backups themselves. This applies to manually stored passwords, the password manager’s own database or its master password, and TOTP-based MFA enrollment: if any of these becomes unreachable during a disaster recovery scenario, the backups may be technically intact but inaccessible.

Zero Trust in practice: Some password managers offer cloud-based backup with emergency recovery options built in, which can help address this scenario. Whatever mechanism is used, it should be tested as part of disaster recovery planning.

Lockout policy

A lockout policy complements password policy: accounts are locked after a defined number of failed attempts, which stops password-guessing attacks. This can also be turned against you. An attacker can trigger repeated failed logins on purpose to lock out a legitimate account, including the account of the person who would need to perform a restore during an incident.

For service accounts this type of attack can become a proper DoS (Denial of Service) strategy: the user can be disabled by the lockout policy even if the password is never found. So, for service accounts we suggest disabling account lockout, prohibiting interactive logon, and using long, high-complexity passwords. Raising alerts on repeated failed attempts, instead of locking the account, gives visibility into the suspicious activity without the same exposure. For human user accounts, lockout remains appropriate, since their passwords are comparatively easier to guess and by the nature of their accounts, interactive logons cannot be disabled.

Account lifecycle

When a person changes role or leaves the organization, their account should be disabled, not deleted. Disabling removes access immediately while keeping the account’s identity intact for audit purposes, so past actions remain attributable. Deleting the account breaks that attribution, and if there are specific permissions given to the disabled account to resources, or ownership, regaining access to those resources may be difficult or at least cumbersome.

Zero Trust in practice: Never delete accounts, disable them.

SAML / IdP authentication

Veeam supports single sign-on through SAML 2.0, and you may find this feature listed among the security capabilities of Veeam. Using an identity provider is not inherently more secure than local accounts - the security improvement, if any, comes entirely from what the IdP itself enforces. An IdP with MFA and regular password rotation raises the bar above local accounts with just a username and password. An IdP without those controls does not.

VSA Security Officer

On the Veeam Software Appliance, the Security Officer role can technically be disabled during initial setup. This is strongly discouraged: the Security Officer is what enforces separation between managing users and controlling security-sensitive operations. Not using it removes that separation entirely.

Zero Trust in practice: Never disable the Security Officer in production environments. The option to skip it is there mainly for Test or Lab environments.