Locks a user's authenticator to prevent authentication
This step locks a specific authenticator for a user, preventing them from using it to authenticate. Locking is useful for temporarily blocking an authenticator when suspicious activity is detected or as part of a security enforcement flow.
Locking is supported for the following authenticator types: passwords, passkeys, mobile biometrics, face authentication, and PIN codes (This functionality is being gradually rolled out across regions and tenants). TOTP and OTP (email, SMS) authenticators cannot be locked.
The authenticator to lock is identified by its authenticator ID, which can be retrieved using the "User Authenticators: User authenticators API" step or the User Authenticators API. If the step completes successfully, the authenticator is locked and the journey continues to the next step. If it fails, the journey proceeds to a failure branch (if one is specified); otherwise, the journey is aborted and an error is sent to the client.
For more about which authenticator types support locking, see Manage user authenticators.
| Field | Description |
|---|---|
| User auth state | Indicates if the user has authenticated in this journey. If the user is authenticated (default), the user context is provided implicitly by the journey. If not, a user identifier must be configured. |
| Identifiers | Only configured if the journey doesn't authenticate the user before invoking this step. Can be an external user ID, email, phone number, username, or a custom identifier, if configured for B2C users in your tenant. |
| Authenticator ID | ID of the authenticator to lock, specified as an expression. Can be retrieved using the "User Authenticators: User authenticators API" step or the User Authenticators API. |
| Lock reason | Optional reason for locking the authenticator. This value is stored with the lock event and can be used for auditing purposes. |
| Error output variable | Name of the variable that stores any errors returned by the step. |
| Failure behavior | Determines the behavior in case of failure, which either aborts the journey or proceeds to a failure branch of the control flow (default). |
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see Additional data reporting.