Note: This feature may need to be activated for your account and may not be included in your subscription. If you have any questions, please contact Customer Support.

In the authentication flows you define for each authentication strength which sign-in methods are accepted. Each sign-in method consists of a primary method, which starts the login and identifies the user, and optionally of required second factors, which then confirm the login.

This article lists all methods you can select there and classifies whether a method counts as one or as two factors in terms of multi-factor authentication (MFA).

What counts as a factor?

MFA verifies a user’s identity using multiple independent factors. Each factor belongs to one of these categories:

• Knowledge: something only the user knows, e.g. a password or a PIN.

• Possession: something only the user has, e.g. a smartphone, a security key or access to an email inbox.

• Biometrics: a biometric characteristic of the user, e.g. a fingerprint or the face.

A login only is an MFA when at least two factors from different categories are verified. Bare.ID does not count factors for you: whether a strength requires MFA results solely from the sign-in methods you define for it. The following classification helps you to put these sign-in methods together.

Overview

¹ Only if “User verification” of the passkey is set to “Required” in the “Authentication methods” tab. Otherwise the passkey counts as 1 factor.

² An MFA the user completes at the identity provider itself is not counted as an additional factor in Bare.ID.

Phishing-resistant methods are cryptographically bound to the login page. The credentials can neither be intercepted nor reused on a fake login page.

Primary methods

Primary methods start a login and identify the user. Each sign-in method starts with exactly one primary method.

Passkey

Counts as: 2 factors (possession and knowledge or biometrics)

The user signs in without a password using a passkey (WebAuthn) stored on their device or on a security key. Owning the passkey is the first factor. If the user additionally releases the passkey with a device PIN or biometrics, that is the second factor.

This release is only guaranteed if “User verification” of the passkey is set to “Required” in the “Authentication methods” tab. With “Preferred” or “Discouraged” the login may also succeed without a release, so the passkey only counts as 1 factor.

Password

Counts as: 1 factor (knowledge)

The classic sign-in with a secret password. Optionally, “haveIBeenPwned (HIBP)” checks whether the password has appeared in known data leaks, and a password policy enforces minimum requirements for the password. For an MFA, combine the password with a second factor, e.g. the authenticator app.

Email magic link

Counts as: 1 factor (possession)

The user receives a one-time sign-in link at their email address and confirms the login by clicking it. This proves access to their email inbox. The link is only valid for a limited time.

Kerberos

Counts as: 1 factor (possession)

The user is signed in automatically via their existing Windows/Kerberos session, before the username form appears. This proves that they are signed in on a device of their organization. Bare.ID cannot tell how the Windows sign-in itself was secured. Kerberos therefore counts as 1 factor.

Certificate

Counts as: 1 factor (possession)

The user signs in with a client TLS certificate that identifies them. In the “Authentication methods” tab this method is called “TLS certificate”. The certificate proves possession of the device or smart card it is stored on.

Identity provider

Counts as: 1 factor

The user signs in via a connected login provider. In the “Authentication methods” tab this method is called “Login provider”. Even if the user uses several factors at the login provider itself, the login counts as 1 factor in Bare.ID. If you want to require MFA for logins via a login provider, combine the method with a second factor.

Second factors

Second factors confirm a login after the primary method. They cannot start a login on their own.

Authenticator app

Counts as: 1 factor (possession)

An authenticator app (e.g. Google Authenticator or 1Password) regularly generates a new one-time code (TOTP) on the user’s smartphone. To sign in, the user enters the code currently shown. More information can be found under One-time password (OTP) via authenticator app.

Email code

Counts as: 1 factor (possession)

A one-time code is sent to the user’s email address, which they enter for confirmation. More information can be found under One-time password (OTP) via email.

Note: The email code depends on successful email delivery. If delivery is delayed or unreliable for some users, configure additional methods such as the authenticator app, passkeys or recovery codes.

Text message code

Counts as: 1 factor (possession)

A one-time code is sent via text message to the user’s stored mobile number, which they enter for confirmation. More information can be found under One-time password (OTP) via SMS.

Security key

Counts as: 1 factor (possession)

The user confirms the login with a security key (WebAuthn), e.g. a FIDO token. Unlike the passkey, the security key only serves as a second factor and does not replace a password. More information can be found under Security Token (WebAuthN).

Recovery code

Counts as: 1 factor

A list of pre-generated one-time codes the user keeps in a safe place. They use a code when another second factor (e.g. the smartphone) is not available. Each code can only be used once. More information can be found under Allow setting up recovery codes.

Notes on putting sign-in methods together

• Two methods from the same category do not result in an MFA. If you combine e.g. “Email magic link” with “Email code”, both depend on the same email inbox. Anyone with access to the inbox satisfies both.

• A passkey with “User verification” set to “Required” already satisfies MFA on its own. A sign-in method consisting only of a passkey is therefore a full alternative to a password and a second factor.

• The methods “Certificate”, “Kerberos” and “Text message code” may need to be activated for your account and may not be included in your subscription. If a method is not booked, it cannot be selected in the authentication flows.

How to set up strengths, policies and the default rule is described in the chapters Authentication Flows and Step-up Authentication of the Bare.ID manual.