MFA reduces account takeover risk, but it can also create lockout risk if you enable it carelessly. That matters more when you are a freelancer or solo founder because there may be no internal IT admin to rescue you.
The safe path is not “turn on MFA everywhere tonight.” The safe path is to add MFA in layers, starting with recovery.
The short version
Before enabling or changing MFA on a critical account, slow down and confirm the recovery path. Make sure the password works, recovery email and phone number are current, backup codes are saved, and at least one recovery method exists outside the account being protected.
Only then should you test sign-in, remove old devices, or sign out of existing sessions. This matters most for primary email, password manager, domain registrar, cloud storage, source-code hosting, and payment accounts.
Who this is for
This guide is for solo operators who manage their own accounts and devices: freelancers, solo founders, developer-consultants, and tiny technical teams without dedicated IT.
If a company manages your identity provider, device policy, and recovery procedures, follow that process. If you are your own admin, you need to design the recovery path yourself.
Step 1: Start with the recovery accounts
Before turning on MFA everywhere, identify the accounts that recover other accounts. For most solo operators, that means primary email, password manager, domain registrar, phone or SIM provider, cloud backup account, and source-code hosting account.
These accounts deserve the most careful rollout. A weak primary email can let attackers reset other accounts. A badly configured primary email can also lock you out of everything.
For a broader account map, start with the Freelancer Account Security Checklist.
Step 2: Avoid one-device MFA
One phone with one authenticator app is fragile. A safer setup enrolls a second device where the service allows it, adds more than one passkey or security key, saves backup codes before signing out, keeps recovery material outside the account it recovers, and leaves at least one trusted device available during the change.
If an account supports only one MFA method, document that limitation. You may still enable MFA, but you should know the risk before relying on it for a business-critical account.
Step 3: Save backup codes before testing
When an account offers backup codes, save them before you sign out of all devices.
Then test carefully:
- confirm your password works
- confirm MFA works
- confirm backup codes are stored
- confirm at least one other trusted device or method exists
- sign out of one session and test sign-in
- only then remove old sessions or old devices
Do not make your first recovery test happen during a real emergency.
For storage options, see Where To Store Backup Codes And Recovery Keys.
Step 4: Treat phone numbers as weak recovery
SMS recovery may be better than nothing, but it has weaknesses. SIM swaps, number loss when changing providers or countries, delivery problems while travelling, dependency on a single phone account, and socially engineered recovery flows all make SMS a weaker choice for high-impact accounts.
If a service supports stronger options, prefer passkeys, authenticator apps, or hardware security keys. Still keep recovery codes.
The practical rule: do not make a phone number the only recovery path for primary email, password manager, domain registrar, or payments.
Step 5: Record account-specific recovery paths
Every platform has different recovery rules. For critical accounts, write down which MFA methods are enrolled, where backup codes are stored, whether support can recover the account, what proof is needed, which email address receives recovery messages, which trusted devices remain signed in, and what you would do if your phone was lost.
This is especially important for domains, email, source-code hosting, cloud storage, and payment accounts.
Step 6: Handle device replacement carefully
Phone replacement is a common lockout moment.
Before wiping or trading in an old phone, export or migrate authenticator entries if your app requires it, confirm passkeys are synced or re-enrolled, confirm backup codes are still available, test sign-in to primary email and password manager, update the recovery phone number if it changed, and keep the old phone available until critical logins are verified.
The same applies to laptop replacement if passkeys, SSH keys, browser profiles, or password manager sessions are tied to the device.
Step 7: Make a recovery drill small enough to repeat
You do not need a dramatic disaster simulation. A simple drill is enough:
Ask four questions: can you sign in to primary email from another browser, can you unlock the password manager without your daily laptop, do you know where domain registrar backup codes are, and do you have at least one recovery method that is not your phone?
Run this after major account changes and before travel.
Example rollout for a solo founder
Here is a practical order for a one-person business:
| Stage | Account | What to do |
|---|---|---|
| Day 1 | Primary email | Confirm the password, update recovery email, save backup codes, add MFA, and keep one trusted device signed in. |
| Day 2 | Password manager | Confirm the emergency kit or recovery key, enable MFA, store recovery material outside the vault, and test unlock on a second device. |
| Day 3 | Domain registrar and DNS | Enable MFA, save backup codes, verify transfer lock, and confirm recovery email is not only on the same domain. |
This slower sequence is less exciting than a one-night security sprint, but it reduces the chance of creating a lockout while trying to improve security.
What to document for each MFA-protected account
Keep the note short enough that you will actually maintain it:
For each critical account, record the account name, why it matters, MFA methods, where backup codes are stored, recovery email, recovery phone, trusted devices, support URL, and last checked date.
Do not include the password in this note. Store passwords in the password manager. This note is for recovery routing and decision-making under stress.
Common mistakes
The most common lockout pattern is enabling MFA and skipping backup codes. The second is storing those backup codes only inside the account they recover. Both make an account stronger against attackers but weaker against ordinary device loss.
Device changes cause problems too. Do not remove the old phone before the new one is tested, and do not assume passkeys always sync the way you expect. If SMS is the only recovery method for a business-critical account, document that weakness and improve it when the provider allows better options.
Good next step
Pick one critical account and audit it slowly. Start with primary email or password manager. Confirm password, recovery email, MFA methods, backup codes, and trusted devices.
Related guides:
- Solo Founder Account Recovery Plan
- Where To Store Backup Codes And Recovery Keys
- Domain Registrar Security Checklist