Set up two-factor authentication
Two minutes, and the largest single reduction in account-takeover risk available to you. Plus the ten recovery codes, and what to do when a phone is lost.
Two-factor authentication means that a stolen password is no longer enough to sign in as you. Microsoft's own published figures put the reduction in account-compromise risk above 99% once a second factor is in place. Enrolment takes about two minutes per person. Almost nothing else you do this month has that ratio of effort to effect.
This covers enrolling your own account, what happens when somebody loses the phone that holds their codes, and the administrative jobs that follow. One thing to know first, because it changes how you plan: completing an enrolment produces ten single-use recovery codes, shown once and never again. They are the difference between a lost phone costing somebody five minutes and costing them an administrator's afternoon.
What you need
- An authenticator app on your phone. Qorionix uses the standard time-based one-time password method — TOTP — so any TOTP app works, including the one inside most password managers.
- A phone you expect to still be holding next month. Undoing an enrolment needs an administrator, so enrolling on a device you are about to replace makes work for somebody else.
- Two minutes. Nothing expires half-way through, and nothing is switched on until you type a working code. An interruption costs one fresh press of Start enrolment.
- Somewhere safe to keep ten recovery codes. Enrolment ends by showing them, once. A password manager is the obvious place; a photograph on the phone holding the authenticator is the one place they are no use, because that is the device you are insuring against losing.
Enrolling your own account
Enrolment lives under Identity → MFA and covers your own account only. Nobody can do it for you, including us. The page holds two panels — an authenticator, and a list of registered passkeys — and between them they are the whole of what Qorionix offers. There is no SMS code, no emailed code and no push-approval prompt: not switched off pending a licence, simply not built. Passkeys and hardware security keys are the phishing-resistant option; a typed code never is.
Open Identity → MFA and press Start enrolment
The status row reads Not enrolled, method None. If it already reads Enrolled, you are done and can stop reading here.
Step 1 — scan the code
A QR code appears. Open your authenticator app, choose to add an account, and point the camera at it. Nothing has changed on your account yet.
Step 2 — or enter the key by hand
If you cannot scan, the same key is printed as text with a Copy key button, beside the six parameters your app may ask for. Take the warning under it literally: "Anyone holding this key can generate your codes. Do not share it and do not store it beside your password."
Step 3 — confirm a code
Type the six-digit code your app is showing right now and press Verify and enable. This is the step that switches the factor on; until it succeeds your account is unchanged, so a failed attempt costs nothing.
Keep the recovery codes
The status row flips to Enrolled and, from your next sign-in, the password screen is followed by a code prompt. Ten single-use recovery codes are generated whenever an authenticator enrolment completes, wherever that enrolment happens — the invitation flow shows them as its own final step, behind a tick-box you have to complete before continuing, and the same codes belong to an enrolment made here. Save them the moment they appear: they are displayed once and cannot be shown again.
When the code is rejected
Two rejection messages — the first from the enrolment and disable screens, the second from the code prompt at sign-in:
invalid TOTP code
invalid MFA codeNine times in ten the cause is clock drift, not a typo: the code is derived from the clock on your phone and on our server, so a phone half a minute out produces nothing but wrong codes. Turn on automatic date and time, then type the code on screen now — not the one you started typing.
One honest detail while you are here. We accept a code for its own thirty-second window and one either side, and we do not record which codes have been used — so a single code stays usable for roughly ninety seconds, more than once. It matters where somebody can read your screen.
A lost phone: recovery codes first, administrator reset second
This is the part people get wrong, and until this revision it was the part this article got wrong. Somebody who loses the phone holding their authenticator has one self-service route back in: type one of their ten recovery codes where the 6-digit code is asked for. It works once, and then that code is spent. Having signed in, they should re-enrol an authenticator on the new phone, which produces a fresh set of codes.
The administrator reset is what remains when there are no codes left, or when the codes were never kept — which, honestly, is most of the time. An administrator clears the enrolment; the person then signs in with their password alone and enrols again. There is no email fallback and no self-service screen for that case.
That reset needs the users.write permission, which in a stock tenant means the built-in admin role and nothing else — member and viewer hold users.read only, because every identity change was deliberately held back to administrators. Roles and permissions covers how to check a role.
An administrator cannot do it for themselves. Not because we forbid it, but because of the shape of the problem: the reset happens inside the console, you reach the console by signing in, and signing in is what the missing phone has stopped them doing. A registered passkey is the one exception, which is a good reason for administrators to hold one.
Rolling it out to your team
You cannot enrol on somebody else's behalf, and you should be suspicious of any product that lets you. What you can do is watch. Identity → Users carries an MFA column — a green enabled pill where a factor is enrolled, a plain dash where it is not — above tiles reading MFA enrolled and MFA coverage. Start with the administrators, then read the posture report's version of the same point:
ZQ-M365-PRIV-003Administrators without multi-factor authentication
- Why it matters
- A password alone protects these accounts. Passwords are guessed, reused, and bought in bulk from other companies' breaches.
- What the attacker does
- Attackers buy or spray passwords at scale. With no second factor, a correct password is complete access — no alarm, no further work.
- The fix
- Require a second factor for every administrator. Microsoft's own data puts the reduction in account-compromise risk above 99%, and it takes each person about two minutes to set up.
The change we offer alongside it adds a Conditional Access policy covering privileged roles only, so each administrator is prompted at their next sign-in. It is marked disruptive because it changes how those people sign in, and reversible: switching the policy off takes effect immediately.
| Priority | Who | Why |
|---|---|---|
| 1 | Everyone with the admin role | One password buys an attacker every member, every role and every API key. This is the critical finding above. |
| 2 | Anyone who handles money or client data | In an accountancy firm, most of the fee earners. Invoice fraud starts with a mailbox, not with malware. |
| 3 | Everyone else | One sitting at a team meeting, rather than ten separate reminders. |
The signup wizard sets the expectation — "Qorionix requires multi-factor authentication for every tenant admin." — above a checkbox offering to enrol TOTP after first login. That checkbox enrols nobody: your first administrator still does the work above.
A colleague has lost or replaced their phone
Confirm it is really them
Not by email, and not by a message from the phone that is allegedly lost. Ask them in person, or ring a number you already had. Resetting a second factor on the strength of an emailed request is a well-worn attack, and it works because it sounds like helpfulness.
Open Identity → Users and find their row
Search by name, email or status. Each row ends in three labelled buttons: Reset MFA, Revoke sessions and Suspend.
Press Reset MFA
You confirm against their email address, the console reports "MFA reset." and the MFA column falls back to a dash. It clears the enrolment and nothing else — no password change, and no email to them, so tell them yourself. Ask them first whether they still hold an unused recovery code: if they do, they can sign in on their own and you need not touch the account at all.
Revoke their old sessions
Revoke sessions signs them out of every device at once. If the phone is lost rather than replaced, do it: a session already signed in on a missing device is never asked for a second factor again.
Watch them re-enrol, and see that they keep the new codes
Have them run the three steps on the new phone while you are still in the room. Completing the enrolment produces a fresh set of ten recovery codes, shown once, and the old set is of no use to them now — so this is the moment to make sure the new set actually gets saved somewhere.
Both actions are audited as mfa.admin_disabled and user.sessions_revoked, naming you as the actor. One limit while you rely on that: identity audit rows are not hash-chained the way our compliance and privileged-access records are, so treat them as a dependable log rather than tamper-evident evidence.
Turning it off
Disabling is deliberately awkward. Disable authenticator does nothing on its own: it asks for a current six-digit code — "Enter a current code from your authenticator to confirm." — and only then offers Confirm disable. That is the point: somebody who has stolen your password cannot switch off the thing stopping them.
Two good reasons to disable your own factor: you are moving to a different authenticator app, or to a phone you are holding right now; and you want a fresh set of recovery codes, because the old set has been spent or is no longer somewhere you trust. Either way, re-enrol in the same sitting and keep the ten codes the new enrolment gives you.
Keep a way back in
Create a separate emergency access account before you require a second factor across the firm, and give it the admin role so that it can perform the reset nobody else can. Two things to keep physically safe for it: the device holding its authenticator, and its ten recovery codes, printed and stored with the password somewhere a second person can reach. Use the account for nothing else. Your posture report argues the same case about your Microsoft tenant, as ZQ-M365-PRIV-004:
If your only administrator loses their phone, leaves, or is locked out by the very policy that protects them, nobody can administer the tenant. Microsoft support cannot reliably get you back in.
That account is one of the items on the first-week checklist, and ten minutes you will hope never to need.
What to do next
- Enrol your own account now, if you have not.
- Check that a second person holds the
adminrole. If nobody does, fix that today. - Open Identity → Users and note every administrator showing a dash in the MFA column.
- Work through the first-week checklist, where fixing those administrators is an early item.