Multi-factor authentication factors, and which to require

The two second factors Qorionix actually supports, what each one resists, what it costs the person using it, and who should be on which.

Written for whoever runs IT10 min readUpdated 3 September 2026

A factor is one piece of evidence that you are you. A password is something you know. A code from an app on your phone is something you have. A passkey held in a security key or in your phone's secure hardware is something you have that also cannot be handed to the wrong website by mistake. This article is about the factors Qorionix supports, what each one is actually worth, and who in your organisation should be on which.

It is about the model rather than the procedure. If you want the three screens that enrol your own account, read Set up two-factor authentication instead — this article assumes you are deciding policy for other people.

The factors that exist, and the ones that do not

There are two, and it is worth stating the list plainly because most identity products advertise five or six.

TOTP — a six-digit code from an authenticator app: The standard time-based one-time password. Any authenticator app works, including the one built into most password managers. One enrolment per person; the platform refuses a second while the first is active.
WebAuthn — passkeys and security keys: A key pair created by your phone, laptop or a USB security key. The private half never leaves the device. This is the only phishing-resistant factor we offer, and it is covered in detail in Passkeys and security keys.

There is no SMS factor, no emailed code, and no push-approval factor. These are not stubbed or half-built; they are simply not present in the platform. If you are migrating from a product that offered them, plan on moving those people to an authenticator app or a passkey rather than looking for the equivalent setting here.

What each factor resists, and what it costs

The two supported factors, judged on what they stop, what they do not stop, and what the person carrying them has to do.
Factor	Resists	Does not resist	Cost to the user
TOTP code	A stolen or reused password on its own. Bulk password spraying. Credentials bought from another company's breach.	A real-time phishing page that asks for the code and relays it within its window. A compromised laptop that holds both the password manager and the authenticator.	About two minutes to enrol. A phone in hand at every sign-in, and a clock that is roughly correct.
Passkey or security key	Everything above, plus real-time phishing: the browser will not offer the credential to a site that is not the one it was created for.	Someone who has your unlocked device in their hand. Loss of the only device you enrolled, if nobody can reset you.	About the same to enrol. A modern browser. A second key, or a second device, if you want a spare.

Two properties of our TOTP implementation are worth knowing before you rely on it. Codes are six digits on a thirty-second period, and we accept one step either side of the current one to allow for clock drift — so a given code is accepted across roughly a ninety-second span. Within that span the code is not marked as used, so the same six digits will be accepted more than once. That is normal for the mechanism and it is part of why TOTP is a floor: a code that has been read by somebody else is useful to them for as long as it is useful to you.

What phishing-resistant means here, exactly

The policy engine can require a phishing-resistant factor for a rule. The set of factors that satisfy that requirement is fixed in the code, not configurable, and it is short:

The factor names that count as phishing-resistant

webauthn
passkey
fido2

TOTP is deliberately excluded, and the reason recorded alongside the list is the right one: a one-time code falls to a real-time attacker-in-the-middle proxy, which is the exact threat the requirement exists to address. A person who can be persuaded to type a code into the wrong page can be persuaded to do it inside thirty seconds.

When a policy rule asks for a factor, the names it uses are the literal strings totp, webauthn, passkey and fido2. Those appear in the challenge your browser receives, so a rule that lists a factor nobody has enrolled produces an empty factor list rather than a prompt — the client should send that person to enrolment rather than asking them to try again.

Both legs of a sign-in now enforce that. Presenting a one-time code where a passkey is demanded is refused on the initial call with This sign-in requires a passkey or security key. A one-time code is not accepted., and refused again on the second call — the one that submits the code — with This sign-in requires a passkey or security key. A one-time code cannot be used. The second check was missing for a while and an earlier version of this article said so; it is there now.

Be careful: The requirement is enforced at sign-in and not at step-up

Step-up authentication does not read the phishing-resistant requirement at all. So a tenant whose sign-on policy demands a passkey to get in can still authorise a privileged write — creating a user, editing a role, changing organisation settings — with six TOTP digits, or with a printed recovery code. The step-up path accepts exactly TOTP, a recovery code, and a first-time TOTP enrolment; there is no WebAuthn branch in it. That is a real gap and it is exactly the sort of thing a buyer should hear from us rather than from a pen test. It is written up in full in Step-up authentication. Until it is closed, 'our administrators can only act with a phishing-resistant factor' is a statement about sign-in, not about privileged actions, and you should not write the wider version into a policy document.

Be careful: A passkey does not register as a second factor anywhere that counts

This is the one to know before you move people onto passkeys. Enrolling a WebAuthn credential writes an audit row and nothing else — it does not set the account's MFA flag. Every check that asks does this person have a second factor reads that flag, and that flag tracks TOTP only. The visible consequences: a require_mfa sign-on policy hitting a passkey-only account walks them through TOTP enrolment despite the phishing-resistant factor they already hold; GET /auth/mfa reports {"enabled": false} for them; the step-up status endpoint reports that enrolment is required; and an administrator clearing someone's MFA does not remove their passkeys, so a passkey survives a reset intended to remove every factor. The practical advice until this is fixed: have people who need a passkey enrol TOTP as well, so the flag is set and the policy engine sees a factor. It is not the arrangement we want either.

Who should be on which factor

The honest ordering is by blast radius, not by seniority. Ask what an attacker gets from each account, and start where the answer is worst.

