Veeam Backup & Replication SAML SSO with authentik

How authentik SAML SSO works for Veeam backup administrators

authentik acts as the SAML identity provider for the Veeam Backup & Replication console, and the integration guide in the authentik integrations catalog walks through the pairing. Backup administrators who sign in with local Veeam accounts today would instead authenticate against authentik, which holds the user records, group membership and the second factor. The practical change is that you gain one place to disable an administrator, review who has access and enforce MFA, because the Veeam console trusts authentik's assertion rather than storing its own password for each person. Before you start, confirm in the guide and against the Veeam version you have installed which SAML settings the console exposes, since the exact field names and the way Veeam maps SAML attributes to its roles must come from that documentation rather than from this page.

SAML sign-in does not replace everything in the Veeam console. Keep at least one local administrator path that works when authentik, its database or the network path to it is unavailable, and test that path before you enforce SSO. Licensing is also unaffected by the sign-in method. Veeam's documentation states that Veeam Backup and Replication consumes licenses only to back up data and that restores do not require licenses, so an authentication outage does not change your ability to recover VMs and data through the console. For a separate recovery route, Veeam's extract utility can recover machines from backup files without any interaction with Veeam Backup and Replication, and it can be downloaded separately with a registered Veeam account. Plan that route as part of your recovery runbook, not as a dependency on SSO.

Treat the SAML setup as a change to the backup control plane. Record the authentik application, the signing certificate and its expiry, and the Veeam settings you changed, and confirm with your Veeam partner or the vendor documentation how the console behaves during certificate rotation. Ask your team to verify the sign-in flow with a non-production test account, then with a named administrator, before you remove or restrict local logins. Because backup administrators hold high-impact rights, the MFA requirement should be enforced in authentik for the groups that can reach the console, and that enforcement should be checked from the user side each time the policy changes.

Versions, licenses and access needed before the SAML setup

Four things must be settled before anyone opens an admin console: which authentik release you run, which Veeam Backup & Replication version and license you run, how the two endpoints resolve and present certificates, and who holds administrative access on each side. Each card below names the check and where to make it, so the SAML work starts from a supported and reachable baseline.

Supported authentik release

The authentik security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Confirm that your running instance sits on one of those lines before you add a SAML provider, and plan any upgrade ahead of the Veeam work rather than during it. Check the installed version under the admin interface and compare it with the security policy page.

Supported Veeam Backup & Replication version

Veeam lists version 13 as released in November 2025 with support and security fixes until November 2028, and version 12 with support until February 2027. Choose the version you will configure against and confirm the date on Veeam's lifecycle page. A SAML setup on a release that is near end of support creates rework when the next upgrade arrives, so check the date before the change window is booked.

License or Community Edition limits

Veeam Backup and Replication runs as the free Community Edition without a license key, and that edition is limited to 10 workloads. Count the VMs, hosts, Windows and Linux servers and NAS devices you protect, then confirm whether a paid license covers them. Veeam states that restores do not require a license, but backups do, so a lapsed license can stop protection even while the SAML login still works. Ask your Veeam partner or account team which license type fits your renewal cycle.

DNS and TLS for both endpoints

Give the authentik side and the Veeam console stable fully qualified names, each resolvable from the administrator workstations that will sign in. SAML relies on the browser reaching both endpoints over TLS, so confirm that certificates chain to a trust store the Veeam server and client machines accept. Record the authentik issuer URL and the Veeam console address now, because the SAML metadata and redirect URLs depend on them and changing either later means reconfiguring both sides.

Administrative access on authentik

Confirm that you hold an administrator account in authentik that can create providers, applications and groups, and that a second administrator exists for recovery. Check the permissions on the authentik admin interface before work starts so you are not blocked mid-change. Keep a separate local path to the Veeam console for emergencies so a broken SAML configuration does not lock every backup administrator out.

Administrative access on Veeam

Confirm that a Veeam administrator can edit the SAML identity provider settings and that the local Veeam administrator account is documented and tested. The Veeam server is the component that must accept the SAML response, so the person making the change needs console rights on that server, not only on authentik. Schedule the change in a window where a backup administrator can fall back to local sign-in if the first login attempt fails.

