Veeam v13: Security Hardening and Best Practices

Veeam v13 Series | Component: VBR v13, VSA v13 | Audience: Enterprise Architects, Security and Compliance Teams, Hands-on Sysadmins

Most Veeam environments were configured by someone who needed backups to work. Not by someone thinking about what happens when a backup admin account gets compromised. Those are two different starting points and they produce two very different environments.

The gap matters now more than it ever has. Ransomware operators have figured out that deleting backups before encrypting production is how you turn a bad day into an unrecoverable one. They're targeting backup infrastructure specifically, and they're patient about it.

This article covers the controls that actually close that gap. Four Eyes authorization, how it works, and where it stops. Encryption done right instead of done quickly. The insider threat surface most Veeam shops leave wide open. And the Security Officer architecture that v13 introduced to make zero trust backup infrastructure a real thing you can configure, not just something vendors say.

1. What You're Actually Defending Against

Before you touch a single setting, be clear about the threat model. The controls in this article aren't primarily about external attackers getting through your firewall. They're about what happens after a credential is already compromised. After a disgruntled admin decides to act. After ransomware has moved laterally and is specifically targeting your backup infrastructure.

The backup server is the highest value target in a ransomware attack. An attacker who can authenticate to VBR with a Backup Administrator account can delete every restore point in your environment before anyone notices. The goal of this article is to make that impossible even if the account is compromised, even if the attacker is patient, and even if the person doing it is a legitimate employee.

2. Four Eyes Authorization

Four Eyes requires a second person to approve certain operations before they execute. Simple concept. The details matter a lot.

What It Actually Covers

When Four Eyes is enabled, the following operations require approval from a second Backup Administrator or Security Administrator before they go through:

• Deleting backup files or snapshots from disk or the configuration database
• Deleting information about unavailable backups from the config database
• Removing backup repositories or storage from the infrastructure
• Adding, updating, or deleting users or user groups
• Enabling or disabling MFA for all users
• Resetting MFA for a specific user
• Enabling, updating, or disabling automatic logoff for all users
• Cloud Connect operations: removing cloud repositories, deleting tenant backup files

That last category matters for MSPs specifically. A tenant who calls your support line and convinces someone to delete their "accidentally created" backups without a second approver is a social engineering attack you've just made much harder to execute.

What It Doesn't Cover

Four Eyes also can't protect you if the VBR server itself is compromised at the OS level. An attacker with OS access can stop Veeam services and delete backup files directly from the filesystem. VBR controls don't apply at that point. That's why immutability on the repository is a separate layer, not a substitute. You need both.

Enabling It

Before you flip this switch, confirm you have at least two accounts with Backup Administrator and at least two with Security Administrator. If you only have one approver and they're on vacation when someone needs to delete a restore point, the request sits there until they get back. That's not a hypothetical. It happens.

1. In the VBR console, go to the main menu, then Users and Roles, then Authorization.
2. Check Require additional approval for sensitive operations.
3. Set the approval window. Minimum is 1 day, maximum is 30. Default is 7 days. Requests that aren't approved or rejected inside that window are automatically rejected. Seven days is fine for most environments, but consider shortening it to 2 or 3 if you're under active compliance auditing.
4. Configure email notifications so approvers actually know when a request is pending. Without email, they have to check the console manually. Nobody does that.
5. Tell your backup admins before you enable it. The first time someone tries to delete a restore point and gets an unexpected approval dialog with no context, you're getting a support ticket.

The Security Officer on the VSA

On the Veeam Software Appliance, there's a dedicated Security Officer account configured at installation time. It's separate from the Host Administrator account and it has to stay that way. They can't be the same person in any meaningful security implementation.

The Security Officer logs in separately at port 10443 via the Veeam Host Management web UI. Their primary role on the VSA is approving password reset requests and user unlock operations. Data deletion approval follows the same VBR console flow as on Windows, but the Security Officer account provides an additional gate for host level admin actions that the standard Backup Administrator role can't touch.

