Skip to content

Users

users_factors_reset

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes.

Tool

users_factors_reset

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes.

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes. This does NOT remove anything now. It SCHEDULES the removal behind this product's mandatory delay (config `mfa.resetDelayHours`, default 72) and immediately emails the user's primary address an abort link; if that mailbox is alive and its owner clicks, nothing happens. When the delay elapses, EVERY factor is deleted, every backup code with it, and EVERY SESSION of that user is revoked (a session that reached `aal2` must not outlive the factor that earned it) — after which the user signs in with their first factor alone and enrolls again. Every step is audited (`factor.reset_scheduled` / `_cancelled` / `_applied`) with the `reason` you pass, so do the identity proofing FIRST and write down what it was: this tool is a supervised account takeover, and the trail is what makes it reviewable.

Behavior

HTTP
POST /users/users/:userId/factors/reset

Arguments

NameTypeRequiredDescription
reasonstringWhat identity proofing was done and under which ticket. Recorded verbatim in the audit row — this is the whole point of the tool being audited.
userIdstringThe end user whose second factor is being reset.

Response

FieldTypeAlwaysDescription
requestIdstring
scheduledForstring

Try it

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes.

When to use

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes. This does NOT remove anything now. It SCHEDULES the removal behind this product's mandatory delay (config `mfa.resetDelayHours`, default 72) and immediately emails the user's primary address an abort link; if that mailbox is alive and its owner clicks, nothing happens. When the delay elapses, EVERY factor is deleted, every backup code with it, and EVERY SESSION of that user is revoked (a session that reached `aal2` must not outlive the factor that earned it) — after which the user signs in with their first factor alone and enrolls again. Every step is audited (`factor.reset_scheduled` / `_cancelled` / `_applied`) with the `reason` you pass, so do the identity proofing FIRST and write down what it was: this tool is a supervised account takeover, and the trail is what makes it reviewable.

Example

Ask your agent something like this:

OPERATOR RESET of an end user's MFA, for the case the normal recovery cannot serve: the user lost their authenticator AND their backup codes.

The agent will invoke users_factors_reset with these arguments:

{
  "reason": "<reason>",
  "userId": "<userId>"
}

Esc

Start typing to search the docs.

navigateselect