Manage user authenticators

The Authenticator view in the user profile aims to enhance the efficiency of support operations by providing a centralized tool for managing user authenticators, including passwords, passkeys, SMS/email OTPs, email magic links, social login, OIDC, SAML, TOTPs and PIN codes.

By having centralized access to user authentication information, Customer Support Representatives and Admins can seamlessly assist users in resolving authentication-related issues and manage authenticators effectively.

authenticator view

How authenticators work

When configuring authentication for the apps in your tenant, you can choose from multiple authenticators and define a different selection for each app. Each authenticator can be customized based on its capabilities, and for those that support it, you can also define lockout policies to enhance security.

Authenticators are scoped in different ways, which determine how their configuration and status behave across applications. The scoping model includes three categories:

  • Global-user authenticators (per user across the tenant) : authenticators such as email or OTP are bound to the user's identity in the tenant. These authenticators are shared across all applications, and their configuration cannot vary per app. Their lockout status is tenant-wide—if an authenticator is locked due to failed login attempts in one app, it will also be locked in all other apps. Note that, although the unlock API is authenticated in the context of a specific app, for global authenticators unlock actions apply tenant-wide.
  • App-user authenticators (per user per app) : authenticators like TOTP or passwords are scoped per application. Each app holds its own instance of the authenticator, including configuration and lockout status. A user may have an active TOTP in App A and no TOTP in App B. Lockout and unlock operations affect only the relevant app context.
  • Device-user authenticators (per device per app) : authenticators like PIN, passkey, or mobile biometrics are tied to both the device and the application. A user can register multiple instances of the same authenticator—one per device per app. Each instance has its own status. For example, a failed PIN attempt in App A on Device 1 does not affect the same user’s PIN in App B or on Device 2. Unlock actions apply per app and affect all authenticators of the same type registered for that app (e.g., all passkeys).

Admins can view and manage authenticators from the Admin Portal > B2C Identity > Users > Select user > Authenticators tab.

For more information on how to configure manage authenticators' behavior and lockout policies, see Customize login methods.

Authenticator registration

An authenticator is considered registered once it's ready for use. Certain authenticators require an explicit registration process, such as for password, WebAuthn, TOTP, and PIN codes. Other authenticators are registered implicitly. For example, social login methods are registered the first time they're used to authenticate, while an email or phone-based method is registered once the email/phone number is added to the user's profile.

Upon registration, an authenticator ID is automatically generated (accessible via API).

Authenticator view

The Authenticator view not only provides a comprehensive list of all authenticators for each user but also offers detailed information such as the date of the last login, the accessed app, the login device, and more for each authenticator.

To access the authenticator management view, navigate to B2C Identity > Users > Select user > Authenticators.

To get comprehensive information about a user's authenticators, use our user authenticators API.

Authenticator status

The Status column in the Authenticators view (B2C Identity > Users > Select user > Authenticators) shows the current state of each authenticator associated with the user.

authenticator status

Possible statuses include:

  • Registered : the authenticator is available, but hasn't yet been used
  • Locked : a lockout rule is applied to the authenticator in accordance with the settings specified in the method (only for password, OTPs, TOTPs, PIN codes).
  • Deactivated : the user is suspended, so authentication is deactivated. Admins can update the status to deactivated to manually block it (either temporarily or permanently) due to the detection of malicious activity.
  • Active : the authenticator has been used for login at least once.

Each authenticator is listed once, but it may be linked to one or more apps within the tenant. When the same authenticator is used across multiple apps, the UI displays a Multiple label.

If the status of that authenticator is consistent across apps (e.g., Active in all apps), the unified status is shown. If different statuses exist across apps (e.g., Active in App A but Locked in App B), the status may be shown as Mixed.

Clicking a status reveals contextual information for that authenticator, including:

  • the associated app,
  • last successful authentication time,
  • registration date,
  • current status within that app.

This allows admins and support teams to understand how each authenticator is used and whether issues are scoped to a specific application.