Two-factor authentication: which second factor, and where it still fails

Two-factor authentication asks for something beyond the password — a code, a tap, a key — so that a stolen password on its own is not enough. It is the cheapest meaningful improvement available to a small business, and the reason is arithmetic rather than ideology: passwords leak constantly, in breaches of unrelated services, and people reuse them.

The part usually skipped is that the factors are not equivalent. Some stop the attack small businesses actually meet, which is a convincing fake login page, and some do not.

The factors, weakest to strongest

• SMS codes. Better than nothing and the weakest option: interceptable, and vulnerable to somebody persuading a phone company to move the number. Use it only where nothing else is offered.
• Email codes. Roughly as weak, and circular if the email account is what you are protecting.
• Authenticator apps generating time-based codes. A large step up — nothing to intercept — and still typed by a person, which means it can be typed into a fake page.
• Push approval. Convenient and vulnerable to fatigue: people tap approve on the tenth prompt at midnight. Number-matching versions are meaningfully better.
• Passkeys and hardware security keys. The only options that resist a fake login page, because the credential is bound to the real domain and simply will not work on a lookalike.

The attack that reaches small businesses is almost never a technical break. It is an email that looks like a login prompt, a page that looks like the real one, and a person entering both password and code within a minute. Codes typed by a human can be relayed by an attacker in real time; a passkey cannot, because it checks the domain itself. That distinction is the whole argument for moving to passkeys where they are offered.

Rolling it out without a rebellion

1. Start with the accounts that unlock everything else: email, the domain registrar, the password manager, banking, and anything holding customer data.
2. Enrol the administrators first, including the person who would have to fix a lockout.
3. Set recovery up before you need it: backup codes stored somewhere physical, or a second registered key. This is where most small deployments break.
4. Give people a fifteen-minute walkthrough rather than a policy email. Adoption stalls on confusion far more often than on objection.
5. Check what happens when somebody leaves or loses a phone, and write it down. If the answer is one person can fix it, that person is a single point of failure.
6. Only then extend to everything else, and prefer passkeys where the service supports them.

Where it still fails

Two-factor authentication does not help if the session token is stolen after login, if a service offers a weaker fallback the attacker can choose, or if recovery is easier than the login itself — an account protected by a hardware key and recoverable by a security question is protected by the security question. It also does nothing about a device already compromised. None of that argues against enabling it; it argues for checking the recovery path with the same attention as the login.

Where Ettex fits

Ettex Teams is where team members and their access live, and the account-level side supports passkey sign-in — the phishing-resistant option above — alongside conventional login. Who should have access to what is a separate question, covered in access control policy, and the surrounding rules in information security policy.

The limits, plainly: we do not provide a hardware key programme, do not run device management, and cannot enforce two-factor authentication on the other services your business uses. Those are switched on individually, in each service, and the list of which ones matter most is the first step above.