Something strange is happening in your infrastructure:

Someone wants to enable SSH?
Obtain temporary root access?
Change security-critical settings without your knowledge?

Who you gonna call? Ghostbus... uh, no: the Security Officer of course.

With Veeam v13, this new role has been introduced for the Veeam Software Appliance and the Veeam Infrastructure Appliance.

However, what may initially sound like the supreme ghost hunter—uh, I mean security chief — for the entire Veeam environment is often misunderstood. The Security Officer neither manages backup jobs nor automatically approves the deletion of backups.

Its actual purpose is much more specific: It ensures that particularly critical changes to the appliance cannot be performed by a single person. The Security Officer approves or rejects requested actions.

But when do you really need this role? What is the difference between the Security Officer, MFA, and Four-Eyes Authorization? And why is this role particularly relevant for VBR and VIA repositories? We will get to this in this blog…

 

But first, a few quick facts.

1. What Is the Security Officer?

The Security Officer is a dedicated local role within the Veeam Host Management Console — not the VBR console or VBR web UI. The default account for this role is named veeamso.

Its purpose is to enforce separation of duties.

This means that a person with the Host Administrator role must not be able to perform particularly security-sensitive changes alone. The Host Administrator initiates the action, and the Security Officer approves or rejects it.
 

The main roles are therefore divided as follows:

• The Host Administrator administers the appliance.
• The Security Officer controls particularly critical changes to the environment.
• A Backup Administrator manages Veeam Backup & Replication.
• A VBR Security Administrator controls security-related VBR functions, for example as part of Four-Eyes Authorization.

The Security Officer can also:

• approve or reject authorization requests
• view and export appliance and security events
• process remote password reset requests
• use or renew their own recovery token
• manage passphrases for encrypted configuration backups

However, the Security Officer cannot manage local users and does not have access to the text-based Host Management Console (TUI).

The Security Officer is a control account for the appliance layer — not a universal security administrator for the entire Veeam environment.

Sources:
Configuring Users · Performing Security Officer Tasks

 

2. Must the Security Officer Always Be Enabled?

No. During installation, the configuration of the Security Officer can generally be skipped.

However, this decision has an important consequence:

If you skip the Security Officer during installation, you cannot simply enable it later. To activate it afterward, you must reinstall the appliance and perform the initial configuration again.

For this reason, the decision should not be based solely on the current operational overhead. You should also consider future compliance requirements, separation of duties, and privileged-access controls.

There is one important exception: a Veeam Hardened Repository without MFA.

For a VIA ISO installation using the Veeam Hardened Repository role, the following rule applies:

• If MFA is disabled, a Security Officer must be configured. In this configuration, the Security Officer cannot be skipped.
• If a Security Officer has been configured, the default account must be initialized before the Hardened Repository can be added to Veeam Backup & Replication.

Source:
Configure Security Officer Account for VIA

Practical recommendation

A Security Officer should be configured if at least one of the following conditions applies:

• Regulatory requirements demand separation of duties
• Root or SSH access must be controlled
• The appliance stores backup data as a Linux repository
• The appliance serves as a Hardened Repository
• A compromised administrator must not be able to disable all protection mechanisms alone
• Remote password recovery without LiveOS should be possible

Skipping the Security Officer may be acceptable in a small test or lab environment. For production environments, however, you should make a conscious decision and document it properly.

 

3. If I Do Not Enable MFA, Do I Need a Security Officer?

MFA and the Security Officer serve two different purposes.

MFA protects the identity of an account

MFA makes it more difficult to use stolen or guessed credentials. In addition to the password, an attacker needs another authentication factor.

The Security Officer protects administrative workflows and actions

The Security Officer prevents a Host Administrator from performing certain security-sensitive actions alone — even if the Host Administrator’s login is completely legitimate.

These two mechanisms are often confused, but both are important and relevant.

MFA protects against account misuse.

The Security Officer protects against the misuse of administrative privileges.

Without MFA, configuring a Security Officer becomes even more important. However, the Security Officer does not replace MFA.

If an attacker compromises the credentials of both the Host Administrator and the Security Officer, this control layer has also been defeated.

For a VIA deployed with the Hardened Repository role, the Security Officer is mandatory if MFA is disabled. For other appliance roles, the Security Officer can generally be skipped.

Sources:
Managing User Authentication · Initial Security Officer Login

 

4. Which Actions Require Security Officer Approval?

The Security Officer does not block all appliance administration. It is used selectively for particularly sensitive operations.

Documented authorization requests include, among others:

• enabling SSH
• stopping a Veeam service
• granting temporary access to the root shell
• performing a remote password reset for a locked-out user
• importing configuration files
• changing domain membership
• adding another Security Officer account
• allowing remote connections for Veeam management agents
• allowing a backup server to join a high-availability cluster
• disabling Backup Infrastructure Lockdown
• changing the Host Management Console certificate
• adding a trusted certificate
• changing the FIPS mode
• enabling the management of iSCSI or Fibre Channel storage
• enabling Application Backup Repository Mode on a Hardened Repository
• performing certain configuration restore and infrastructure operations (e.g. changes to immutability settings,…)

