Multi-factor authentication is not one control. It is a family of methods with very different strengths, and the question "do we have MFA?" hides the question that matters: which factor, and what can an attacker still do against it?
This guide compares the common options, explains where each one fails, and ends with a way to assign factors by role rather than choosing a single answer for everyone.
Two questions to ask of every factor
- Can it be phished? If a person can be tricked into handing the factor to a fake site, an attacker who runs that site can relay it in real time.
- What happens when it is lost? The recovery path is usually the weakest part of the whole system.
NIST SP 800-63B, the digital identity guideline, draws the same distinction between authenticators that can be intercepted or relayed and those bound cryptographically to the legitimate site. It is worth reading the authenticator sections once.
Tip
Start with administrators. They carry the most risk and are the easiest group to give a security key or passkey.
One-time codes from an app (TOTP)
Time-based one-time passwords, specified in RFC 6238 (built on the counter-based scheme of RFC 4226), are the six-digit codes that change every thirty seconds.
The phone and the server share a secret at enrolment, usually through a QR code, and each side computes the code from that secret and the current time.
Strengths:
- Works offline, with no network at the time of sign-in.
- No per-message cost, no dependency on a mobile carrier.
- Widely supported by any compliant authenticator app.
Weaknesses: - Phishable. A person who types a code into a fake page gives it away, and the attacker uses it within its validity window. - The shared secret sits on the server and on the phone.
A stolen phone backup can carry it. - Clock drift occasionally causes failures; servers usually accept one step either side.
TOTP is a sensible baseline for most staff. It is a clear improvement over passwords alone and costs almost nothing to run.
SMS codes
A code sent by text message is easy to roll out because everyone has a phone number. It is also the weakest common factor.
Messages can be diverted through number porting or SIM swap fraud, can be read on lock screens, and depend on carrier delivery, which is unreliable at times. Our article why SMS OTP is not enough goes through the attack paths.
If you keep SMS, keep it as a fallback for low-risk roles, not as the primary factor for administrators.
Push approval
In a push scheme, the phone shows a prompt, "Approve this sign-in?", and the person taps yes or no. It is friendly to use, but it has a known failure mode: push fatigue, also called prompt bombing.
An attacker who already has the password triggers prompt after prompt, perhaps late at night, until the person taps approve to make it stop.
Mitigations exist: number matching (the person types a number shown on the sign-in screen), showing location and application context, and rate limiting. These help but do not make push phishing resistant.
To be transparent: AuthMantra does not offer push-notification MFA today. It offers authenticator-app codes (TOTP), SMS codes, passkeys and security keys. The discussion of push here is general, so you can judge it fairly in any product you evaluate.
Passkeys and hardware security keys
Passkeys and security keys use public-key cryptography under the W3C Web Authentication standard (WebAuthn) and the FIDO Alliance's FIDO2 and CTAP2 specifications.
The device holds a private key that never leaves it, and the browser binds each sign-in to the website's real origin. A fake site on another domain simply cannot obtain a valid response.
That is what "phishing resistant" means, and it is the property that codes and push prompts lack.
Two forms matter in practice:
- Platform passkeys live on a phone or laptop and unlock with Face ID, Touch ID or Windows Hello. They are convenient and often sync across a person's devices.
- Security keys are physical USB or NFC devices. They need a purchase and a distribution process, but give you a factor that is independent of any phone.
See passkeys explained for how the protocol works under the surface.
Weaknesses to plan for: lost or broken keys, devices that are not compatible, and the recovery path (below).
Comparison
| Factor | Phishing resistant | Works offline | Main risk | Cost to run |
|---|---|---|---|---|
| SMS code | No | No | SIM swap, interception | Per message |
| TOTP app | No | Yes | Real-time relay | Very low |
| Push approval | No (partly with number matching) | No | Prompt fatigue | Low |
| Passkey | Yes | Yes | Device loss, sync account takeover | Low |
| Security key | Yes | Yes | Loss of the key | Hardware purchase |
Recovery decides everything
An attacker does not need to defeat your strongest factor if the recovery flow is weak. Review it carefully:
- If "forgot my authenticator" can be satisfied with an email link alone, then your effective strength is the strength of the mailbox.
- Require at least two registered methods per person, so losing one device does not lock them out.
- Route recovery for privileged accounts through a human check, such as a manager or the IT desk with a call-back to a known number.
- Log every factor reset, and alert on a reset followed by a new enrolment. Both belong in your identity log stream.
- Make administrators pass step-up authentication again before they change someone else's factors.
Assign factors by role
A single policy for everyone either frustrates people or under-protects the few who matter. A tiered approach:
- All staff: TOTP minimum; passkeys offered, then encouraged.
- Administrators and finance approvers: passkeys or security keys required, no SMS.
- Shared or kiosk devices: security keys, since personal phones may not be allowed.
- Contractors: whatever you can enforce at enrolment, with a hard expiry on the account. See contractors and vendors with expiry.
What to do this week
- List which factors each group of staff can use today, and which are allowed as fallback.
- Find out how recovery works for an administrator who loses a phone, and test it.
- Remove SMS as an option for privileged roles.
- Choose a pilot group of 10 to 20 people for passkeys or security keys.
- Write the recovery procedure on one page and agree who approves exceptions.