MFA and 4-Eyes Authorization for the Solo Admin

Four-Eyes Authorization exists to prevent a single compromised account from deleting your backups. Most teams skip it because it sounds like an enterprise feature that requires a dedicated security team. It does not. A solo admin can implement it today - the second approver can be a trusted external partner, a break-glass account, or even a gMSA. The threat model justifies the five minutes of setup.

The Threat Model You Are Defending Against

Ransomware operators do not just encrypt your production data. The playbook now includes credential theft, lateral movement to the backup server, and destruction of backup data before the encryption payload runs. If your Veeam administrator account is compromised and 4-Eyes is not enabled, an attacker with that credential set can delete every backup job, remove every repository, and wipe the configuration database before you know anything is wrong. Immutability helps - but only if your retention period is longer than the attacker's dwell time. Credential compromise is a different attack surface and deserves a separate control.

4-Eyes Authorization is that control. With it enabled, no single credential can complete a destructive operation in Veeam. A delete request is created, held in a pending queue, and cannot execute until a second account with Veeam Backup Administrator or Security Administrator rights approves it. An attacker with your primary admin credentials hits a wall. They can create the request, but they cannot approve their own request.

What 4-Eyes Does Not Protect

Veeam's documentation is explicit about this: 4-Eyes Authorization cannot protect the backup infrastructure if the Veeam Backup and Replication server itself is compromised at the OS level. If an attacker has local administrator access to the machine running VBR, they can create additional Windows users with local admin rights and use those accounts to approve their own requests. The protection is at the Veeam application layer, not the OS layer.

This is the strongest argument for running VBR on the VSA or on a hardened Linux appliance rather than a general-purpose Windows server - the OS-level bypass vector is significantly harder to exploit when there is no local Windows administrator surface to pivot through. If you are running VBR on Windows today, 4-Eyes is still worth enabling, but pair it with OS-level hardening and restrict local administrator access to the VBR machine itself.

The other constraint: with 4-Eyes enabled, destructive operations via PowerShell cmdlets, the REST API, and Veeam Backup Enterprise Manager are blocked entirely - those paths do not support the approval workflow. If your automation scripts use PowerShell to clean up old backups or remove repositories, those scripts will break. Audit your automation before enabling.

License Requirement

4-Eyes Authorization requires either Veeam Universal License (VUL) or the Enterprise Plus edition. It is not available on lower-tier socket licenses. If your environment runs VUL - which is the licensing model for v13 deployments - you already have access. Confirm your edition in the VBR console under Help > About before proceeding.

The Solo Admin Problem - and the Solutions

The feature requires at least two accounts with Veeam Backup Administrator or Security Administrator roles. For a team of one, that means creating a second account before you can enable it. You have several options, each with different security and operational trade-offs.

The External Partner Model in Practice

The external partner option is the strongest for a solo admin because it creates genuine separation of identity. The partner does not need Veeam operational access - they need only enough permissions to view pending approvals and approve or reject them. Assign them the Veeam Security Administrator role, which provides approval authority without the ability to configure jobs, modify repositories, or access backup data.

The workflow is simple. You initiate a deletion or repository removal. Veeam holds it in the pending queue. An email notification goes to the partner. They review the request, confirm with you out-of-band (a quick message or call), and approve it in the console. The operation executes. The entire interaction is logged in the Authorization Events node under the History view.

Set the approval window to a period that matches your operational tempo. The default is 7 days - requests not approved or rejected within that window are automatically rejected. For a small environment where deletions are infrequent, 7 days is fine. If you need faster turnaround, coordinate with your partner on expected response time. The minimum window is 1 day, maximum 30.

Enabling 4-Eyes Authorization

MFA - The Prerequisite You Should Enable First

4-Eyes Authorization protects against a compromised credential completing a destructive operation. MFA protects against the credential being usable at all. The two controls are complementary - MFA raises the bar for initial access, 4-Eyes raises the bar for damage once access is obtained. Enable MFA on both accounts involved in the 4-Eyes model. If your primary admin account has MFA and the approver account does not, an attacker who compromises the approver account can approve their own malicious requests submitted under your primary account.

Veeam v13 supports TOTP-based MFA for all user accounts. Enable it under Main Menu > Users and Roles > Security tab. MFA must be configured per individual user account - user groups are not supported. For a break-glass account with offline credentials, configure MFA and store the TOTP seed alongside the account credentials - both in the sealed offline location. If you use an external partner as your approver, require them to enable MFA on their Veeam account as a condition of the arrangement.

The Partner Agreement You Should Have in Writing

If you use an external partner as your approver, document the arrangement. It does not need to be a formal contract but it needs to cover: what the role entails, expected response time for approval requests, out-of-band verification procedure before approving (the partner should confirm with you directly before approving any request, not just click approve on every email), credential rotation schedule for the approver account, and what happens if the partner relationship ends. The last point is important - when the arrangement ends, you need a process to rotate the approver account credentials and verify the account cannot still be used.

The out-of-band verification step is not optional. If an attacker compromises your primary account and submits a deletion request, the email notification to your partner is the only signal that something happened. Without a policy of confirming directly with you before approving, that email alone is not a reliable verification signal.