If the Security Officer password is lost and there's no backup Security Officer configured, account recovery requires direct console access to the appliance. Treat those credentials the same way you treat your config backup encryption password. Store them somewhere that survives the system they protect getting compromised.

3. Encryption Key Management

Veeam supports encryption at two levels. Job level encrypts data before it leaves the source. Storage level encrypts data at the repository. Most environments that use encryption at all use job level. That's the right call for most cases, but there's a common mistake that turns job level encryption from a protection into a liability.

The Mistake: Encrypting Without Password Loss Protection

When you enable encryption on a backup job, Veeam generates a data encryption key for each backup chain and wraps it with a key derived from your password. The password lives in the VBR config database, encrypted. That means if the password is lost and you haven't configured password loss protection, that backup is permanently unrecoverable. Not hard to recover. Gone.

Veeam Enterprise Manager provides a key escrow mechanism. When Enterprise Manager is connected to VBR and configured correctly, a recovery key is stored in Enterprise Manager that lets you decrypt without the original password if you lose it. This isn't optional if you're encrypting production backup jobs. It's the difference between a recoverable situation and an unrecoverable one.

1. Deploy Veeam Backup Enterprise Manager if it's not already in use. There's no workaround here. EM is required for key escrow.
2. In VBR, go to the main menu, Encrypted Backups, and enable Enterprise Manager key support. VBR stores an encrypted recovery key with EM automatically.
3. Verify the connection between VBR and Enterprise Manager is healthy. The Encrypted Backups node in VBR shows which jobs have EM key protection active. If a job isn't showing it, the connection isn't working.
4. Test the recovery path. Once a year, simulate a lost password on a non-production backup. Confirm you can restore using the EM key recovery workflow. Untested recovery paths aren't recovery paths.

KMS Integration

v13 supports external Key Management System integration via KMIP. If your organization already runs HashiCorp Vault, Thales, or AWS KMS, you can point VBR at it directly instead of managing key material inside Veeam. Backup encryption keys live in your existing key governance framework. Rotation happens at the KMS level. VBR requests fresh material each backup cycle.

Password Hygiene

• Use a unique encryption password per backup job category. A compromised password only affects the jobs it covers.
• Store passwords in your enterprise password manager. Not a spreadsheet. Not a shared inbox. Not a Teams channel pinned message.
• Set the password hint to something meaningful to your team but not guessable by someone reading it. The hint is stored in the clear.
• Rotate passwords annually or after any personnel change that had access to them. Rotation requires a new full backup with the new password. Old chains stay encrypted with the old password until they age out of retention.

4. The Insider Threat Surface

The Veeam Backup Administrator role is one of the most powerful accounts in your infrastructure. Someone with that role can delete every backup in the environment, disable encryption, remove repositories, and modify RBAC. Most environments assign it liberally to anyone who touches backups. That's the attack surface.

Role Scoping in v13

v13 introduced custom roles with scoped permissions. You can now give an engineer access to manage backup jobs for a specific set of VMs without giving them access to repository management, user management, or backup deletion. Before v13 the role was essentially binary: Backup Administrator or nothing useful.

Service Account Isolation

The service account VBR uses to connect to vCenter is one of the most targeted accounts in a backup environment. Standard practice is to create one account and use it for everything. Better practice is isolation by function, because a compromised service account that can reach vCenter, your managed servers, and your repositories is a credential that can move laterally through your entire backup fabric.

• Create a dedicated vCenter service account for VBR with the exact minimum permissions Veeam documents. Don't use a vCenter administrator account. It has permissions VBR will never need and that an attacker would love to have.
• Use Group Managed Service Accounts (gMSA) for all Windows server connections where possible. gMSA passwords rotate automatically and are never readable by a human.
• Restrict service account logons to the VBR server IP only. A service account that can log in from anywhere is a credential that works for an attacker from anywhere.
• Never reuse VBR service accounts in other systems. If the account has permissions outside the backup infrastructure, a compromise of that account provides a path to everything it can touch.

MFA on Everything

v13 enforces MFA by default on the VSA. On the Windows VBR server it's configurable but not enforced by default. Enable it. Settings, Users and Roles. Enforce it at minimum for every account with Backup Administrator or Security Administrator role.

