Turning On Multifactor Authentication Without Locking Yourself Out

Why this matters

Multifactor authentication (MFA, sometimes called two-step or two-factor) means an account asks for something beyond the password: a code from your phone, a tap on an app, or a small hardware key. It stops the most common account takeover cold, because a stolen password alone no longer gets in. Owners who resist it are usually not worried about the hassle of a code. They are worried, correctly, about the day the phone goes in a bucket of pool water and they cannot get into payroll. That fear is a real risk and it is solved by preparation, not by leaving MFA off. This card is the order to do it in and the recovery work that has to come first.

The factors, and what each one actually protects against

Not all second factors are equal, and the difference matters most for the accounts that reset other accounts.

Factor How it works Main weakness
Text or voice code A code sent to your phone number Your number can be stolen; see SIM swap below
Email code A code sent to an inbox Only as strong as that inbox; useless if the inbox is the account being protected
Authenticator app An app on your phone generates a code that changes every 30 seconds A convincing fake login page can still ask you for the code and use it at once
Push approval The app asks "is this you?" and you tap People approve prompts they did not start, especially when bombarded; number-matching prompts reduce this
Security key or passkey A physical key or a credential stored on your device, checked by the real site only Costs a little and needs a spare; the strongest common option against fake login pages

A SIM swap is when an attacker persuades your mobile carrier, often with personal details found online, to move your phone number onto a SIM card they hold. Your phone loses service and every text code now goes to them. For the owner of a small shop, whose number is on the trucks and the website, this is a realistic attack. Two defenses: ask your carrier to put a port-out PIN or number lock on the account (most US carriers offer one as of 2026; the name and process vary, so ask), and move important accounts off text codes.

Phishing-resistant is the term for factors a fake login page cannot capture and replay, which in practice means security keys and passkeys. CISA recommends them for the accounts that matter most. A text code is far better than nothing; an authenticator app is better again; a key or passkey is best on email admin, the domain and the bank where the provider supports it.

Before you enable anything: build the recovery kit

