4-Eyes Authorization is one of the most effective controls for protecting backup data from a single compromised credential. Most solo admins and small teams skip it because it sounds like it requires a dedicated security team. It doesn't. Here is how to implement it when you're a team of one.
Full article with step-by-step setup guide at anystackarchitect.com - link in profile.
The Threat Model
Ransomware operators don't just encrypt 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 admin account is compromised and 4-Eyes is not enabled, an attacker with that credential can delete every backup job, remove every repository, and wipe the config database before you know anything is wrong.
4-Eyes Authorization is the control. With it enabled, no single credential can complete a destructive operation. 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 who has your primary credentials hits a wall - they can create the request, but they cannot approve their own request.
What It Protects - and What It Doesn't
Once enabled, these operations require a second approval:
-
Deleting backup files or snapshots from disk or the configuration database
-
Deleting information about unavailable backups
-
Removing backup repositories and 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
-
Disabling 4-Eyes itself - also requires a second approval
Important limitation: 4-Eyes cannot protect the infrastructure if the VBR server is compromised at the OS level. On Windows, a local admin can create accounts to self-approve. Running VBR on the VSA or a hardened Linux appliance closes that bypass vector.
Also: with 4-Eyes enabled, delete operations via PowerShell cmdlets, REST API, and Veeam Backup Enterprise Manager are blocked entirely. Audit your automation before enabling. File copy jobs that overwrite files also need a registry workaround.
| LICENSE REQUIREMENT 4-Eyes Authorization requires Veeam Universal License (VUL) or Enterprise Plus edition. Not available on lower-tier socket licenses. Confirm your edition under Help > About before proceeding. |
The Solo Admin Problem - Second Account Options
The feature requires at least two accounts with Veeam Backup Administrator or Security Administrator roles. For a team of one, here are your options ranked by security strength:
| Option | Security | Notes |
| Trusted external partner | Strong | VAR, MSP, or peer engineer. Security Admin role scoped to approvals only. Genuine separation of identity. |
| Break-glass account | Strong | Credentials + TOTP seed stored offline in sealed envelope. Used only to approve requests. |
| gMSA account | Acceptable | AD-managed password, never known to a human. Note: MFA cannot be enabled on gMSA - non-interactive accounts are not supported. |
| Second local account | Weak | Technically satisfies the requirement. Attacker with your primary creds likely has access to the same machine. |
The External Partner Model
This is the strongest option for a solo admin because it creates genuine separation of identity. Assign the partner the Veeam Security Administrator role - approval authority only, no ability to configure jobs, modify repositories, or access backup data.
The workflow: you initiate a deletion, Veeam holds it in the pending queue, an email notification goes to the partner, they confirm with you out-of-band and approve in the console. The entire interaction is logged in the Authorization Events node under History view.
Critical: the partner should always confirm directly with you before approving any request - not just click approve on every email. If an attacker submits a malicious deletion request, that email notification is the only signal your partner will see.
MFA - Enable This First
MFA and 4-Eyes are complementary. MFA raises the bar for initial access, 4-Eyes raises the bar for damage after access is obtained. Enable both on both accounts involved.
In VBR: Main Menu > Users and Roles > Security tab > Enable multi-factor authentication. MFA must be configured per individual user account - user groups are not supported. For a break-glass account, store the TOTP seed with the offline credentials.
| THE MINIMUM VIABLE IMPLEMENTATION MFA on your primary admin account. Break-glass account with Security Admin role, MFA enabled, credentials + TOTP seed stored offline in a sealed envelope. 4-Eyes enabled with a 7-day approval window. Email notifications configured. Test the full workflow end to end. Under 30 minutes to configure. The protection is real. |
Defense-in-Depth Summary
| Control | What It Stops | What It Doesn't Stop |
| MFA on primary account | Credential phishing enabling console login | Session hijacking after successful login |
| MFA on approver account | Approver credential compromise enabling malicious approvals | Simultaneous compromise of both accounts |
| 4-Eyes Authorization | Single credential completing destructive operations | OS-level compromise of the VBR server |
| Immutability | Direct file deletion during the immutability window | Attacks after the window expires |
| VBR on VSA / Linux | Local Windows admin OS-layer 4-Eyes bypass | Hypervisor-level compromise of the VSA host |
KEY TAKEAWAYS
-
4-Eyes Authorization requires VUL or Enterprise Plus. Available by default in v13 VUL deployments.
-
Destructive operations are held in a pending queue until a second account approves. Disabling 4-Eyes also requires a second approval.
-
Does not protect against OS-level VBR server compromise. Running on the VSA or hardened Linux closes the Windows local admin bypass vector.
-
PowerShell, REST API, and Enterprise Manager delete operations are blocked entirely when enabled. Audit automation first.
-
For solo admins: external partner or break-glass account provide the strongest second-account models. gMSA works but MFA cannot be applied to it.
-
MFA path in VBR: Main Menu > Users and Roles > Security tab. Per-user only - groups not supported.
-
Minimum viable setup under 30 minutes. No excuse not to have this enabled.
Full article with 6-step enable guide and partner agreement recommendations at anystackarchitect.com.
