What is the difference between TOTP, push notifications, hardware keys, and biometrics for MFA?

TOTP and push notifications are convenient app-based second factors, but both can still be phished if a user is tricked into approving access or sharing a code. Hardware keys are the most phishing-resistant because they require a physical device. Biometrics are also resistant to phishing and often easier for users, but they depend on supported hardware and raise user comfort concerns.

How these MFA factors differ in practice

TOTP, push, hardware keys, and biometrics all improve account protection, but they fail in different ways. The practical difference is not just convenience, it is how each factor resists phishing, how much user interaction it requires, and what assumptions it makes about the device, authenticator, or human performing the approval.

TOTP is a time-based code, so the code can be relayed if the user is tricked in real time. push notifications reduce typing friction, but the approval step can become a weakness if users rubber-stamp prompts. Hardware keys bind authentication to a physical token and the site origin, which is why they are usually the strongest option against phishing. Biometrics improve usability, but they depend on supported hardware and operating-system integration rather than being a standalone secret the user can simply carry anywhere.

For a practitioner comparing them, the main trade-off is that stronger phishing resistance usually comes with a more specific deployment model. Hardware keys and biometrics are often more robust than app-based second factors, but both require compatible devices and a clearer rollout plan than generic one-time codes.

Where the security boundary actually moves

The important question is where trust is being placed. With TOTP, trust sits in the shared secret and the user’s ability to recognise a fraudulent login flow. With push, trust shifts to the approval decision, which creates exposure to prompt fatigue and social engineering. Hardware keys move trust toward possession of a cryptographic device and a genuine origin check. Biometrics move trust toward the local device’s sensor and unlock path, which means the quality of the implementation matters as much as the factor itself.

This is why two methods that both count as MFA can have very different assurance outcomes. A push prompt may still be easy to abuse if the attacker has already obtained a password and can pressure the user into approving. A hardware key is materially different because it reduces the chance that a code or approval can be replayed from a remote phishing page. Biometric prompts are usually more resistant than simple knowledge-based factors, but they still depend on how the platform stores and verifies the biometric template.

If you are designing policy, the distinction is less about “MFA or not” and more about whether the factor resists relay, replay, and coercion in the threat model you actually face.

Choosing the right factor for your environment

The best choice depends on the balance between user friction, device availability, and the sensitivity of the protected system. For high-value administrative access, hardware keys are usually the safest default because they reduce phishing success and do not rely on a human making a separate approval decision. For broad workforce rollout, TOTP or push may be easier to adopt, but they should be treated as weaker and more phishable than cryptographic authenticators. Biometrics are often best when the platform already supports them natively and when user experience matters, but they should be paired with a strong fallback and a clear recovery process.

Implementation details matter here. If the organisation allows fallback to SMS, shared recovery codes, or weak reset workflows, the strongest MFA factor can be undermined by the account recovery path. If the platform does not enforce origin binding or device attestation, “MFA” may still leave room for phishing and session theft.

For teams with mature identity controls, the goal is not to pick one factor for every case. It is to use the strongest available method where the risk justifies it, and to avoid treating a convenience-oriented factor as equivalent to a phishing-resistant one.

Risk and Threat Considerations

Phishing and approval abuse are the main threats that separate these MFA methods. TOTP and push factors can be defeated when an attacker captures a password and then tricks the user into entering or approving the second factor, while hardware keys and well-implemented biometrics reduce that path because they are harder to relay or approve remotely.

Failure mechanism: The control fails when the attacker can reuse a stolen password in a live phishing session, or when the user can be manipulated into approving the login without recognising the real destination or context.

Impact: A successful bypass can lead to account takeover, privileged session access, and downstream access to applications, data, or administrative functions that were supposed to be protected by MFA.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL — Authentication Assurance Levels	Differentiates MFA strength and phishing resistance for this login decision.
	C — Authenticator Assurance	Covers authenticator properties such as phishing resistance and binding to the authenticating device.
Recommendation — Match the required assurance level to the account's sensitivity and preferred authenticator type. Prefer authenticators with stronger resistance to relay and approval abuse.
CIS Controls v8	6 — Access Control Management	Covers practical account access choices, MFA enforcement, and recovery-path hardening.
Recommendation — Enforce stronger MFA for sensitive accounts and remove weaker fallback paths.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Applies because the question compares authentication methods and their control strength.
Recommendation — Select authentication methods that reduce phishing and strengthen access assurance.
GDPR	Art.9 — Special categories of personal data	Biometrics are regulated as special-category data when used for identification or authentication.
Recommendation — Assess biometric handling and lawful basis before deploying biometric MFA.

Practitioner Guidance

What to verify: Treat the factor choice as a control-strength decision, not a branding decision. Verify whether your login flow blocks origin replay, whether push approvals include enough context for users to make a real decision, and whether recovery paths are stronger than the MFA method itself.

Decision rule: If the account can reach sensitive systems, prefer hardware keys or platform biometrics over push or TOTP, and reserve weaker factors for lower-risk access or temporary onboarding states.

Practitioner takeaway: The real question is not which MFA method is “multi-factor,” but which one still holds up when the attacker already has the password and is trying to win through phishing, approval fatigue, or weak recovery.