# 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](/assets/authenticator_view.a46b0b7f9b2be13a8a482570d3a2d740e2b3acb24d54a5c9e01493243b1bcbd8.2397ab79.png)

## 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** or **B2B Identity**  > **Users** > *Select user* > **Authenticators** tab.

For more information on how to configure manage authenticators' behavior and lockout policies, see [Customize login methods](/guides/user/auth_methods_customize).

## 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** or **B2B Identity** > **Users** > *Select user*  > **Authenticators**.

To get comprehensive information about a user's authenticators, see [User Authenticators API](/openapi/user/authenticators.openapi).

## 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 or journeys) and authenticator appears in the Admin Portal (**B2C Identity** or **B2B Identity** > **Users** > *Select user* > **Authenticators** tab).

Authenticators can be registered using APIs (see the login guides for each authentication method) and registration journey steps (such as [Register password](/guides/orchestration/journeys/register_password), [Register TOTP](/guides/orchestration/journeys/register_totp), [Register mobile biometrics](/guides/orchestration/journeys/register_mobile_biometrics), [Register mobile PIN](/guides/orchestration/journeys/register_mobile_pin), and [Register passkeys](/guides/orchestration/journeys/register_webauthn)).

## Authenticator status

The **Status** column in the **Authenticators** view shows the current state of each authenticator associated with the user.

![authenticator status](/assets/authenticator-statuses.672cd67aeadeeb2fd7ddf50feec0ca42637fe6bbd5f360fd2cecae93c1afedea.2397ab79.png)

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 (for example: password, passkeys, face authentication, OTPs, TOTPs, PIN codes).
- **Deactivated**: the user is suspended, so authentication is deactivated. Admins can update the status to deactivated to manually lock 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.

You can retrieve credential metadata for a user via the [User Authenticators API](/openapi/user/authenticators.openapi/other/userauthenticators). For WebAuthn authenticators, the API also returns public keys, which can be useful for authentication resiliency purposes.

## Manage authenticator status

Admins can lock, unlock, and delete certain authenticators directly from the Admin Portal. To manage an authenticator:

1. Navigate to **B2C Identity** or **B2B Identity** > **Users** > *Select user* > **Authenticators**.
2. Click the authenticator entry to open its details.
3. Next to the authenticator entry for the relevant app, select ![](/assets/action_icon.1ecac3af0cbb5a99cfdd0e9a3a7067f9df88a26acab052d3eced16c35ad4626a.9c1bb791.svg) and then the action.


The available actions depend on the authenticator type:

| Authenticator | Lock / Unlock | Delete |
|  --- | --- | --- |
| Password (new implementation) | Yes | Yes |
| PIN | Yes | Yes |
| Passkeys | Yes | Yes |
| Mobile biometrics | Yes | Yes |
| Face authentication | Yes | Yes |
| TOTP | No | Yes |
| OTP (email, SMS, direct) | No | No |


- **Lock** manually locks the authenticator, preventing the user from authenticating with it. This is useful for temporarily blocking an authenticator if suspicious activity is detected.
- **Unlock** resets the lockout state and allows the user to authenticate again. This applies to authenticators that were locked either manually or by a lockout policy.
- **Delete** removes the authenticator registration entirely. The user will need to re-register the authenticator to use it again.


Note
For device-user authenticators (such as passkeys or PINs), each device-app instance is managed separately. Locking or deleting one instance does not affect other instances of the same authenticator type on different devices.

Deleting a device-bound authenticator only removes an authenticator in Mosaic but preserves the local key on device which should be overwritten in case of authenticator re-registration.

You can also manage authenticators programmatically:

- [Lock authenticator API](/openapi/user/authenticators.openapi/other/lockuserauthenticator)
- [Unlock authenticator API](/openapi/user/authenticators.openapi/other/unlockuserauthenticator)
- [Delete authenticator API](/openapi/user/authenticators.openapi/other/deleteuserauthenticator)
- [Delete authenticator journey step](/guides/orchestration/journeys/delete_authenticator)