A password alone, no matter how strong, is a single point of failure. Two-factor authentication adds a second, independent check — something you have, like your phone, in addition to something you know, like your password — so that a stolen or guessed password alone is not enough to access an account. Most teams know they should be using it, but the specific choices around how you set it up matter more than most people realize, and some common configurations create risks that defeat much of the purpose.
This guide covers how to set up two-factor authentication correctly for a small team, building on our password manager comparison, which touched on this topic briefly.
Why SMS-based two-factor is the weakest option
Receiving a code via text message is the most common form of two-factor authentication offered by default, largely because it requires no additional app and works on any phone. It is also the least secure common option, because of a well-documented attack called SIM swapping, where an attacker convinces a mobile carrier to transfer your phone number to a SIM card they control, then receives your two-factor codes directly.
SIM swapping attacks have been used in numerous documented account takeovers, particularly targeting individuals with valuable accounts (cryptocurrency holders, executives, public figures), but the underlying vulnerability exists for anyone using SMS-based authentication. For a small business, this risk is real enough that we recommend avoiding SMS-based two-factor for any account of real consequence whenever an alternative is available.
Authenticator apps: the practical default
Authenticator apps (Google Authenticator, Authy, Microsoft Authenticator, or the authenticator built into your password manager) generate time-based codes locally on your device without any text message or network dependency. Because the code is generated on-device rather than transmitted, there is no SIM swapping equivalent risk — an attacker would need physical access to your unlocked device or a copy of the underlying secret key, not just control of your phone number.
Setting one up is straightforward: when enabling two-factor authentication on a service, you are typically shown a QR code to scan with your authenticator app, which then generates a new six-digit code every 30 seconds. This is currently the most practical balance of security and ease of use for most small teams, and should be the default recommendation for any account that supports it.
Hardware security keys: the strongest option
A physical hardware security key (YubiKey being the most widely recognized brand) provides the strongest protection currently available, since it requires physical possession of the actual device and is specifically designed to resist phishing in a way that authenticator app codes are not — a hardware key will not authenticate on a fake login page that mimics the real one, while a typed authenticator code technically can be, if a user is tricked into entering it there.
Hardware keys are a reasonable investment for any account with unusually high consequences if compromised — a company’s primary admin account, a shared password manager master account, or financial system access. For a small team, equipping the handful of people with access to the most sensitive systems, rather than the entire team, is often the most practical way to introduce hardware keys without a significant budget or rollout effort.
Setting up recovery codes correctly
Every two-factor setup should come with backup recovery codes, generated once during setup, for the scenario where you lose access to your primary authentication method — a lost phone, a broken hardware key. The critical mistake we see repeatedly: storing these recovery codes inside the very same password manager or account they are meant to help you recover into. If that account becomes inaccessible, the recovery codes stored inside it become inaccessible too, at exactly the moment you need them.
Store recovery codes somewhere genuinely independent — printed and kept in a physical safe, or in a separate secure location that does not depend on the same account being accessible. This is a small extra step during setup that prevents a genuinely unrecoverable lockout later.
Rolling out two-factor authentication across a team
A practical rollout for a small team follows a clear order of priority. Start with the accounts that would cause the most damage if compromised: the shared password manager’s master accounts, your domain registrar and DNS provider (an attacker controlling these can redirect your entire company’s email and website), and your cloud infrastructure admin accounts. Only after these are covered should you move to lower-risk individual accounts.
Where the service supports it, enforce two-factor authentication as a mandatory organization-wide policy rather than an optional setting individual employees can choose to skip. Most business-tier SaaS tools, cloud providers, and password managers offer an admin-level setting to require this rather than relying on voluntary adoption, which our testing across multiple tools consistently found to be far less reliable than an enforced policy.
Push-based authentication: a middle ground
Some services offer push-based authentication instead of a typed code — a notification sent directly to a registered app on your phone, which you approve with a single tap rather than typing a six-digit number. This is more convenient than typing a code and avoids some phishing scenarios where a typed code could be captured, though it introduces a different risk: “push fatigue” attacks, where an attacker who already has your password repeatedly sends approval requests hoping you will eventually tap approve out of habit or annoyance, without realizing it is not you attempting to log in.
Services that implement push-based authentication well include additional context in the request — the location or device attempting to log in — making it easier to recognize a suspicious request. If your team uses a service offering push notifications, train employees specifically to check this context before approving, and to deny and report any unexpected request rather than assuming it is a glitch.
What happens when a service does not support strong two-factor options
Not every tool your team uses will support authenticator apps or hardware keys — some smaller or older SaaS products only offer SMS-based two-factor, or no two-factor authentication at all. For these cases, weigh how sensitive the data in that specific tool actually is. For a low-stakes tool with no sensitive data, SMS-only two-factor (or even no two-factor) may be an acceptable risk to simply document and accept. For anything touching client data, financial information, or credentials, consider whether an alternative tool with stronger authentication support is worth switching to, factoring this into your evaluation the next time you assess your software stack.
Common mistakes we see
Using the same phone number for SMS-based two-factor across every account. If SMS is unavoidable for a specific service, at minimum this consolidates the SIM-swapping risk to a single point of failure across every account using it, which is worth being aware of even if you cannot fully eliminate it for every service you use.
Never testing the recovery process. Setting up two-factor authentication and recovery codes but never actually testing what happens if you lose your primary device means discovering problems with your recovery setup during an actual emergency, which is the worst possible time to discover them.
Treating two-factor as a replacement for strong, unique passwords. Two-factor authentication is a second layer of defense, not a substitute for the first. A weak, reused password protected by two-factor authentication is still a weaker setup than a strong, unique password with two-factor added on top.
Frequently asked questions
Is an authenticator app enough, or do we need hardware keys for everyone?
An authenticator app is sufficient for the large majority of accounts and users. Reserve hardware keys for the specific highest-risk accounts and the people who have access to them, rather than treating it as an all-or-nothing team-wide decision.
What if an employee loses their phone with the authenticator app installed?
This is exactly what recovery codes are for, provided they were stored correctly and independently as described above. Most services also allow re-verifying identity through alternative means and re-establishing two-factor on a new device, though the process varies by provider and is generally slower than using recovery codes directly.
Can we use the same authenticator app across multiple accounts and team members?
Each account should have its own independent two-factor setup tied to the specific person’s device, rather than sharing a single authenticator instance across a team, since this reintroduces the same lack of accountability and revocation problems that a shared password creates in the first place.
Does two-factor authentication slow down daily logins significantly?
Most authenticator apps and modern browsers support remembering a trusted device for a set period, meaning you are not prompted for the second factor on every single login, only periodically or when logging in from a new device. This significantly reduces the day-to-day friction while maintaining the security benefit for the scenarios that actually matter, like an unfamiliar device attempting to log in.
Should we require two-factor for contractors and part-time staff, not just full-time employees?
Yes — access risk is tied to what an account can reach, not to someone’s employment classification. A contractor with access to client systems or company data represents the same risk as a full-time employee with equivalent access, and should be held to the same authentication requirements.
Two-factor authentication is one of the highest-value, lowest-cost security improvements a small team can make, but the specific choices around which method to use and how to handle recovery determine whether it actually delivers the protection you expect. Getting these details right during initial setup avoids both a false sense of security and a painful lockout down the road.
For more on securing your team’s credentials as a whole, see our password manager comparison and full tool reviews section.