Configuring the authentik SAML provider and the Veeam identity provider

This sequence connects Veeam Backup & Replication to authentik over SAML so backup administrators sign in with their directory identity. It produces a SAML provider and application in authentik, a configured identity provider in Veeam, and group-based access that is verified with a non-admin account before production users are moved.

Create the SAML provider in authentik
Using the authentik integrations guide for Veeam Backup & Replication as the reference, a platform or identity engineer creates a SAML provider and an application in authentik. Record the entity ID, the assertion consumer service URL and any other endpoint values the guide specifies, then bind the provider to the authorization flow your administrators already use. Done when the provider and application appear in the authentik admin interface with the values from the guide and no placeholder text remains.
Record the metadata and entity values
Copy the provider's metadata location and entity ID into your change record, along with the signing certificate details and its expiry date. Open the metadata URL from a browser on the backup management network and confirm it returns XML. Done when the entity ID in the XML matches the value you entered in authentik character for character, because a mismatch is one of the most common causes of failed SAML logins.
Configure the identity provider settings in Veeam
A Veeam administrator enters the authentik values into the SAML single sign-on settings of the Veeam Backup & Replication console. Confirm the exact settings screen and field names in Veeam's user guide for your installed version, since the console layout differs between releases. Keep at least one local administrator account available for recovery before saving. Done when the settings save without error and the login page offers the SSO option while local sign-in still works.
Map authentik groups to Veeam roles
Assign the authentik groups that should have backup console access to the application, and configure the group attribute in the SAML assertion as the guide describes. On the Veeam side, map each group to the role it should receive, starting with the least privileged role that meets the need. Done when a SAML assertion captured with a browser tracing tool or the authentik preview shows the group attribute with the expected group names.
Test with a non-admin account
Create a test user in authentik, add it to a group mapped to a limited Veeam role, and sign in through the SSO option. Confirm the session opens with the expected role and no administrative rights. Then sign in with a user outside the mapped groups and confirm access is refused. Done when the in-group test user signs in with the correct role, and the out-of-group user is denied, with both results recorded in the change record.
Move production access after testing
Add production administrator groups in controlled batches, informing the affected administrators of the new sign-in path and keeping the local recovery account documented. Confirm that the authentication flow applied to the application is the one you intend, since MFA enforcement is configured on that flow in the next section. Done when each production administrator signs in successfully, the recovery account still works, and the final group-to-role mapping matches the approved access design.

Mapping authentik groups and attributes to Veeam roles

This table compares each SAML attribute authentik sends with the Veeam role or user setting it should feed, who owns that mapping, and what happens when a group is removed. Confirm every attribute name and role option against the Veeam Backup and Replication version you run and the current authentik Veeam guide before you build the mapping.

Attribute or item	Veeam setting it feeds	Mapping owner	Handling when removed
User identifier (NameID)	Veeam user account matched at first SAML sign-in	Identity team, with the backup administrator lead confirming account names	Disable the authentik user; remove the matching Veeam account or role through the backup team's change record
Display name attribute	Display name shown in Veeam console sessions and audit entries	Identity team	Updates on next sign-in; no access change, so confirm it is cosmetic in your version
Email attribute	Contact address for the account, where the Veeam role mapping uses it	Identity team	Remove on user offboarding; confirm whether Veeam requires it for account creation
Group membership attribute (Veeam Backup Administrators group)	Veeam role with full backup console rights	Backup administrator lead approves; identity team maintains the authentik group	Membership removal blocks new sign-ins to that role; review active sessions and existing role assignments
Group membership attribute (Veeam Restore Operators group)	Veeam role limited to restore tasks, if your version offers that role	Backup administrator lead approves; identity team maintains the authentik group	Remove the group from the assertion; confirm whether Veeam keeps the assignment until it is cleared in the console
Group membership attribute (read-only or auditor group)	Read-only or reporting role, if available in your edition	Security or compliance team approves; identity team maintains the group	Remove from the group and recheck the role list after the next sign-in
Attribute name in the assertion	Must match the attribute name the Veeam guide expects	Identity team with the Veeam administrator	Re-test after every authentik or Veeam upgrade, since attribute names can change
Empty or missing group claim	Access denied or fallback account, depending on Veeam's behavior	Veeam administrator confirms behavior; identity team tests it	Keep a documented local recovery account, and confirm its status before you enforce SSO

