What is the difference between TOTP and WebAuthn for enterprise MFA?

How TOTP and WebAuthn differ in enterprise MFA

TOTP is a shared-secret code generator, which means the verifier and the authenticator both rely on the same underlying secret. That design is easy to deploy, but it also means the factor can be copied, relayed, or harvested if an attacker gets the code or the seed. WebAuthn uses asymmetric cryptography and checks the website origin during sign-in, so the credential cannot be reused against a lookalike site.

The practical difference is not just usability, it is trust model. TOTP proves possession of a secret that can be replayed in the wrong place, while WebAuthn proves possession of a private key bound to a genuine origin. In enterprise terms, that makes WebAuthn materially stronger against phishing, adversary-in-the-middle capture, and credential replay during interactive login.

For security teams, the important distinction is that TOTP still leaves room for interception at the human interaction layer, while WebAuthn removes the attacker’s ability to present a fake login page and successfully reuse the factor. That is why WebAuthn is commonly treated as phishing-resistant MFA, especially when paired with strong recovery controls and device assurance.

Why WebAuthn changes the phishing and replay equation

With TOTP, the code is short-lived, but it is still a bearer code. If malware, a browser session, or a phishing kit captures it quickly enough, the attacker can use it before it expires. The seed that generates the codes is even more sensitive, because once it is stolen the attacker can produce valid codes whenever they want. NHIMG’s MFA Guide covers the common bypass paths around one-time passwords, including relay, fatigue, and legacy fallback weakness.

WebAuthn changes the attack surface by tying authentication to the actual relying party origin. The authenticator will not sign a challenge for a lookalike domain, so a convincing fake portal is not enough on its own. That makes the control much harder to bypass through ordinary phishing, and it reduces the value of intercepted credentials because the signed assertion is scoped to the destination site rather than to a reusable shared secret.

Enterprise rollouts usually benefit most when WebAuthn is the default for workforce sign-in, not a premium option reserved for privileged users only. NHIMG’s Passwordless and Passkeys Guide is a useful companion for understanding how WebAuthn, passkeys, and FIDO2 fit together in a modern authentication stack.

What enterprises should consider when choosing one or both

TOTP remains useful as a compatibility layer, a fallback, or a temporary bridge during migration, but it should not be treated as equivalent to phishing-resistant MFA. If the business still depends on TOTP, the operational question is whether the code path is protected well enough against phishing kits, SIM-related fallback routes, and help-desk recovery abuse. If the answer is no, the control is only partially compensating for weak password-based access.

WebAuthn is stronger, but it introduces its own deployment decisions. Enterprises need to think about device enrollment, recovery, cross-device use, roaming authenticators, and how to handle staff who lose their primary authenticator. Those choices matter because a phishing-resistant primary factor can be undermined by a weak recovery path, especially if reset workflows are easy to social-engineer.

For workforce programs, the best outcome is usually a migration path that keeps TOTP only where necessary and moves sensitive applications, admins, and high-risk users to WebAuthn first. NHIMG’s Workforce Identity Security Guide is a good reference for aligning phishing-resistant MFA with SSO, recovery, and session protection.

Risk and Threat Considerations

TOTP fails most often when the attacker can observe or relay the code in real time, or when the seed leaks and the factor is effectively cloned. That means the residual risk is not theoretical: a user can enter a valid code into the wrong site and still hand access to an attacker. WebAuthn materially reduces that risk because the browser and authenticator verify the origin before completing the assertion.

Failure mechanism: A shared secret or one-time code can be intercepted, relayed, or replayed faster than the organisation can detect the fraudulent login, especially when phishing kits or malware sit between the user and the real service.

Impact: The attacker gets a valid sign-in event that looks legitimate, which can lead to account takeover, session theft, access to admin consoles, and follow-on movement into email, SaaS, or internal systems.

Practitioner Guidance

What to verify: Treat WebAuthn as phishing-resistant only if the login flow truly checks origin, the enrolled authenticators are managed, and recovery does not fall back to an easier but weaker path. If recovery can be reset through a weak process, the stronger factor is only protecting the front door.

Decision rule: Use WebAuthn for any role where phishing, credential theft, or session hijacking would create material business impact. Keep TOTP only as a transitional or constrained fallback, and assign it a lower trust level in your access policy.

Practitioner takeaway: The right comparison is not “code versus no code”, it is “replayable shared secret versus origin-bound cryptographic proof”, and that difference is what makes WebAuthn the better enterprise control for phishing resistance.

Related resources from NHI Mgmt Group

• Why do TOTP codes and push MFA create more account takeover risk than WebAuthn security keys?
• How should security teams choose between U2F, WebAuthn, and other hardware MFA protocols for enterprise access?
• What is the difference between TOTP MFA and SMS-based MFA for enterprise access control?
• How do SSO, MFA, and passwordless compare as enterprise authentication options?