TL;DR: One-time codes remain widely used for MFA, but the article argues they are vulnerable when delivered over SMS or email, can collapse into two forms of the same factor, and add user friction that drives abandonment, according to Beyond Identity. Passwordless MFA reduces those weaknesses by removing passwords from the factor set and shifting trust to device-bound cryptographic keys and biometrics.
At a glance
What this is: This article compares one-time-code MFA with passwordless MFA and finds that code-based authentication can still fail when delivery channels, password reuse, or user friction undermine the factor model.
Why it matters: IAM and CIAM teams need to treat MFA as a design problem, because weak factor composition and poor user experience can both increase takeover risk and reduce adoption.
Context
One-time codes are often treated as MFA, but their security depends on how the code is delivered and what else the user must know or possess at login. When the code rides over SMS or email, the control can inherit the weaknesses of the delivery channel and of the underlying account used to receive it.
For identity programmes, the real issue is factor independence. If the second factor depends on the same password class, the same device, or the same recovery path, the system may still look like MFA while offering much less assurance than the label suggests.
Key questions
Q: What makes one-time codes weaker than they look in MFA designs?
A: One-time codes only help when the delivery channel and the receiving account are independently trustworthy. SMS can be intercepted, email often depends on another password, and reuse can collapse both factors into the same compromise path. The result is MFA in name, but not always in assurance.
Q: How should teams decide when passwordless MFA is worth the change?
A: Choose passwordless MFA when phishing resistance, account takeover reduction, and predictable user completion matter more than preserving password-based recovery flows. It is most valuable when the organisation can support device-bound keys, biometric confirmation, and a clean fallback model that does not reintroduce shared secrets.
A: A control is failing when the attacker can capture a valid token in transit and reuse it before the legitimate user notices. Warning signs include unexpected lockouts, proxy-style logins, or successful sign-ins that follow a phishing event. Those patterns show the factor was accepted, but the session itself was not trustworthy.
Q: Should organisations keep SMS or email codes as a backup factor?
A: Only if the backup is tightly limited and the risk is acceptable, because both channels can be weaker than teams assume. In many environments, they are better treated as transitional or recovery mechanisms than as a preferred MFA design. The safer default is a phishing-resistant primary factor with minimal secret exposure.
Technical breakdown
Why one-time codes can collapse into weak MFA
One-time codes are usually presented as a possession factor, but that only holds if the delivery channel is itself trustworthy and independent. SMS can be intercepted through SIM swap or telecom weaknesses, and email codes often depend on another password-protected account, which can turn the supposed second factor into a second instance of the same factor class. In practice, the factor model matters more than the checklist label. If the same compromise path unlocks both the primary account and the code channel, the authentication strength is far lower than teams assume.
Practical implication: validate whether each MFA factor is independently resistant to the same compromise path, not just whether a second prompt exists.
Why passwordless MFA changes the authentication trust model
Passwordless MFA replaces password dependence with asymmetric cryptography and device-bound keys, typically protected by hardware such as a TPM and paired with a biometric or similar inherence check. That changes the trust anchor from a shared secret to a private key that is not meant to be copied or reused across accounts. The result is not just fewer steps, but fewer recovery and reuse paths for attackers to exploit. For identity architecture, this is a material shift from knowledge-based verification to device-centred assurance.
Practical implication: design authentication around device-bound keys and avoid reintroducing shared secrets through fallback paths.
Why user friction is an identity security issue, not just a UX issue
The article makes a practical point that often gets missed in MFA planning: friction changes security outcomes. A control that delays codes, requires a second device, or adds repeated prompts increases abandonment, which can push teams toward weaker fallback methods or create user pressure to bypass the control entirely. Security and adoption are linked. If an MFA method is hard to use, the business may end up preserving the label while eroding the actual protection through workarounds, recovery flows, or selective enforcement.
Practical implication: evaluate MFA methods against both assurance and abandonment risk, especially where customer conversion or workforce productivity matters.
Breaches seen in the wild
- Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
One-time codes are a delivery-dependent control, not a durable authentication factor. Their strength varies with SMS routing, email security, device access, and the password state of the receiving account. That means the security label can overstate the actual assurance provided. The practitioner conclusion is simple: treat code delivery as part of the attack surface, not as proof of factor independence.
Passwordless MFA reduces shared-secret exposure, but only if fallback paths do not reintroduce it. The article is right to focus on device-bound keys and biometrics, because they remove the most common password reuse and phishing failure modes. But identity teams still need to inspect recovery, reset, and enrollment flows, where weak alternatives often creep back in. The practitioner conclusion is to govern the full authentication journey, not just the primary login.
Factor composition matters more than factor count. Two prompts are not automatically two distinct factors if both rely on the same knowledge secret or the same compromised channel. This is the practical lesson for both CIAM and workforce programmes: assurance comes from independence between factors, not from the number of boxes checked. The practitioner conclusion is to audit whether your MFA design actually survives credential theft, SIM swap, and mailbox compromise.
User friction is itself a security control variable. Code-based MFA can drive abandonment, delayed completion, or workarounds that weaken enforcement. That creates a governance problem, because the organisation may believe it has stronger authentication while operational behaviour pushes users back toward less secure paths. The practitioner conclusion is to align the authentication method with the risk profile and the tolerance for user drop-off.
Device-bound authentication is a more stable pattern for modern identity governance. Passwordless MFA is less about removing inconvenience than about removing brittle trust assumptions inherited from passwords and one-time-code delivery. That makes it more compatible with phishing-resistant authentication strategies and with programmes that want predictable assurance at login. The practitioner conclusion is to prefer factors that remain valid even when the user’s email, phone number, or password state changes.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Factor independence is the governing concept here: a second prompt does not equal a second factor if both depend on the same password or the same compromised delivery path. Identity teams should judge MFA designs by whether they survive mailbox compromise, SIM swap, and password reuse, not by whether they present a familiar login sequence.
Authentication policy has to account for abandonment as well as attack resistance. If a control regularly drives users to bypass it, lean on recovery, or abandon a transaction, the programme may be preserving compliance optics while weakening actual assurance.
Passwordless MFA changes the control boundary: it shifts trust from reusable secrets to device-bound credentials, which is more durable in environments where phishing and credential stuffing are persistent threats. The practical question for programmes is no longer whether MFA exists, but whether the factor set is truly resistant to common compromise paths.
For practitioners
- Audit factor independence Map each MFA method to the actual compromise paths that can defeat it, including SMS interception, mailbox takeover, password reuse, and recovery channel abuse.
- Reduce shared-secret reliance Replace password-plus-code designs where possible with device-bound cryptographic authentication and biometric confirmation, and remove backup secrets from the primary flow.
- Review recovery and fallback flows Check whether account reset, enrollment, and step-up paths quietly reintroduce passwords or one-time codes as the effective second factor.
- Measure abandonment and completion rates Track where code delays, second-device dependence, or repeated prompts cause drop-off in registration, sign-in, or checkout journeys.
Key takeaways
- One-time codes can look like MFA while still inheriting the weaknesses of SMS, email, and password reuse.
- The central evidence is not factor count but factor independence, because the same compromise path can defeat both the password and the code channel.
- Passwordless MFA is most useful when teams want phishing resistance without adding recovery flows that recreate the very secrets they were trying to remove.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and factor strength are central to the article's comparison of MFA methods. |
| IA-2 — Identification and Authentication (Organizational Users) | The article addresses workforce authentication design and assurance quality. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | The article also discusses customer-facing MFA and online conversion flows. | |
| Recommendation — Apply IA-5 to remove weak shared-secret factors and govern fallback authenticators tightly. Use IA-2 to require stronger authentication patterns for users where phishing resistance matters. Apply IA-8 to align customer authentication strength with account takeover risk and recovery design. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about whether authentication controls actually enforce intended access assurance. |
| Recommendation — Review authentication policy against PR.AA-05 to ensure access decisions rely on durable factor assurance. | ||
Key terms
- One-Time Code MFA: A multifactor pattern that sends a temporary code by SMS, email, or an authenticator app to confirm a login. It is weaker when the delivery path, recovery path, or underlying password can be intercepted, reused, or socially engineered, because the second factor may not be truly independent.
- Passwordless MFA: An authentication approach that replaces passwords and code-based second factors with device-bound cryptography and local user verification. The user proves possession of a trusted device and then unlocks it with a biometric or similar control, reducing reliance on reusable secrets and delivery channels that can be intercepted.
- Factor Independence: The degree to which each authentication factor relies on a different trust anchor, device path, or failure mode. Independent factors are harder to defeat together. If one reset channel or one device compromise can bypass all factors, the system may appear layered while remaining functionally single-point.
- Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 29, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org