Why MFA belongs in front of the backup console

The backup console deserves a stronger sign-in than most internal tools because the people who use it can change what the business can recover. A backup administrator who can alter retention settings, remove restore points or change repository configuration holds a lever that matters most during an attack, when an intruder with a stolen password would want exactly that access. Putting multi-factor authentication in front of the Veeam Backup & Replication login closes the gap between a password and the console. In this integration, the check happens in authentik, not in Veeam, so the control applies to every SAML sign-in that authentik issues for this application.

The enforcement point matters for how you configure it. authentik runs the authentication flow for the SAML provider, and MFA is a stage in that flow that must succeed before authentik issues the SAML assertion Veeam relies on. Veeam receives an assertion only after the user has passed the flow, so the console inherits the second factor without a separate Veeam setting. Confirm this behavior in your own environment by signing in with a test account that has no second factor enrolled and checking that the flow prompts for enrollment or blocks access, as your policy requires. Also confirm which factors your administrators can use, whether enrollment is self-service or handled by an administrator, and what happens when a device is lost.

MFA configuration itself is covered on the authentik MFA and passwordless pages, so this section does not repeat the factor options. Before rollout, verify the MFA stage, the flow binding to the SAML provider and the recovery path in a staging instance that mirrors your production authentik version. Also keep a break-glass local Veeam administrator documented and tested, so that a failed identity provider or a misconfigured flow does not lock every operator out of the console during an incident.

Hardening the SAML path and keeping recovery access

The SAML sign-in path decides who can reach the Veeam console, so its trust material, group scope, session length and logs need the same care as the backup repositories behind it. The cards below cover the controls to set before go-live and the checks to repeat after each authentik or Veeam upgrade. Confirm each setting against the authentik and Veeam versions you have actually installed.

Signing and certificate handling

Decide whether authentik signs SAML assertions and responses, which key pair it uses, and who holds the private key. Store the signing certificate in a managed secret store, restrict read access to the authentik operators, and copy only the public certificate into the Veeam identity provider settings. Confirm the signature options the SAML provider offers in your authentik version and whether Veeam validates signatures on both assertions and responses.

Certificate rotation and expiry tracking

A SAML signing certificate that expires without warning locks every administrator out of the console at once. Record the certificate validity dates, set a rotation date well before expiry, and plan the change as a two-step update in which the new public certificate is accepted in Veeam before authentik starts signing with it. Test the rotation in a non-production Veeam server first.

Limiting which groups reach the console

Bind the SAML application in authentik to a group or policy that contains only backup administrators and operators, so a valid account outside that group cannot start a sign-in. Map Veeam roles from groups only for the roles you intend to grant, and keep the default role as the lowest privilege. Confirm that unassigned users are denied at the authentik application level and that Veeam does not grant a default role to first-time SAML users.

Break-glass administrator held offline

Keep one local Veeam administrator account that does not depend on SAML, with a long unique password stored offline in a sealed, access-logged location. Test it at least once after go-live so the recovery path is known to work before an outage. Keep the account disabled for daily use and document who may unseal it and under what approval.

MFA on the authentik sign-in path

Require a second factor in the authentik flow bound to the Veeam application, so a stolen password alone does not open the backup console. Choose a factor that your administrators can use during an incident, and confirm that the stage applies to the SAML application rather than only to the general login page. Review how the factor behaves when an administrator has no device available.

Session timeouts on both sides

Set the authentik session length for the Veeam application and the inactivity timeout in the Veeam console separately, because a long authentik session can outlive the Veeam one. Choose values that suit an administrator working through a restore, and shorten them for privileged roles. Confirm how each product handles re-authentication after the session ends.

Audit logging of console logins

Forward authentik sign-in events for the Veeam application and the Veeam console logon records to the same log platform, so one investigation can match an authentik login to the Veeam session it created. Confirm which events each product records, how long they are kept, and whether the Veeam event log captures SAML-based logons and failed attempts.

Common SAML failures on the Veeam console and their fixes

