A lot of small IT teams skip 4-Eyes Authorization because it sounds like something built for bigger shops with a separate security team.

That is the wrong way to look at it.

If you are the only admin touching Veeam, you probably need it more, not less. The whole point of the feature is to stop one compromised account from doing irreversible damage. If someone gets your Veeam admin credential and 4-Eyes is not enabled, they can try to tear down jobs, remove repositories, delete backup data, and make recovery harder before ransomware ever starts encrypting production. Your backup server becomes part of the attack path instead of the last line of defense.

What 4-Eyes changes is simple. A destructive action no longer completes just because one account asked for it. The request gets parked in a pending state and waits for a second account with the right role to approve it. If an attacker only has your primary credential, they can create the request, but they cannot finish it.

That is why this matters.

What it actually protects

Once enabled, 4-Eyes puts a second approval in front of the operations you would worry about most:

• deleting backup files or snapshots from disk or from the configuration database
• deleting records for unavailable backups
• removing repositories or storage from the infrastructure
• adding, changing, or deleting users and groups
• enabling or disabling MFA for all users
• resetting MFA for an individual user
• disabling 4-Eyes itself

That last point is worth calling out. Turning the feature off also needs a second approval, which is exactly how it should work.

There is one limit you have to understand before you get too comfortable: this is not magic protection against an OS-level compromise of the backup server. If the underlying Windows box is compromised and the attacker has local admin, they can potentially create the conditions needed to bypass the spirit of the control. That is why the platform decision matters. Running VBR on the Veeam Software Appliance or on a hardened Linux deployment takes away the easy Windows local-admin bypass path.

That is also the reason I treat 4-Eyes as one control in a stack, not the whole strategy.

Check the license before you burn time

This feature is not available everywhere.

4-Eyes Authorization requires Veeam Universal License or Enterprise Plus. If you are on a lower-tier socket-based edition, you are going to waste time looking for a switch that does not exist. Before you do anything else, check Help > About in VBR and confirm the edition.

That sounds obvious, but it is an easy miss.

The real problem for a solo admin: who is the second approver?

This is the part that makes people think the feature is out of reach. It is not. You just need to be honest about the strength of each option.

Best option: trusted external partner

If you have a VAR, MSP, or another engineer you trust, this is the cleanest model. It creates actual separation of identity. You keep your normal admin account, and the second person gets the Veeam Security Administrator role so they can approve sensitive requests without becoming your day-to-day backup operator.

That separation is the whole value. It is not just a second login. It is a second human boundary.

Strong fallback: break-glass account

If no external partner makes sense, use a dedicated break-glass account. Store the credentials and TOTP seed offline. Treat it like emergency-use-only access, not a convenience account you dip into whenever something is annoying.

This works well because the second factor is not living next to your main admin session, and the account is not part of your normal operational muscle memory.

Acceptable, with caveats: gMSA

A gMSA can satisfy the second-account requirement and has one useful characteristic: the password is AD-managed and not known to a human. That is better than a second ordinary user account.

The catch is that MFA cannot be applied to it, because non-interactive accounts are not supported for that use case. So yes, it can work, but it is not where I would start if I had a cleaner option.

Weakest option: second local account

This checks the box, but it is the least convincing form of separation. If the same compromised machine and same compromised operator context can reach both accounts, you have not really created a strong second boundary. It may satisfy the feature requirement. It does not do much for the threat model you are actually trying to fix.

Why the external-partner model is so strong

For a team of one, this is usually the model I like best.

You initiate the destructive action. Veeam holds it. The partner gets the notification, validates with you over a separate channel, and only then approves it. That approval is logged in the authorization history, so there is an audit trail showing who requested the action and who approved it.

The important word there is validates.

The second approver should not get trained into clicking Approve every time an email shows up. That kills the whole point. If a malicious request lands in the queue because your primary account was compromised, the partner’s hesitation and out-of-band verification is the control doing its job.

If you use this model, define that procedure up front. “Always confirm directly before approval” is not a nice-to-have. It is the rule that makes the setup worth having.

Turn on MFA before you call this finished

MFA and 4-Eyes solve different parts of the same problem.

MFA makes it harder to get into the console in the first place. 4-Eyes makes it harder to do irreversible damage after access is obtained. One does not replace the other. You want both.

In VBR, MFA is enabled under Main Menu > Users and Roles > Security tab. It is configured per user account, not per group, so plan accordingly. If you use a break-glass account, store the TOTP seed with the offline credentials. That is one of those details that seems small until you need the account and realize nobody can complete the second factor.

The minimum setup that is actually worth doing

If you want the shortest practical version, this is it:

If you are a solo admin, the break-glass model is usually the easiest way to get there quickly. The partner model is stronger, but either one is better than doing nothing and telling yourself you will “come back to it later.”

This is not a giant project. In most environments, you can stand up a usable baseline in under half an hour.

A few gotchas worth checking before you flip the switch

This is where people get surprised.

When 4-Eyes is enabled, delete operations through PowerShell cmdlets, the REST API, and Enterprise Manager are blocked entirely. If you have automation tied to those paths, review it before enabling the control. Otherwise you are going to find out after the change, not before it.

There is also a note around file copy jobs that overwrite files. Those may need a registry-based workaround, so do not assume every existing workflow will keep behaving the same way once approvals are required.

That does not mean “do not enable it.” It means know what else will move when you do.

How I would explain the layered defense

4-Eyes is strongest when it sits alongside the other controls instead of pretending to replace them.

MFA on the primary account helps with stolen credentials. MFA on the approver account helps stop malicious approvals if the second identity is targeted too. 4-Eyes stops one credential from completing destructive actions by itself. Immutability protects backup files during the immutability window. Running VBR on the appliance or a hardened Linux build closes off the easy Windows local-admin bypass path.

That is the right way to think about it: not one perfect feature, but several controls that force the attacker to keep solving harder problems.

Final thoughts

The biggest mistake solo admins make with 4-Eyes Authorization is assuming it is meant for someone else.

It is not. If one person holds most of the operational access, then one compromised credential can do disproportionate damage. That is exactly the environment where you want a second approval boundary in place.

The feature is straightforward. The hard part is deciding who the second identity should be and making sure that identity is genuinely separate from your normal admin path. Get that right, pair it with MFA, and test it once end to end. After that, you are no longer depending on one credential to protect the last copy of your data.