Root access is a good example.

When a Security Officer is configured, the Host Administrator can only request root access. The Host Administrator receives time-limited access to the TUI root shell only after the Security Officer has approved the request.

Without this additional role, users with the required privileges can perform these actions immediately.

Sources:
Performing Security Officer Tasks · Configuring Remote Access · Configuring Backup Infrastructure Settings

 

5. Data Deletion and Four-Eyes Authorization

This is probably the most common misunderstanding.

Some people confuse two different mechanisms and assume that the Security Officer also prevents backup data from being deleted from a repository.

However, the Appliance Security Officer is not the “second approver” for deleting backups in Veeam Backup & Replication.

These are two separate control mechanisms.

Appliance Security Officer

The Appliance Security Officer controls security-sensitive operations in the Host Management Console. These include, for example, root & ssh access, certificates, storage configuration, appliance configuration changes

Four-Eyes Authorization in VBR

Four-Eyes Authorization operates within Veeam Backup & Replication. It requires additional approval from another user with the Backup Administrator or Security Administrator role.

It is used when a user wants to perform actions such as:

• deleting backup files or snapshots
• removing unavailable backups from the configuration database
• removing repositories or storage systems from the backup infrastructure
• adding, changing, or deleting users and groups
• making global MFA changes or performing MFA resets
• changing automatic logoff settings
• disabling immutability or shortening the immutability period on Linux or Hardened Repositories
• performing certain Cloud Connect operations

An administrator who created a request cannot approve their own request. However, they can delete or withdraw the request.

To protect against data deletion, three mechanisms should generally be considered separately.

1. Immutability
   As long as immutability remains active, protected backup files cannot be deleted even with Four-Eyes Authorization.
2. VBR Four-Eyes Authorization
   Once the immutability period has expired, or for data outside the scope of immutability, Four-Eyes Authorization prevents a single person from deleting data through VBR without additional approval.
3. Appliance Security Officer
   The Security Officer controls changes to the operating system and the appliance itself. It therefore helps protect against attacks that attempt to bypass security mechanisms or increase the attack surface.

It is also important to understand a documented limitation: VBR Four-Eyes Authorization alone cannot protect the infrastructure if the backup server has been completely compromised.

It therefore does not replace a hardened architecture, immutability, or administrative separation.

Source:
Four-Eyes Authorization

 

6. Can the Security Officer Log In to Veeam Backup & Replication?

No — at least not based solely on the Security Officer role.

An account with the Appliance Security Officer role cannot be assigned a Veeam Backup & Replication role. The account can log in only to the web-based Veeam Host Management Console, not to the VBR console.

The Security Officer also has no access to the administrative Host Management TUI.

The Security Officer therefore cannot use this role to:

• manage backup jobs
• perform restores
• remove VBR repositories
• delete backups
• approve VBR Four-Eyes requests
• manage VBR user roles

Of course, the same real person can be given a separate VBR user account. However, this should be carefully evaluated from a separation-of-duties perspective.

If the Security Officer is also a Backup Administrator, the organizational separation is significantly weakened.

Source:
Configuring Users

 

7. Can the Security Officer Reset a Password?

The short answer is yes—but only through clearly defined workflows.

Remote reset for a Host Administrator

If Remote Password Reset is enabled in the password policy, a Host Administrator can select Forgot password? on the login page and submit a password reset request.

The Security Officer can approve or reject this request.

If the request is approved, the Security Officer can set a temporary password. The Security Officer must then communicate this password to the user through a secure communication channel.

At the next login, the user must change the temporary password and, if necessary, configure MFA again.

The Security Officer therefore cannot arbitrarily change passwords through a general user-management interface. The Security Officer processes a reset request initiated by the affected user.

The Security Officer’s own password

The Security Officer can change their own password.

If the Security Officer forgets the password, the account becomes locked, or MFA is no longer available, they can use the recovery token generated during account initialization.

For this reason, the recovery token must be stored securely and separately from the appliance. During setup, you should not simply click Next without recording and securely storing the token.

What can the Host Administrator do?

A Host Administrator can reset the passwords of other local users and other Host Administrators.

However, the Host Administrator cannot reset the password or MFA configuration of a Security Officer. The Security Officer must use their own recovery token for that purpose.

What happens without a Security Officer?

If only a Host Administrator exists and no Security Officer has been configured, there is only one recovery path for a lost password: Veeam LiveOS.

LiveOS can be used to change the password of a local account. However, this does not automatically reset MFA.

Additional restrictions apply to resetting MFA. A Security Officer can recover their own MFA configuration only by using their recovery token.

