Two-factor authentication on the accounts that matter

Two-factor authentication requires a second, separate proof of identity beyond a password before a login succeeds, commonly a code from an app on a phone, or a physical security key. It exists specifically for the scenario passwords, accounts and who has access describes: a password that is compromised somewhere, through no fault of the current setup, and used by someone who is not the account holder.

Why a strong password alone is not enough: what two-factor authentication and verification add

A password can be strong and unique and still end up compromised. This can happen through a breach at an entirely unrelated service that happened to reuse the same address for account recovery. It can happen through a phishing email convincing someone to type it into a fake login page. It can happen through malware on a device that quietly logs keystrokes. In every one of these scenarios, the password itself was never the weak link. Something outside the site captured it. Two-factor authentication is what stops that captured password from being enough on its own.

How it actually works: an authenticator app’s time-based one-time password (TOTP) or a physical token

After a correct password is entered, the system requires a second, time-limited code or confirmation. This is generated on a device the legitimate account holder controls — typically a phone, through an authenticator app generating a time-based one-time password (TOTP), or a text message. On the stronger end, it can be a physical security token that has to be physically present. An attacker holding only the password, without also holding that second device, cannot complete the login.

Which method is actually stronger: SMS, an authenticator app such as Google Authenticator or Microsoft Authenticator, or a security key

An authenticator app generating time-based codes — Google Authenticator, Microsoft Authenticator and Authy are common examples — is meaningfully stronger than a code sent by SMS text message. Text messages can, in specific and increasingly documented circumstances, be intercepted through an attack on the mobile carrier itself, not the account. A physical security key is stronger again. It’s increasingly the recommended option for the single most important account on a site, commonly the primary administrator login. For most small-business purposes, an authenticator app is a strong, practical, low-cost choice. It meaningfully exceeds a password alone.

Where it should be applied first: accounts with backup tokens and a verification code ready

Not necessarily everywhere at once, if that feels like too much change to implement immediately. The administrator account, the hosting account login, and the domain registrar account are the three highest-value targets. Compromising any one of them causes the most damage. Prioritise those three first, and add broader accounts as the habit becomes normal for whoever manages the site.

The genuine trade this involves

A small amount of extra friction on every login, in exchange for closing the specific route a compromised password otherwise leaves wide open. For an account with real consequences attached to a compromise — and an administrator or hosting account genuinely does — that trade is close to unambiguous. It is a minor daily inconvenience against a real, common and otherwise unclosed risk.

What to check if it is already enabled

Check that backup codes, provided when two-factor authentication is first set up, are stored somewhere safe and separate from the device generating the codes day to day. Losing access to both the primary device and the backup codes at once is the one scenario that genuinely locks a legitimate user out. It is worth having a plan for that before it happens, rather than during a genuine emergency.

Why “it’s inconvenient” is worth pushing through, once

Most resistance to enabling two-factor authentication is front-loaded — the setup step feels like friction, and afterwards it becomes routine within days, adding perhaps a few seconds to a login that was already happening. The one-off cost of setup is consistently overestimated relative to the ongoing cost of using it, which is close to nothing.

What happens if a device generating codes is lost

This is precisely why backup codes are provided at setup. Store them somewhere safe and separate — printed and kept in a locked drawer, or stored in a password manager’s own secure notes feature. Don’t leave it as a problem to solve only once the primary device is already gone. A lost device with no backup codes available means going through an account recovery process, which is slower and more disruptive than simply having planned for the scenario in advance.

Enforcing this across a team, not just individually

Where a platform allows it, require two-factor authentication for every account with administrator-level access, rather than leaving it optional per person. This closes the gap of one team member deciding the extra step is not worth it and remaining the weakest link in an otherwise well-secured setup.

A quick way to check current coverage

Reviewing which of a business’s important accounts currently have two-factor authentication enabled, and which do not, takes a few minutes. It often reveals gaps nobody had specifically checked before — a worthwhile addition to the periodic access review covered in passwords, accounts and who has access.

The short version

Turn it on for the administrator, hosting and domain accounts this week, store the backup codes somewhere safe, and treat the small extra step at login as the cost of closing a real and common gap.

Where to go from here

Reviewing which accounts exist at all, and removing any that no longer need access, is the companion habit covered in passwords, accounts and who has access. Keeping both of these current on an ongoing basis is exactly the kind of task priced into what website maintenance costs.