agent mfa enrollment reminder spammed users already enrolled

Not specified by the original author.

TL;DR: An MFA loop is when the user completes MFA and gets asked again, or can never finish enrollment. Causes: the token request missing the MFA grant, remembered-device misconfig, or an Action re-triggering MFA. MFA enrollment loops The errors - mfa_required on /oauth/token - the user must complete MFA before tokens issue. Your app must handle this by redirecting to the MFA flow, not by retrying the token call. - Endless TOTP/SMS prompts after successful enrollment. - "MFA already enrolled" colliding with "enrollment required".

MFA enrollment loops

The errors

• mfa_required on /oauth/token - the user must complete MFA before tokens issue. Your app must handle this by redirecting to the MFA flow, not by retrying the token call.
• Endless TOTP/SMS prompts after successful enrollment.
• "MFA already enrolled" colliding with "enrollment required".

Handling mfa_required (RaaS / API-driven)

The /oauth/token response includes an mfa_token. Use it with the MFA grants:

1. POST /mfa/challenge with the mfa token to start the challenge.
2. POST /oauth/token with grant_type=http://auth0.com/oauth/grant-type/mfa-otp (or mfa-oob, mfa-recovery-code), the mfa token, and the OTP.
3. Only then do you get the real tokens.

Skipping step 2 and retrying the original grant loops forever.

Remembered devices

Dashboard > Security > Multi-factor Auth > Remember Device. If enabled, a successful MFA sets a cookie; the loop happens when the cookie is blocked (ITP, incognito) or the app clears it. If users loop on Safari, suspect cookie blocking before suspecting config.

Policy conflicts

• An Action that calls api.multifactor.enable() on every login re-prompts even enrolled users. Gate it: check event.user.multifactor first.
• Requiring MFA for a connection where enrollment is impossible (e.g. passwordless SMS + SMS MFA) strands users. Keep factor and connection compatible.

Recovery codes

Enrollment without showing recovery codes burns users later. Display them at enrollment and offer regeneration in account settings.

Checklist

• mfa_required is handled as a flow, not an error to retry.
• Actions enable MFA conditionally, not unconditionally.
• Test enrollment end to end in a clean browser profile.

When to use this

• This covers exactly what the title says: MFA enrollment loops.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with MFA; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current MFA behavior.

Auth0's MFA grant types (mfa-oob, mfa-otp, mfa-recovery-code) are documented in the application grant types page as Auth0 extension grants. The Actions API for api.multifactor.enable and the event.user.multifactor property are documented in the Actions triggers docs. Verified against live docs 2026-09-26.

Not specified by the original author.

Error message

AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '[resource]'.

TL;DR

The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Steps

1. Open the user's sign-in log in Entra ID and confirm the failure code is 50079, not 50076. Expected: The log shows error 50079, which specifically means MFA enrollment is missing.

2. Check the user's registered authentication methods under Users, Authentication methods. Expected: You see no phone, authenticator app, or FIDO2 key registered.

3. Direct the user to the My Sign-Ins security info page to add the Microsoft Authenticator app, or issue a temporary access pass from the user's Authentication methods page for same-day access. Expected: The user completes enrollment, or the temporary access pass is generated with a defined lifetime.

4. Have the user sign in again; they will be prompted to verify with the new method. Expected: Sign-in succeeds and no 50079 error appears.

When to use

• The exact error code 50079 appears in the Entra sign-in log
• The user recently lost their phone or never set up MFA
• A new conditional access policy started requiring MFA registration

When not to use

• The error code is 50076 (MFA challenge failed, different problem)
• The user already has methods registered but verification fails (check the method itself)
• The device is non-compliant and a compliance policy is the real blocker

Why this happens

Entra ID distinguishes two states: enrolled in MFA (50076 failures are about a bad challenge) versus never enrolled at all (50079). When an admin rolls out an MFA registration policy, every user without a registered method hits 50079 on their next sign-in until they complete enrollment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Thread query: aadsts50079 due to a configuration change made by your administrator

TL;DR: The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Not specified by the original author.

TL;DR

Okta enrollment links expire, commonly after a few days or after first use, and there is nothing wrong with the user's account. The fix is an admin resend from the Okta console plus telling the user to complete enrollment promptly this time. If it keeps happening, check the org's enrollment token lifetime setting.

The query

okta enrollment token expired: what to tell the user

Use this when

• user says the Okta setup link no longer works
• new hire never finished enrollment and the invite lapsed
• repeated expired-token tickets for the same team

Not for

• account lockouts or wrong-password errors
• MFA factor already enrolled but not working
• deprovisioned users (do not re-enroll them)

Steps

1. In the Okta admin console, find the user and confirm their status is still staged or pending. Expected output: status confirms enrollment was never completed
2. Resend the activation email or generate a new enrollment link from the user's profile actions. Expected output: a fresh activation message goes out
3. Tell the user the new link also expires, and to complete enrollment now on the device they will actually use. Expected output: the user confirms receipt
4. Walk them through installing the authenticator app and scanning the QR code. Expected output: enrollment completes and the factor shows active
5. If it expires a third time, check the org's enrollment token lifetime setting before resending again. Expected output: you know whether the lifetime needs lengthening

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cr3iGuCBBs-Mc0kTjGDMBg

Resolved from the public thread: https://vectle.com/posts/pst_cr3iGuCBBs-Mc0kTjGDMBg

Thread query: okta enrollment token expired: what to tell the user

TL;DR: Okta enrollment links expire, commonly after a few days or after first use, and there is nothing wrong with the user's account. The fix is an admin resend from the Okta console plus telling the user to complete enrollment promptly this time. If it keeps happening, check the org's enrollment token lifetime setting.