Everyone agrees multi-factor authentication should be switched on. The reason it is still not on everywhere is rarely disagreement; it is the practical questions that follow. Which accounts first? What about the shared mailbox that four people use? What happens when someone loses their phone? Rolling out multi-factor authentication in a small business is a small project with a few decisions in it, and getting those decisions right is what separates a rollout that sticks from one that gets quietly switched off after the first complaint.
Which accounts first
Start where compromise does the most damage. Email comes first, because a mailbox is the reset mechanism for almost every other account and the launch pad for invoice fraud. Remote access comes second: the VPN, the remote desktop gateway, anything that lets a person on the internet reach the inside of your network. Administrative accounts come at the same time, because an attacker who gets one of those does not need anything else. After that, cloud applications holding customer or financial data, then everything else. A sensible rollout covers those first three groups quickly.
Choosing the second factor
Text messages
Codes sent by SMS are better than nothing, but they are the weakest common option. They depend on the mobile network, they can be intercepted by someone who persuades a carrier to move your number to their SIM, and they train users to type codes into whatever screen asks for one. Use them as a fallback, not the default.
Authenticator apps
An app on the user’s phone that generates rotating codes, or receives a push notification to approve, is the practical default for most small businesses. Push approval with number matching, where the user must type a number shown on the login screen into the app, is preferable to a plain approve button because it defeats the tactic of bombarding someone with prompts until they tap yes to make it stop.
Hardware keys and passkeys
Physical security keys, and the newer passkey approach built into phones and laptops, are phishing resistant: the credential is bound to the genuine website, so a convincing fake login page cannot capture anything usable. They are the right answer for administrators, finance staff and anyone whose account would be catastrophic to lose, and they are becoming practical for everyone else.
Conditional access ideas
Modern identity platforms let you apply rules rather than a single blanket setting. Some patterns that work well in small organizations: require MFA for every sign-in from outside the office network but allow a trusted device on the office network to authenticate less often; block sign-ins from countries where you have no staff; block legacy protocols that cannot present a second factor at all, because attackers deliberately target them; and require a compliant, managed device for access to the most sensitive applications. Rules like these keep the friction where the risk is. Our multi-factor authentication solutions work usually starts by writing these rules down in plain language before anything is configured.
The awkward cases
Shared mailboxes
A mailbox that several people sign into with one password is a problem before MFA is even considered. The clean answer is that nobody signs into it directly: it is configured as a shared mailbox and each person accesses it through their own account, with their own second factor. If a legacy device or process genuinely needs to sign in as the mailbox, that should be treated as an exception with its own controls, and it should be rare.
Service accounts and integrations
Accounts used by scanners, backup jobs, applications and integrations cannot tap an approval on a phone. They should be blocked from interactive sign-in altogether, restricted by rules to the specific system and location they need, given long random credentials stored in a password manager, and reviewed periodically. An unmonitored service account with a weak password and no MFA is exactly what attackers look for once MFA is on for people.
Lost phones and new starters
Decide in advance how a user proves who they are when their phone is lost, and who is allowed to reset a second factor. Register a backup method for everyone at enrolment. Make MFA enrolment part of day-one onboarding rather than a follow-up email that never gets actioned.
Telling people why, not just what
The rollout that lasts is the one users understand. A short explanation of what MFA prevents, a walk-through of the enrolment on their own device, a clear line for help in the first week and a manager who has visibly done it first all matter more than the technical settings. Pair the launch with a brief piece of security awareness training on the prompts users should never approve: any prompt they did not trigger, and any code request that arrives by phone or chat.
Common questions
Which accounts should get multi-factor authentication first?
Email, remote access and administrative accounts, in that order and as close to simultaneously as possible. Email is the reset path for everything else and the source of most fraud; remote access is the door into your network; and administrator accounts give an attacker everything at once. Cloud applications holding customer or financial data follow, then the remaining accounts.
Is SMS-based MFA good enough?
It is better than a password alone, but it is the weakest common method because codes can be intercepted through carrier fraud and users are trained to type them into any screen that asks. Use an authenticator app with number matching as the default, keep SMS as a fallback only, and move administrators and finance staff to phishing-resistant keys or passkeys.
How do we handle MFA for a shared mailbox?
Stop signing into it directly. Configure it as a shared mailbox and give each person access through their own account and their own second factor. That gives you accountability for who read or sent what, and it removes the shared password entirely. If an old device or process genuinely needs direct sign-in, treat it as a documented exception with tight rules around it.
What is phishing-resistant MFA?
Methods where the credential is cryptographically bound to the genuine website or service, so a fake login page cannot capture anything reusable. Hardware security keys and passkeys work this way; codes and push approvals do not, because a user can be tricked into entering or approving them on an attacker’s page. It is the right choice for accounts whose compromise would be most damaging.
If MFA is on for some accounts and you are not sure about the rest, our multi-factor authentication and security awareness training pages describe how we roll it out and help staff live with it, and you can contact us to plan the sequence for your business.