A defensible minimum by group, and the reasoning behind each row.
Who	Minimum	Why
Anyone with the `admin` role	A passkey or security key	An administrator can change roles, read audit logs, issue API tokens and alter the policy that governs everyone else. A phished administrator is the whole organisation.
Anyone who can check out privileged credentials	A passkey or security key	Privileged access management assumes the person holding the session is the person you think it is. A relayed code breaks that assumption at the point where it matters most.
People handling money, payroll or client data	TOTP at minimum, passkey preferred	Invoice fraud starts in a mailbox. This group is targeted by name, not swept up at random.
Everyone else	TOTP	The gap between no second factor and a six-digit code is far larger than the gap between a code and a passkey. Get everyone over the first gap before you perfect the second.

The default authentication policy that ships with a new organisation already contains a rule requiring a phishing-resistant factor for administrators. It ships switched off, on purpose, and the reason is worth understanding before you turn it on — see Sign-on policies and the decision trace.

When somebody loses their phone

This is the part where our answer is thinner than you may expect, so read it before you require a second factor across the firm.

Be careful: A recovery code cannot currently complete a sign-in, only a step-up

The service implements redeeming a recovery code at the second leg of a sign-in, and the request handler in front of it rejects the request before that code is reached: it insists on a totp_code field whatever else you sent, so a body carrying only a recovery code answers 400 mfa_token and totp_code are required. The route that does accept one is POST /auth/step-up, which is a different endpoint reached from a session you already hold. So for somebody who has lost their authenticator and is sitting at a password prompt, the recovery codes in their password manager do not currently help, and an administrator clearing the factor is still the answer. We would rather say that than have somebody discover it at the point of being locked out. I enrolled MFA and now I cannot get in is the article to send them.

An administrator holding users.write can clear a colleague's second factor from that colleague's record — DELETE /api/v1/organizations/{orgID}/users/{userID}/mfa, answering 204 No Content. It removes the TOTP enrolment and deletes every remaining recovery code, so a code that outlived the authenticator it backs up cannot become a standing bypass on an account whose owner believes has no MFA at all. It does not enrol them on anything, does not revoke their sessions, and does not remove any passkey. It is recorded in the audit log as mfa.admin_disabled with the administrator named as the actor. The practical procedure — confirm it is really them by a channel that is not the missing phone, clear the factor, revoke their old sessions, and watch them re-enrol there and then — is covered step by step in Set up two-factor authentication.

The consequence for how you organise your administrators is the important part, and it catches people out:

Never let one person be both your only administrator and the only person who could reset them. If that person loses their phone, nobody in your organisation can restore their access — the recovery codes they hold do not work at a password prompt, only from a session they no longer have.
Keep at least two administrators with a second factor enrolled, on separate devices, so either can clear the other. Two is the minimum that survives one lost phone.
Create a separate emergency access account before you require a second factor everywhere, enrol it, and store its credentials the way you store the keys to the building. Every organisation that has locked itself out of its own console did it by protecting every account well and leaving no way back in.
Revoke sessions when you reset a factor. Clearing an enrolment does not sign anyone out; an existing session on a lost device keeps working. See Session policy and sign-out behaviour.

The messages people will report to you

These are the exact strings the API returns, which is what a colleague will paste into a support message. Note that the same wrong code produces different wording depending on where in the flow it was typed — during enrolment it is one message, during a sign-in it is another.

Enrolment and management, verbatim

MFA is already enabled
MFA enrollment not started
totp_code is required
invalid TOTP code
MFA is not enabled

Completing a sign-in that asked for a second factor, verbatim

invalid MFA code
mfa_token and totp_code are required
invalid or expired MFA token
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.

Recovery codes and step-up, verbatim

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

Be careful: A wrong second factor never locks an account, and three endpoints have no attempt budget at all

The five-failures-then-fifteen-minutes lockout is counted on password failures only. A wrong one-time code and a wrong recovery code each write an audit row — auth.mfa_failed, auth.mfa_recovery_failed — and touch no counter. What actually bounds guessing is narrower than you would hope: the second leg of a sign-in is rate-limited to ten requests a minute per address, and each challenge token is single-use; step-up allows three attempts per thirty-second code window. But confirming an enrolment, disabling MFA and regenerating recovery codes have no limit of any kind, so somebody already holding a session can grind six digits against them indefinitely. Those three all require a session, so this is an escalation risk from a stolen session rather than an unauthenticated one — and it is still worth knowing.

One trap for anyone scripting against the API: confirming an enrolment and completing a sign-in are different endpoints. POST /api/v1/auth/mfa/enroll/verify finishes enrolment and needs a signed-in session. POST /api/v1/auth/mfa/verify completes an interrupted sign-in and takes the short-lived token the sign-in handed back instead. Older quickstart material of ours names the second path for the first job; it is wrong, and the pair is the most confusable thing in this module.

What to do next

Read Passkeys and security keys and enrol one on your own administrator account before you require it of anyone else — then enrol TOTP alongside it, for the reason in the callout above.
Check that you have a second administrator who can reset the first, and an emergency access account you have actually tested.
Read Recovery codes so you know what your colleagues were handed at enrolment and where those codes do and do not work.
Read Step-up authentication before you write down what your administrators must prove to perform a privileged action.
Read Adaptive MFA and risk signals to see when a second factor is demanded rather than merely available.

The factors that exist, and the ones that do not

What each factor resists, and what it costs

What phishing-resistant means here, exactly

Who should be on which factor

When somebody loses their phone

The messages people will report to you

What to do next

Read next

Passkeys and security keys

Adaptive MFA and risk signals

Sign-on policies and the decision trace

Recovery codes

Step-up authentication