Here's why the Four Eyes and MFA combination matters: because MFA changes require Four Eyes approval when both features are enabled, an attacker who's compromised a backup admin account can't disable MFA without a second approver. The attack sequence becomes: compromise account, attempt to disable MFA, request sits pending for up to 7 days while hopefully someone notices. That's not a guarantee, but it's a meaningful delay that gives you a window to detect and respond.

SAML SSO and Identity Lifecycle

v13 supports SAML 2.0 authentication for the VBR web UI and the VSA Host Management console. If your organization uses Microsoft Entra ID, backup console logins go through your standard conditional access policies and MFA enforcement automatically. More importantly, an employee who's offboarded in Entra ID loses VBR access at the same time as everything else. Not whenever someone remembers to delete the local account. At the same time.

This closes a gap that most environments don't even know they have. Local VBR accounts for people who left six months ago are more common than anyone wants to admit.

5. What Immutability Does and Doesn't Do

Immutability comes up in every Veeam security conversation, so it's worth being precise about what it actually covers and where it stops.

What It Does

• Backup files on a correctly configured hardened Linux repository can't be modified or deleted for the immutability period. Even by root. The protection is enforced at the Linux kernel level via XFS immutable file attributes. Not a software setting. Not a Veeam setting. The kernel rejects the delete.
• Immutable backup files can't be deleted even with Four Eyes authorization active. Four Eyes blocks the VBR deletion workflow. Immutability blocks the filesystem deletion. Two independent controls, both have to be bypassed.
• Object storage immutability (S3 Object Lock) provides the same protection for capacity tier backups. Even the AWS account that owns the bucket can't delete objects during the retention period when Object Lock is configured correctly.

What It Doesn't Do

• Immutability doesn't protect against an attacker who has root access to the Linux repository server and can modify the immutability configuration itself. The hardened repository configuration in VBR disables persistent root SSH access specifically to close this gap. If someone adds an SSH key to the repo server, that protection is gone.
• Immutability doesn't protect against orphaned backup chains. An attacker who deletes the VBR configuration database entry for a repository can make your immutable backups unrestorable without touching a single backup file. Back up the VBR config database separately and frequently.
• Immutability doesn't mean the backup is good. An immutable backup created from already encrypted ransomware data is immutable and useless. That's why SureBackup verification and malware detection matter alongside immutability, not instead of it.

6. Network Isolation

Your backup server, proxies, and repositories should be on a network segment that's not directly reachable from general purpose servers or workstations. Most environments skip this because it adds complexity to the initial setup. That's a tradeoff worth thinking carefully about.

• VBR console access should be restricted to a jump host or specific admin workstations. Not available from every machine on the corporate LAN.
• The VBR REST API (port 9419) and the VSA Host Management web UI (port 10443) shouldn't be exposed to general network segments. Firewall rules, not just security group policies that an admin can change.
• Production servers should have no route to the repository server. If they don't know it exists, they can't attack it.
• Keep backup traffic on dedicated VMkernel interfaces or dedicated physical interfaces where possible. Backup infrastructure that's visible on the production network is reachable by anything on the production network.

7. Audit Logging

Every control in this article is worth less if you can't prove it's working and can't reconstruct what happened during an incident.

• The Authorization Events node in the VBR History view is where Four Eyes events live. Export these regularly to a SIEM or log platform that's outside the VBR environment. Logs that only exist on the compromised server aren't useful during incident response.
• Enable syslog forwarding in VBR settings to send events to your SIEM in near real time. The Splunk integration in the monitoring article in this series is the right approach if you're already ingesting Veeam session data there.
• Run the Security and Compliance Analyzer quarterly. Home view, Security and Compliance, Analyze Now. Export the results and store them. An auditor asking for proof of your security posture at a specific date needs the exported report. The live console view isn't an audit artifact.
• The VBR configuration backup is effectively a blueprint of your entire backup infrastructure. Encrypt it, store it off the VBR server, and audit access to wherever it lives.