Your backup console is one of the most valuable login pages in your organization, and it should not be guarding itself with a password of its own.

Think about what sits behind that login. A backup console knows every machine you protect, where their data is stored, when the last backup ran, and often how to reach those machines remotely. For an MSP, it is the one place that touches every customer tenant at once. Attackers understand this: in a modern ransomware incident the backups are hit first, so that recovery is off the table before the encryption starts. The console that manages those backups is the shortest path to them.

A product that stores its own usernames and passwords adds a second, weaker front door to that target. Every password database is a liability: it has to be hashed correctly, protected against stuffing and brute force, paired with its own MFA, and purged of accounts that should no longer exist. Most vendors get some of this right. Very few get all of it right, and every one of them is now maintaining security infrastructure that has nothing to do with backups.

The better design is to not have the door at all. Federated login means the backup console never sees a password: users sign in through an identity provider they already trust, and the console only receives a signed assertion that this person is who they say they are. The three sections below explain why that is a security win, not just a convenience.

No password database to breach

The simplest way to protect a secret is to never hold it. A console that stores no passwords has nothing to leak when a database is exposed, no hashes to crack offline, and no credential set for attackers to replay against the thousands of other services where people reuse the same password.

This matters more than it sounds. Credential stuffing is cheap and automated: lists of leaked email-and-password pairs are tested against every login page on the internet, and backup consoles are on those lists. A vendor that keeps its own password store has to defend against that traffic forever, with rate limiting, lockouts, breach-list checks and incident response, all on a product whose actual job is backups.

With federated login the attack surface moves to GitHub, Google, Apple or your own identity provider. Those organizations run dedicated security teams, see attack patterns across billions of logins, and detect anomalous sign-ins in ways no backup vendor can match. The console inherits that defense without reimplementing any of it.

It also changes what a breach of the console itself would mean. If an attacker gets read access to the console's database, they find user identifiers and organization membership, not credentials. There is nothing to escalate with, and nothing that has to be rotated across every customer.

MFA inherited from the identity provider

Multi-factor authentication is only as good as its enforcement, and enforcement is hard to get right in a product that bolts it on. A console with its own password store has to build MFA enrollment, backup codes, recovery flows, device trust and admin overrides, and then convince every user to turn it on. In practice, optional MFA means partial MFA, and partial MFA means the weakest account is the one an attacker uses.

Federated login sidesteps the problem. If your identity provider requires a hardware key, a passkey, or an authenticator app, then signing in to the backup console requires it too. The policy lives in one place, applies to every application, and is already something your security team monitors and reports on. The backup console cannot be the exception, because it has no login of its own to be exceptional with.

The same goes for the controls that sit next to MFA. Conditional access rules, such as blocking sign-ins from unmanaged devices or unexpected countries, impossible-travel detection, and session lifetime limits all apply automatically. When your identity provider adds a new control, the console gets it the same day, with no vendor update required.

For an MSP this is the difference between asking every technician to enable MFA in every tool and enforcing it once in the directory that everyone already logs in through.

Offboarding handled in one place

The most common way a former employee keeps access to a system is that nobody remembered the system existed. Backup tools are a classic example: set up once, rarely touched, and absent from the offboarding checklist. An account in a standalone password store stays valid until someone finds it, and a disgruntled ex-admin with a working backup login is one of the worst insider scenarios a company can face.

When the console authenticates through your identity provider, disabling the user there ends their access to backups at the same moment it ends their access to email. There is no separate account to hunt for, no shared password that has to be rotated because one person left, and no service account quietly outliving its owner. Role changes work the same way: move someone to a different group in the directory and their console permissions follow.

This is also what auditors ask for. SOC 2, ISO 27001 and HIPAA reviews all want evidence that access is removed promptly when people leave. Pointing to a single identity provider with a documented joiner-mover-leaver process is a much shorter conversation than producing user lists from a dozen separate tools and proving each one was cleaned up.

For MSPs the benefit compounds. A technician who leaves the MSP loses access to every customer tenant at once, from one change, instead of one deprovisioning task per customer.

Customer SSO: the procurement checkbox that is actually about risk

If you have ever filled in a vendor security questionnaire, you know the line: does the product support SSO with our identity provider? It reads like a convenience feature. It is on the questionnaire because every point above is a risk the buyer would otherwise have to own.

Social sign-in with GitHub, Google or Apple solves the problem for small teams and individual operators, who already have a well-protected account with one of those providers. Larger organizations need the same thing against their own directory, whether that is Microsoft Entra ID, Okta, Google Workspace or another OpenID Connect or SAML provider. That is what customer SSO delivers: your users, your groups, your MFA policy, your offboarding, applied to the backup console without a single credential being created inside it.

Watch for two things when evaluating a vendor. First, whether SSO is a paid tier or a default. Charging extra for SSO pushes the least-resourced customers toward the least secure login, which is backwards for a security product. Second, where any email-and-password option actually lives. A password form the vendor built and stores itself is the weak door this article is about. A password account held by a dedicated identity service, with MFA enforced on every account and no credentials in the backup product, is a different thing: the vendor has delegated the hard part instead of reimplementing it.

For MSPs the question runs in both directions. Your own technicians should authenticate through your directory, and your customers who want direct access to their own backup reports should be able to use theirs.

How the Duplicati Console handles login

The Duplicati Console holds no passwords. Every sign-in goes through an identity provider: individual users and small teams sign in with GitHub, Google or Apple, and organizations connect their own identity provider so that their users authenticate against their own directory, with their own MFA and conditional access policies in force. For users who prefer a plain email-and-password account, that account is held by Azure B2C, not by the Console, and MFA is enforced on it with no opt-out. In every case the Console receives a signed identity assertion and nothing else; there is no credential table in our database to leak, crack or clean up.

We built it this way from the start rather than adding it later, because the console is exactly the kind of target described above. It knows which machines you back up, where the data lives, and can open a remote-control session to a Duplicati client. A login that weak-links all of that to a reusable password would undermine every other control in the product, including client-side encryption, end-to-end encrypted tunnels and redacted reporting.

If you are evaluating backup management for an MSP or an enterprise, put the login page on the checklist next to encryption and retention. Ask the vendor where the passwords are stored. The best answer is: not in the backup product, and never without MFA.

See duplicati.com for more on the Duplicati Console or head to documentation for how to connect your identity provider.