I enrolled MFA and now I cannot get in

You turned on a second factor and now the six digits are not being accepted, or the phone that held them is gone. This article works through the causes in the order they actually occur, and is explicit about the one situation where the recovery codes you were given will not help.

1. The clock on your phone has drifted

The most common cause by a distance, and the easiest to fix. A time-based code is derived from the current time, so a phone whose clock is more than a minute out generates codes for a moment that has not happened yet or has already passed.

Qorionix accepts one thirty-second step either side of the current one, so a code is valid across roughly a ninety-second span. That is generous and it is not unlimited.

Fix: turn on automatic time on the phone, or use the authenticator app's own time-correction setting if it has one. Then try again with a fresh code. If the codes were working last week and stopped, this is almost certainly it.

2. You are typing a code that has already been used

A code you have already presented — to sign in, or to complete a step-up — cannot be presented again inside the same thirty-second window. The two paths share a replay guard on purpose, so a code captured from one cannot be spent on the other.

Fix: wait for the app to show the next code rather than retyping the current one. The audit trail records this case distinctly as auth.mfa_code_replayed, so if it is happening repeatedly an administrator can confirm it.

3. You are on the wrong endpoint, or the challenge has expired

This one bites people scripting against the API rather than using the console, and it is the most confusable pair in the module.

The challenge token is valid for five minutes and is single-use — it is spent before the code is even checked, so a captured token cannot be used to brute-force codes. 401 invalid or expired MFA token means you took too long, or you are reusing a token from a previous attempt. Start the sign-in again from the password step.

4. Your organisation requires a passkey and you are offering a code

If your sign-on policy demands a phishing-resistant factor, a one-time code is refused with a message that says so exactly:

This sign-in requires a passkey or security key. A one-time code is not accepted.
This sign-in requires a passkey or security key. A one-time code cannot be used.

The first comes from the initial sign-in call and the second from the leg that submits the code. Both legs enforce it now; an earlier release enforced only the first.

Fix: use your passkey. If you do not have one, an administrator has to either enrol you on one or adjust the policy — Passkeys and security keys covers the first.

5. You have a passkey, and the platform does not count it

6. Your phone is gone

No fix on your side. Recovery codes do not work at the sign-in prompt, as explained at the top, and there is no self-service route back into an account whose authenticator has gone. The next section is what to do.

Getting an administrator to clear it

An administrator holding users.write opens Identity → Users, finds the person, and presses Reset MFA. The confirmation reads Reset MFA for {email}?, and the action returns 204 No Content.

What that does, precisely: it clears the authenticator secret and deletes every remaining recovery code, so a code that outlives the authenticator it backs up cannot become a standing bypass on an account whose owner believes has no MFA at all. What it does not do: enrol you on anything, end your existing sessions, or remove any passkey you hold.

1. 1

   The administrator confirms it is really you, on a channel that is not the missing phone

   A call to a number they already had, or in person. This is the whole security of the procedure — everything after it is mechanical, and an attacker whose entire plan is ask the helpdesk to remove the second factor is defeated here or not at all.

2. 2

   They press Reset MFA

   Recorded in the audit log as mfa.admin_disabled with the administrator named as the actor.

3. 3

   They press Revoke sessions on the same row

   Clearing a factor does not sign anybody out, and a session open on the device you have lost is still a session.

4. 4

   You sign in with your password and re-enrol there and then

   Do not leave it until later. An account that has just had its second factor removed is an account with one factor.

5. 5

   Save the new recovery codes properly this time

   You get ten, once. Recovery codes covers where to keep them and what they are actually good for.

If there is no administrator who can do it

If every administrator in your organisation has lost their factor, or there was only ever one and it is you, this is a tenant-level problem rather than an account-level one. A locked-out tenant covers what can be recovered from outside and what to say when you contact us.

The preventive measure is unglamorous and it works: two administrators with factors on separate devices, each able to clear the other, and one emergency access account you have actually tested. Every organisation that has locked itself out of its own console did it by protecting every account well and leaving no way back in.

The exact messages, for searching

invalid MFA code
mfa_token and totp_code are required
invalid or expired MFA token
invalid TOTP code
totp_code is required
MFA is already enabled
MFA enrollment not started
MFA is not enabled

invalid or already used recovery code
enable MFA before generating recovery codes
a one-time code or a recovery code is required
too many step-up attempts for this code window
step-up requires a second factor and this account has none enrolled