This table lists the SAML sign-in failures most likely to block backup administrators on the Veeam console, with the likely cause, how to confirm it and the fix for each. Work through the rows in order when sign-in fails, and use the break-glass path to recover access if the identity provider is unavailable.

Failure	Likely cause and how to confirm	Fix and recovery path
Assertion rejected with a time or validity error	Clock skew between the authentik server, the Veeam backup server and the browser client. Confirm by comparing UTC time on each host and reading the assertion NotBefore and NotOnOrAfter values in the SAML trace.	Synchronize all hosts with NTP and retry. Keep the local Veeam administrator account available so an administrator can sign in while clocks are corrected.
Entity ID or ACS URL mismatch	The entity ID or assertion consumer service URL in the authentik SAML provider does not match the values Veeam expects. Confirm by comparing both values character by character, including scheme, host and trailing slash.	Copy the values from the Veeam identity provider settings into the authentik provider and save both sides. Retest with a single administrator account before rolling out to the team.
Signing certificate expired or replaced	The certificate in Veeam no longer matches the certificate authentik uses to sign assertions. Confirm by checking the certificate validity dates in authentik and the certificate stored in Veeam.	Import the current signing certificate into Veeam. Schedule a reminder before expiry and record which certificate is active so the change is tracked.
Signed in but no Veeam role or access	The user's group or attribute did not map to a Veeam role, so the account has no effective permissions. Confirm by checking the attributes sent in the assertion and the role mapping on the Veeam side.	Map the authentik group to the intended Veeam role and have the user sign in again. Keep role assignments documented so backup operators are not granted broader rights by default.
Redirect loop after a DNS change	The Veeam console or authentik still points to the old hostname, or the browser holds a cached redirect. Confirm by checking DNS resolution from the client and the Location headers returned during sign-in.	Update the hostnames in both the Veeam settings and the authentik provider, then clear cached sessions. Confirm the new name resolves consistently on every network path.
Lockout after incomplete MFA enrollment	The user started MFA enrollment but did not finish it, so the flow blocks sign-in. Confirm by reviewing the user's enrollment state in authentik and the event log for the failed attempts.	Reset the enrollment for that user in authentik and have them enroll again while supervised. Use the break-glass local administrator account on the Veeam server to recover access, then rotate its credentials.
Identity provider unavailable during an incident	authentik is down, unreachable or misconfigured, so no SAML sign-in succeeds. Confirm by testing the authentik endpoint from the backup network and checking the authentik server and worker health.	Use the break-glass local Veeam account, which should be stored under documented controls and tested before it is needed. Restore authentik, then verify SAML sign-in before closing the incident.

How the Veeam version and license model change the work

A new deployment starts on the current major version. Veeam Backup and Replication 13 was released in November 2025 and receives support and security fixes until November 2028, so the SAML integration can be designed once against the version you will run for the planned lifecycle. Licensing shapes the scope less than you might expect, because SSO sits in front of the console and does not change what the backup server protects. Confirm your license model before you size the environment, since per instance, per capacity and per socket licensing count differently.

Version choice: Build against Veeam 13 and record the November 2028 end of support in your lifecycle register.
License model: Per instance, per capacity or per socket. Socket licensing is not available with a Linux-based backup server, so a Linux build rules that model out.
Workload count: Per capacity licensing is metered by workloads, so the number of protected VMs and servers drives the license quote, not the number of administrators you sign in.
Edition: Prices are on request from Veeam, so request a quote for the edition and workload count you plan to run.
Restore: Restore does not require a license, so an SSO outage or license lapse should not block recovery work.

Confirm the license model, workload count and Linux or Windows backup server choice with Veeam before you finalize the SAML design.

What buyers ask before hiring help with Veeam SSO

How much does it cost to put Veeam Backup & Replication behind authentik SSO?

The price depends on the written scope, so no figure is given here. Cost has three parts: the DeployOpen fixed-scope fee for the work agreed in writing, the authentik licensing you choose, and the Veeam licensing you already hold or buy. Ask for the quote to list each item separately, state what is one-time (design, configuration, testing, handover) and what recurs (support or retainer, if you add one). Ask which SAML settings and identity provider steps are covered, and whether MFA setup is included.

How long does a Veeam SAML integration project take?