The lockouts happen because people turn MFA on, close the setup screen, and lose the one thing that would have let them back in. Do these first:

  1. Lock your phone number at the carrier. Text codes and many recovery flows depend on it, so it comes before everything. Skip this and every text-based factor you add is only as strong as a carrier's call-center script.
  2. Decide where recovery codes live. Most services give a set of one-time recovery codes when you enable MFA; each one gets you in once if your phone is gone. Print them, label each sheet by account and date, and keep them in a locked place at the shop or with the owner's papers, plus a copy in the password manager's owner-only vault. Not in email, not in a photo on the same phone.
  3. Plan a second factor for every critical account. Two security keys (one on the keyring, one in the safe), or the authenticator app on two devices (the owner's phone and an office tablet that stays locked in the office), or an app plus a backup phone number that belongs to the shop. One factor on one phone is the lockout setup.
  4. Make sure each account's recovery email and phone are ones the shop controls. MFA on an account whose recovery email is a dead mailbox moves the weak point rather than removing it. See related: The Account Inventory Every Shop Should Keep.

The order to enable accounts, and the reason for it

Work from the top of your recovery chain downward, because an attacker who holds an unprotected account higher up can use it to reset a protected one lower down.

  1. The password manager, since it now holds everything else.
  2. Email admin and any mailbox used as a recovery address, including the owner's personal mailbox if it recovers business accounts.
  3. The domain registrar and DNS host. Whoever holds these can redirect your email. See related: Your Domain Name Is the Master Key.
  4. Bank, card processor, payroll, accounting.
  5. Business profiles, social accounts, the website.
  6. Supplier portals, field software, everything else.

The top of the list is where a lockout hurts most, which is why the recovery kit comes first and why you should do the top three on a quiet weekday morning, not at 6 p.m. before a holiday.

Enabling one account, the routine

Do the same five things every time; the consistency is what makes recovery work later.

  1. Enroll the strongest factor the service offers, a key or passkey if available, otherwise an authenticator app. Avoid text-only if there is any alternative.
  2. Save the recovery codes before closing the setup screen. Print them or put them in the vault now. Many services show them once.
  3. Add the second factor immediately: the spare key, the second device, or the shop backup number.
  4. Sign out and sign back in using the new factor, on a different browser or device. This proves it works while you still have a session open to fix it if it does not.
  5. Record it in the account inventory: factor type, where the codes are, what the backup is, the date.

Testing recovery before you need it

A recovery plan nobody has tried is a guess. Once everything is enabled, test it on purpose:

  • Use a recovery code on one low-stakes account (a supplier portal) to confirm the printed codes work and you know how the service asks for them. Then generate fresh codes and replace the sheet, since the used one is gone.
  • Sign in to one critical account with the backup factor only, the spare key or the office tablet, with the main phone switched off.
  • For staff accounts, test the admin reset. Have an office manager pretend to have lost her phone and have the email admin reset her MFA from the admin console, so you know it works and how long it takes.

Worked example: the phone goes in the bucket

The owner of an eight-person garage door shop spends a week enabling MFA on 14 accounts, following the order above: carrier lock on Monday, then password manager, email admin and his personal mailbox, registrar, then the money accounts, then the rest. Eleven of the 14 get an authenticator app on his phone plus the office tablet, with printed codes; email admin and the registrar get two security keys. Payroll offers only text codes, so it gets text to his phone, and in the rush he does not save its recovery codes. The setup took about six hours across the week.

In week three, his phone is crushed under a door section on a job. That evening:

  • The 2 key-protected accounts: he signs in with the keyring key. No problem.
  • 10 of the 11 app accounts: he signs in from the office tablet, which has the same app entries. No problem.
  • The one remaining app account, a supplier portal, was set up on his phone only, a slip in step 3; he uses a printed recovery code and re-enrolls.
  • Payroll: text only, phone gone, no codes. Locked out. It cost him a morning at the carrier store for a replacement SIM before payroll could run, a day later than the crew expected their pay.

Thirteen of 14 recovered within an hour, and the one that failed failed for exactly the reason the routine's step 2 exists. Had the carrier lock not been on, the replacement SIM would also have been the attacker's easiest path into his number, which is why a number lock and a text-only payroll account are a worse pair than either alone. His fix: ask the payroll provider whether an app option exists (it did, in a setting he had not found), switch to it, and save codes.

What changes the approach

A service only offers email codes. Then the mailbox receiving them is the real second factor, and its own MFA is what protects this account. Point those codes at a shop mailbox that has a key or app on it, never at a personal inbox with only a password.

A tech has no company phone. An authenticator app on a personal phone is reasonable and asks nothing of the employee beyond an app; requiring text codes to a personal number ties shop access to a number the shop cannot lock or recover. Settle the ground rules first. See related: Personal Phones at Work: The BYOD Question.

Someone outside the shop holds the account. If a web designer or bookkeeper is the admin, you cannot enable or recover MFA on it, and turning it on for them puts the second factor on their phone. Move the account into the shop's name first. See related: The Agency or Web Designer Holds Your Keys.

The owner travels or works alone in remote areas. Security keys need no signal and no battery, which makes them the better primary factor for someone often out of coverage.

Rolling it out to the crew

Turn it on for the owner and office first, then require it for everyone from the email admin console, with a grace period of about a week so people enroll at a convenient time rather than at a locked screen on a job. Use the authenticator app on company phones where techs have them. Watch for a shared login turning up during rollout: MFA ties an account to one phone, so a login four techs share will break the day you enable it, which is the moment to give each tech their own. See related: The Shared Login Problem.

References

  • CISA guidance on implementing phishing-resistant multifactor authentication
  • NIST Special Publication 800-63B, which treats text-message codes as a restricted authenticator because of number-takeover risk
  • See related: The Account Inventory Every Shop Should Keep
  • See related: Rolling Out a Password Manager to a Small Crew
  • See related: The First Hour After a Suspected Breach SOP