In one sentence
If you've lost every second factor on your account, you can't get back in on your own — an administrator has to reset your multi-factor authentication, and that reset is deliberately loud: everyone who administers your organization is emailed, and any of them can cancel it.
- You can't self-recover. That's the point. "Whoever holds the password gets to enroll a new factor" is exactly the bypass the second-factor rules close, so recovery is an administrator action.
- A reset does not change your password. It clears your second factors, signs you out everywhere, and makes you confirm your email address before you enroll again.
- We never accept a phone number you give us during a call. If QFormance support needs to verify a caller, we ring the number your organization recorded in advance.
First: are you actually locked out?
Work down this list before asking anyone for a reset. Each row is faster than the one below it.
| Situation | What to do |
|---|---|
| Lost your phone, but you saved recovery codes | Enter a recovery code at the sign-in challenge. Then set the authenticator app up again from Profile → Security. |
| Lost your phone | Use one of your one-time recovery codes at the challenge. A passkey will not get you past it — it signs you in, it is not a second factor. |
| You're on a device you marked "trust for 30 days" | The trusted browser skips the second-factor prompt. Use it to sign in and enroll a replacement factor from your Profile. |
| A trusted device was lost or stolen — but you can still sign in | Don't ask for a reset. Profile → Security → Forget trusted devices revokes the 30-day trust on every browser at once, so the missing device gets challenged for a second factor like any other. Your own enrolled factors are untouched. |
| You have no factor and no recovery code left | You need an administrator. Continue below. |
The one-time recovery codes are minted when you enable the authenticator app (TOTP), which everyone sets up — so you always have them. Store them somewhere you can reach WITHOUT your phone, because that is the exact situation they exist for. Lose both the phone and the codes and it takes an administrator reset.
The escalation ladder
Who resets whom depends on who is stuck.
| Who's locked out | Who fixes it | How it works |
|---|---|---|
| Any member | An admin of their own organization | Admin → Users, the shield icon on their row. Takes effect immediately. |
| Any member | Someone holding only the Reset MFA permission (a help-desk delegate) | Same page. Takes effect immediately if they record how they verified the caller; otherwise it waits 24 hours so the request can be stopped. |
| One of several admins | Another admin of the same organization | Same page, same immediate effect. |
| An admin | Must be another administrator | A delegate holding only Reset MFA cannot recover an administrator's account — the ceiling exists so a help-desk seat can't be used to take over a privileged one. |
| The organization's only admin | QFormance platform support | Raised as a request, not an instant action — see When the sole admin is locked out below. |
| QFormance's own platform administrator | Nobody, through the product | Handled by an internal manual procedure. Every system ends somewhere; the design goal is to make each rung rarer and louder than the one above it. |
A single-admin organization has no internal recovery path — if that person loses their second factor, the next rung is a phone call to QFormance. The Users page shows a standing amber banner while your org has only one admin, for exactly this reason. Promoting a second admin removes the dependency.
Resetting a member's MFA (for admins)
Open Admin → Users and click the shield icon on the member's row.
The button is unavailable in two cases, both on purpose:
- On your own row. You can't reset your own MFA. A session that already satisfies MFA proves nothing about the person who is locked out — and someone genuinely locked out can't reach the page at all. Ask another admin.
- On a member with no second factor enrolled. There's nothing to clear; they'll be sent to set one up at their next sign-in anyway.
The dialog asks for two things:
- Whether to remove their passkeys and security keys too. On by default. Leave it on for a lost or stolen device; turn it off when they've only lost access to their authenticator app and their security key still works.
- A reason. At least ten characters, and it goes on the permanent audit record. Say how you know the request is genuine — "Sam called from their desk phone; lost their phone on Tuesday, confirmed identity in person" is the shape you want, because that sentence is what an auditor reads back later.
What the reset does — and doesn't do
It does:
- Delete their authenticator app enrollment and every unused recovery code.
- Delete their passkeys and security keys, if you left that box ticked.
- Sign them out everywhere — including browsers they'd marked "trust this device for 30 days".
- Clear any second-factor lockout they'd hit from failed attempts.
- Email the member and every active admin of the organization.
It doesn't:
- Change or reset their password. That's a separate action on the same page.
- Change their email address, roles, permissions, or seat.
- Let anyone enroll a new factor for them. The member does that themselves, and only after confirming their email.
What the member does next
At their next sign-in they land on Set up multi-factor authentication — but before they can enroll anything, they have to prove they control the email address on their account:
A password thief doesn't automatically hold the mailbox. That's the whole reason for this step.
If the confirmation email doesn't arrive, the setup page says which problem it hit rather than leaving the member guessing — a link already sent and waiting, a delivery failure, or email not being configured on the deployment at all. The last one is an administrator's problem to fix, not something waiting will solve.
The notifications, and the cancel link
Every reset broadcasts by email — to the affected member and to every active admin of the organization. It's email rather than an in-app notification on purpose: the person with the most reason to object is the account holder, and by definition they may be the one who can't sign in.
You'll see up to three messages:
| Subject | When |
|---|---|
| Action required: MFA reset requested for … | The moment it's raised, before anything is carried out. |
| MFA was reset for … | Once it's actually done. |
| MFA reset for … was cancelled | If anyone stops it. |
The first email carries a cancel link that works without signing in. That's deliberate: requiring a login to object would silence exactly the person the broadcast is meant to reach. Cancelling is the fail-safe direction — the worst case is that a legitimate reset is stopped, and an admin simply raises it again. A fraudulent request wants the reset to proceed, so there's no version of "an attacker cancels it" that helps an attacker.
You don't have to rely on the email. Any pending reset also shows as a banner at the top of Admin → Users, visible to everyone who can reach that page, with its own Cancel button — so a reset stays visible even if the mail bounces. The person being reset can cancel one aimed at them from there too, whatever their permissions.
If you get one of these and nobody told you it was coming, cancel it first and ask questions second. If the reset has already happened and you didn't expect it, treat it as a security incident: tell your administrator and review the account's record history and auth activity.
Nothing about a reset is silent, and nothing runs on a timer of its own — a request that's never carried out simply goes stale and expires. Only one reset can be pending against a given member at a time; a second attempt is refused until the first is completed or cancelled.
When the sole admin is locked out
If the only administrator of an organization is locked out, nobody inside that organization can help. The next rung is QFormance support — and that path is deliberately slower and noisier than an internal reset, because a vendor employee who can reset a customer's MFA is the softest target in the whole system.
Two things make it slow:
- A 24-hour hold. A reset raised by QFormance support can't be carried out for 24 hours. The same hold now applies to one of your people holding only the Reset MFA permission — for the same reason, and cleared the same way, by recording a verification. The request email goes out immediately, so your other administrators have a full day to notice and cancel.
- A recorded verification. The hold is skipped only if the operator records how they confirmed the caller is who they say they are — calling back a number already on file, the caller quoting your organization's support PIN, or a second admin of your organization confirming through a separate channel. Recording it is a deliberate, attributable act that lands in your organization's audit trail, not a checkbox someone ticks by reflex.
The rule underneath both: never verify through the channel the request arrived on. An attacker controls their own phone and their own inbox. They don't control what you told us months ago.
Support verification — set it up before you need it
Admin → Organization → Auth & Sign-in Policy, the Support verification card. Admin-only, and you'll need a session that has already cleared its second-factor challenge — because these details are an input to a later authorization decision, and someone holding a stolen password must not be able to quietly repoint them.
Three fields:
- Callback number — a number we can ring to reach someone who can vouch for a request. Not a mobile that lives in one person's pocket if you can avoid it.
- Who it reaches — a name and role, so the operator knows they got the right person, not just the right number.
- Support PIN — 4–12 digits. Share it with the people who might call us.
We store only a hash of the PIN, so we can check one a caller quotes but can never read one back to you. If it's forgotten, set a new one.
Changing any of these emails every other administrator in your organization. That's the same reasoning as the reset broadcast: repointing the callback number is a step someone would take before phoning support, so it must not be quiet.
This item also appears on the onboarding checklist. If you'd rather not record anything, mark it We'll rely on other checks — but do it deliberately, because the cost of skipping it lands on the day someone is locked out and there's nothing to check a caller against.
How to recognize someone social-engineering you
Most attacks on account recovery aren't technical. Somebody phones a help desk, sounds credible, and asks for a reset. Your own staff are as much a target as ours, so it's worth knowing what a legitimate QFormance interaction looks like.
- We will never ask for your support PIN by email. Not in a reply to a ticket, not in a "please confirm your details" message, not ever. An email asking for it is not from us.
- We will never accept a phone number given to us during a call. If someone contacts us claiming to be from your organization, we ring the number you recorded in advance. A caller who says "don't use that number, call me on this one instead" gets refused.
Turn those around and you have your own checklist:
- Inbound calls prove nothing. Caller ID is trivially forged. If someone phones claiming to be QFormance support and asks you to confirm a PIN, approve a reset, or read out a code — hang up and call back on a number you looked up yourself.
- Urgency is the tell. "The auditor is here, I need this in the next five minutes" is the oldest lever there is. Every legitimate recovery path here survives a ten-minute delay; none of them are damaged by you checking first.
- Verify on a different channel than the request arrived on. An email request gets verified by phone. A phone request gets verified by messaging the person on a channel you already had. Never verify a request using contact details supplied inside that same request.
- A reset email you didn't expect is a live alarm. Someone raising a fraudulent reset needs everyone who was notified to ignore the message. Don't be the person who ignores it.
- Treat the reason field as a real record. "User asked" tells a future reader nothing. "Confirmed in person at the Ashford site" tells them how the decision was made.
Delegating recovery without handing over the org
Getting a locked-out colleague working again is a help-desk job. Changing branding, facilities, roles and seats is an administrative one. Those don't have to be the same person — see the Account Recovery permission group in User management and Roles & permissions.