Time-based one-time passwords require the user to enter a code that expires after a short window, which makes them more resistant to phishing than static passwords. Magic links send an email link that grants access when clicked, so the user experience is simpler but the flow depends heavily on email security. The right choice depends on risk tolerance and the login context.
Why Time-Based Codes and Magic Links Solve Different Login Problems
Time-based one-time passwords and magic links both reduce dependence on reusable passwords, but they do it in different ways. A time-based code proves the user can access a short-lived secret and enter it correctly, while a magic link proves control of the email inbox and turns the inbox into the authentication channel. That difference matters because the trust boundary moves from memorisation to device possession in one case and to email delivery and inbox security in the other.
For teams choosing between them, the real question is not which is more modern, but which failure mode is more acceptable. Time-based codes are stronger against simple credential reuse, but they still depend on the login flow, the device handling the code, and user behaviour under pressure. Magic links are easier for users, but they inherit the security posture of email, which can be weaker than the application itself. Current guidance suggests treating the email account as part of the authentication surface when magic links are used, because mailbox compromise can become account compromise.
That is why passwordless design is as much about trust boundaries as it is about usability. In practice, many security teams discover the real weakness only after the inbox, device, or recovery path has already become the easiest way in.
How They Work in Practice
Time-based one-time passwords, often delivered by an authenticator app, generate a code that is valid only for a short window. The user types the code into the application, and the server verifies that the code matches the expected value for that time slice. This makes the factor ephemeral, but not magical: if an attacker can phish the code in real time, intercept the session, or coerce the user into entering it into a fake site, the control can still fail.
Magic links work differently. The application sends a link to the user’s email address, and clicking that link completes the login. The practical benefit is low friction, especially for low-resistance consumer flows or occasional access. The trade-off is that the email account becomes the gatekeeper. If the mailbox is already compromised, or if forwarding rules, shared inboxes, or weak recovery controls exist, the link can be reused by an attacker before the intended user sees it.
- Time-based codes are usually better when you want a second factor that is not fully dependent on email delivery.
- Magic links are usually better when user convenience matters more than strict separation between identity proof and inbox access.
- Both options need strong session controls, because authentication strength is weakened if the post-login session is easy to hijack.
For a broader control lens, NIST guidance on authentication and session assurance is useful, and NIST’s control catalogue can help teams tie the login method to broader access governance. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is also relevant when passwordless patterns are reused for machine or service access, where rotation and visibility matter as much as user convenience.
These controls tend to break down when email is widely federated, heavily forwarded, or shared across multiple users, because the login decision becomes less about the user and more about the least protected mailbox in the path.
Common Variations and Edge Cases
Tighter passwordless controls often increase user friction or operational overhead, so organisations need to balance assurance against support cost and recovery complexity. A magic link can be the right answer for low-risk access, but it becomes a poor fit when the email account is not strongly protected or when the application handles sensitive data and privileged actions.
There are a few important edge cases. Time-based codes may be a better fit than magic links when users switch devices frequently, because code entry is less dependent on a single inbox. Magic links may work well for short-lived, low-risk access events, but they are a weaker choice when the user’s email account is also used for password reset, account recovery, or administrative approvals. In those cases, one compromised mailbox can unlock multiple paths into the same account.
Another subtle issue is assurance drift. Teams sometimes treat either method as inherently “passwordless” and stop there, but neither method removes the need for binding, session expiry, suspicious-login detection, or recovery hardening. The right choice depends on whether the organisation can tolerate inbox-based authentication and whether it can keep the recovery path from becoming the easiest attack path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question is about authentication method choice and trust boundaries. |
| Recommendation — Align login design to identity assurance and enforce the right authentication strength for the use case. | ||
| CIS Controls v8 | 6 — Access Control Management | Passwordless methods still depend on access governance and account recovery controls. |
| Recommendation — Harden account access and recovery paths so authentication strength is not undercut downstream. | ||
| NIST SP 800-63 | 5.1.2 — Authentication Assurance and Binding | TOTP and magic links differ in assurance, binding, and proof strength. |
| Recommendation — Use the appropriate authenticator assurance level and bind the factor to the intended user. | ||
| NIST Zero Trust (SP 800-207) | 3.3 — Policy Decision Point | The login flow depends on contextual trust and real-time access decisions. |
| Recommendation — Evaluate access in context instead of trusting a single login event as permanent proof. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Secret Management | Magic links and time-based codes rely on short-lived secrets and delivery integrity. |
| Recommendation — Protect short-lived credentials and invalidate them immediately after successful use. | ||
Practitioner Guidance
What to prioritise: Decide first whether the login flow needs stronger separation from email or whether simplicity is the primary goal. If the account can initiate sensitive actions, favour the option that leaves less residual trust in the inbox and more control over session lifetime.
Decision rule: If email compromise would be enough to compromise the account, do not treat magic links as a low-risk convenience feature; treat them as an authentication dependency that needs the same scrutiny as any other access path.
What to verify: Confirm how the user recovers access, how links are invalidated after use, and whether session tokens outlive the assurance provided by the login method. If those controls are weak, the passwordless method is doing less work than the design assumes.
Practitioner takeaway: The important decision is not code versus link in isolation, but whether the chosen method matches the trust level of the account, the sensitivity of the action, and the resilience of the recovery path.
Related resources from NHI Mgmt Group
- Which controls matter most when comparing magic links with one-time passwords for authentication flows?
- What is the difference between SMS one-time passcodes and mobile network based authentication?
- What is the difference between biometric authentication and one-time passwords in financial services?
- What is the difference between passwordless authentication and password-based access?