Sources:
Managing User Authentication · Performing Security Officer Tasks · KB4761: How to use Veeam LiveOS ISO

 

8. When Is the Security Officer Useful on a VIA?

The importance of the Security Officer depends heavily on the role assigned to the Veeam Infrastructure Appliance.

VIA Proxy-only appliance

A proxy-only appliance does not store backup data. Its direct value in protecting stored backups is therefore lower than it would be for a repository.

Nevertheless, the Security Officer can still be useful because an attacker could exploit a compromised proxy to:

• use it as a starting point for lateral movement
• monitor or disrupt backup traffic
• gain unauthorized access to production systems
• manipulate the proxy through root, SSH, or certificate changes

For small and isolated proxy environments, the additional approval process may create more operational overhead than security value.

In larger or regulated environments, however, it provides consistent separation of privileged actions.

Assessment: Useful, but not mandatory in every scenario.

VIA as a standard Linux repository

The importance of the Security Officer increases significantly when the VIA is used as a repository.

The appliance has access to stored backup data and the underlying storage.

In this scenario, the Security Officer protects particularly against unilateral actions such as:

• enabling root or SSH access
• making storage changes
• changing certificates
• importing configurations
• weakening certain appliance protection mechanisms

However, the Security Officer does not automatically turn a standard Linux repository into a Hardened Repository. It also does not, by itself, guarantee protection against the deletion of backup data through VBR.

Additional controls are required, including:

• an appropriate repository architecture
• immutability
• VBR Four-Eyes Authorization
• separate administrative accounts
• secure network segmentation

Assessment: Clearly recommended.

VIA as a Hardened Repository

The Security Officer provides its greatest value on a Hardened Repository.

The very purpose of a Hardened Repository is to minimize administrative access and the ability to manipulate backup data.

The Security Officer makes the following actions more difficult to perform without oversight:

• uncontrolled root access
• uncontrolled activation of SSH
• security-sensitive storage changes
• adding additional privileged Security Officer accounts
• expanding the attack surface through additional repository functions

For Hardened Repositories, Veeam also recommends disabling the Host Management Console web interface to reduce the attack surface further.

The following points are particularly important:

• If MFA is disabled on a VIA with the Hardened Repository role, the Security Officer is mandatory.
• A configured Security Officer must be initialized before the repository can be added to VBR.
• The Security Officer does not replace immutability.
• Even an approved VBR Four-Eyes request cannot delete immutable backup files during their protection period.

Assessment: Very strongly recommended and mandatory in certain configurations.

Sources:
Using VIA as Hardened Repository · Hardened Repository Requirements and Limitations

 

9. Which Threats Does the Security Officer Protect Against?

The Security Officer specifically reduces the risks associated with the following threats.

Compromised Host Administrator credentials

An attacker who has obtained the Host Administrator’s password cannot immediately perform certain critical actions. The attacker also needs approval from the Security Officer.

Insider threats and human error

Even a legitimate administrator cannot accidentally — or intentionally — enable root access, SSH, or other particularly sensitive functions alone.

Uncontrolled expansion of the attack surface

Additional remote connections, certificates, management agents, or repository functions can be subject to a second approval step.

Loss of the only Host Administrator account

The Security Officer provides a controlled remote password reset process, avoiding the need to immediately resort to LiveOS.

Appliance manipulation below the VBR layer

VBR roles protect the application layer, while the Security Officer addresses security-sensitive changes to the appliance and its operating system.

10. What Does the Security Officer Explicitly Not Protect Against?

The Security Officer is not a complete security solution.

It does not automatically protect against:

• compromise of both administrative roles
• stolen Security Officer credentials and MFA factors
• deletion through VBR when Four-Eyes Authorization is not enabled
• data deletion after the immutability period has expired
• attacks against storage or virtualization layers outside the appliance
• organizational weaknesses where the same person controls all roles and credentials

The Security Officer should therefore be part of a layered security model.

Recommended controls include:

• separate identities
• MFA
• least privilege
• the Security Officer role
• VBR Four-Eyes Authorization
• immutable backups
• network segmentation
• secure and separate storage of recovery tokens
• centralized audit and event monitoring
  
   

Conclusion

The Security Officer in Veeam v13 is a control function for the appliance layer. It prevents a Host Administrator from performing particularly security-sensitive changes alone.

Its greatest value does not lie in day-to-day backup administration, but in protecting the underlying system:

• Who is allowed to enable SSH?
• Who approves temporary root access?
• Who authorizes security-sensitive infrastructure changes?
• Who helps recover a locked-out Host Administrator account?
   

Four-Eyes Authorization is responsible for controlling data deletion within Veeam Backup & Replication. For the actual protection of backup files, immutability remains the decisive technical barrier.

These are three important security functions that complement one another. This combination provides its greatest value when used with a Hardened Repository. Together, these controls help ensure that compromising a single account is not enough to turn a hardened backup target back into an ordinary Linux system with extensive administrative access.