I have watched small companies lose a mailbox to a password that was already floating around the internet. Nobody broke encryption. Someone reused a login, or typed it into a page that looked like an invoice portal.
A second factor is the cheapest thing that stops that class of attack. Below is the order I would run a rollout in, written for the person who has to make it stick across a team of five or fewer.
The threat model, in one paragraph
Attacks on a small business are rarely clever. A password leaked from some unrelated website gets tried against the business mailbox because people reuse credentials. A phishing page collects the password while the victim is still looking at it. Automated tools spray millions of leaked email-and-password pairs at popular services every night. And in a shared office, a password on a sticky note is a real risk, not a theoretical one.
Add a second proof of identity and a stolen password stops being enough on its own. The attacker now needs something that usually expires within seconds and lives on a device they do not hold.
Ranking the second factors
Strength runs in a clear order. Pick from the top down and stop where your team's patience runs out.
Hardware security keys (FIDO2 / WebAuthn). A USB or NFC key bound to the real domain, which is what makes it resistant to phishing: a look-alike page cannot use it. Reserve these for owners, admins and anyone who can move money.
Authenticator apps (TOTP). Free, offline, and dramatically better than a text message. This is the sensible default for everyone else.
Push approval inside an app. Pleasant to use, but only if the person reads the prompt. Attackers spam approval requests until a tired thumb taps yes.
SMS codes. Still better than a bare password, yet exposed to SIM swaps and number porting. Treat it as the fallback for services that offer nothing else.
Codes by email. The weakest option of the five. When the mailbox is the thing you are protecting, mailing a code to that same mailbox protects very little.
The pattern most small teams settle on: an authenticator app on every account, and a hardware key wherever an account could reset all the others.
Do these five accounts first
You do not have to convert the whole company on day one. Work from the accounts that unlock everything else.
- Business email - Google Workspace, Microsoft 365, or a hosting mailbox. Nearly every other service resets through it.
- Domain and DNS registrar - control of DNS is control of the website, and it is enough to intercept mail.
- Hosting and cloud infrastructure - the site, the databases, and any customer records sitting on them.
- Banking and payment platforms - the direct financial exposure, and usually the platform most willing to support a second factor.
- Social media and advertising accounts - an ad account with a saved card is a favourite target for fraud.
After those, keep going through accounting tools, the POS and inventory systems, and anything holding customer personal data.
The rollout meeting that actually works
The software is the easy half. Getting a small team to adopt it is the hard half, and it fails for boring reasons.
Turn it on for yourself first, then show the team exactly what you did and how long it took. Book one session where everybody sets it up together, rather than sending a message asking people to get around to it. Standardise on a single authenticator app, because supporting several across a handful of staff is how you end up with locked accounts and a support burden. Give the business reason instead of the vocabulary: if someone reaches our mailbox, they can read every quote we ever sent and write to our customers as us. Then stay available for the first week, which is when rollouts quietly die.
Shared logins, backup codes, and leavers
Shared credentials are common in small teams, and a second factor makes the problem visible immediately.
Where a platform sells extra user seats cheaply, take them. One login per person means removing someone does not require re-issuing a password to everyone. Where an account genuinely has to be shared, keep both the password and the authenticator secret inside a shared password manager instead of a chat thread or a drawer.
When a service hands you one-time recovery codes as you enable the second factor, put them somewhere physical or in the password manager. The one place they must not live is only on the phone that generates the codes. For staff documents that several people need to reach from different machines, an encrypted cloud folder is a better home than one laptop that might leave the building - read the plan carefully, though, and check whether a cheap "one-time" tier quietly renews.
Leavers need a checklist, not good intentions. Remove the account, remove the device from the trusted list, and remove the second factor from shared services on the same day. Then confirm that the recovery email address and recovery phone number still belong to the business rather than to the person who left.
The lost-phone drill
Write the answer down before you need it.
Sign in with a backup code from a computer. Kick the missing device out of the trusted list and the active sessions. Enrol a new authenticator and regenerate the recovery codes, then destroy the old set. Change the password, because a lost phone plus a weak password is precisely the combination attackers hunt for. Finally, read the recent activity for logins, mail forwarding rules and connected apps that nobody on the team created.
A fifteen-minute monthly routine
A second factor is one layer, not a whole strategy. A short monthly pass covers most of what is left.
Review the sessions and devices on those priority accounts and remove anything unfamiliar. Look for forwarding rules you did not write - an intruder who has lost the password can still read mail that way. Confirm the backups ran and that one copy sits apart from the main machines. Update the offboarding checklist whenever somebody joins or leaves. And once a quarter, prove one recovery path works by actually using it.
None of that needs a security budget. It needs a checklist, a password manager, and the discipline to repeat it, which is the difference between a business that recovers from an incident and one that does not.
I wrote the longer version of this, with the account-by-account detail, on tanit365.com - the guide is kept up to date there.
Top comments (0)