No duration is supplied for this integration, so confirm it in the written scope rather than relying on a general estimate. Duration depends on how many Veeam consoles you run, whether authentik is already in production, how many groups map to Veeam roles, and how quickly your team can approve a test window. Ask for the timeline to show separate milestones for the authentik SAML provider, the Veeam identity provider settings, MFA enforcement and a test sign-in with a break-glass account.

What does our team need to provide for the Veeam SSO work?

Expect to supply access and decisions rather than code. You will need an administrator for the authentik instance, an administrator for the Veeam Backup & Replication server, a list of groups that should map to Veeam roles, and a named owner who approves the change window. Your team should also confirm the external URL Veeam will use and the certificate chain for authentik. Ask the provider to list these inputs in the scope so gaps are found before work starts.

Can our own team set up Veeam SSO with authentik without a partner?

Yes, if you have people who administer both authentik and Veeam and can test sign-in safely. The SAML path touches identity, the backup console and access control, so the risk is in mistakes rather than complexity. Ask yourself whether you can run a test sign-in without locking out every administrator, keep a local account for recovery and document the mapping. Hiring help makes sense when those skills are thin or when the change must be proven to an auditor.

Do we need Enterprise authentik features for the Veeam SAML path?

Confirm this before buying anything. The authentik pricing page lists Enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management, password history, enhanced audit logging and ticket-based support. None of these is named as required for the SAML provider in the supplied material, so check the authentik integration guide and your own requirements. Enterprise audit logging or privileged access features may matter to your compliance team even if SAML itself works on Open Source. The project's code is MIT licensed except for the enterprise directory, which has its own license.

What happens to backup restores if SSO fails?

Restore does not depend on Veeam licensing, but it can depend on sign-in. Veeam Backup & Replication consumes licenses only to back up data, and restore does not require licenses. Sign-in to the console, however, can fail if authentik is down or the SAML configuration is wrong. Ask the provider to document a break-glass path, such as a local Veeam administrator account kept outside SSO, and to test a restore through that path before cutover. Confirm where that account's credentials are stored and who can reach them during an outage.

Which Veeam licensing and version should we confirm before the SSO work?

Confirm your Veeam edition and version first, because SSO work is wasted if the console is unsupported. Veeam Backup and Replication 13 has support and security fixes until November 2028, and version 12 until February 2027. Without a license key the product runs as Community Edition, which is limited to 10 workloads. Subscription licenses are normally 1 to 3 years, and perpetual licenses typically include one year of support. Confirm your current entitlements with Veeam, since prices are on request.

How DeployOpen scopes and delivers the Veeam SAML integration

DeployOpen plans and builds the authentik and Veeam Backup & Replication SAML integration inside your own infrastructure, starting from a written scope that names the SAML provider, Veeam identity provider settings and MFA requirements. Work is documented and handed over to your backup administrators so the console keeps working after the engagement ends.

How we scope

Written scope lists the authentik SAML provider, Veeam identity provider settings and the MFA policy to be enforced
We confirm your Veeam Backup & Replication version and the authentik release running in your environment before work starts
We agree which administrator groups map to Veeam roles and which local accounts stay as break-glass access
Engagements are fixed-scope, with deliverables and timelines agreed in writing before the build begins

How we build

We configure the authentik SAML provider and application for the Veeam console in a non-production environment first
We set up Veeam identity provider settings and test sign-in for each administrator group, including MFA prompts
We run failed-login and lockout scenarios to confirm the local fallback account still works
We record each configuration value and its owner so changes can be reviewed later

How we hand over

Documentation covers the SAML configuration, certificate locations, group mappings and the MFA enforcement path
We walk your backup and identity teams through sign-in, role mapping and the break-glass procedure
Runbooks describe what to check when sign-in fails and who to contact on each side of the integration
We hand over the production change only after your team has tested sign-in and accepted the documentation

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
A support retainer can cover reviews when authentik or Veeam Backup & Replication releases change SAML behavior
Ask whether your retainer includes testing of the MFA path and the break-glass account after each change
Quotes follow from the written scope, so ask for each deliverable and its acceptance step to be listed separately

authentik and Veeam Backup & Replication SAML integration