Passwordless sign-in methods compared

At a glance

“Resists phishing” means what NIST means by it: the method itself stops a look-alike site from capturing something it can replay, without relying on the person noticing the address bar.

Email one-time codes

The person enters their address, receives a short code and types it back. It works on any device, including when the email arrives on a phone and the sign-in is on a laptop, which makes it the most forgiving method.

Its security is the mailbox’s security. A compromised inbox is a compromised account, and a look-alike site can ask for the code and relay it in real time. NIST SP 800-63B goes further and says email shall not be used for out-of-band authentication in the federal systems it covers. For most consumer and business apps, email codes remain a common, reasonable baseline when they are built carefully:

• codes of 6 digits or more, single use, expiring within minutes
• a few attempts per code, then a new code
• rate limits on sending and on checking, per address and per IP address
• the same response whether or not the address has an account
• the code bound to the browser session that asked for it

Magic links

The email carries a single-use link instead of a code. One click and the person is in, with nothing to type.

Two problems come with it. The link signs in whichever device opens it, so someone who asked on a laptop and opens the email on a phone is signed in on the phone. And email security scanners, common in workplaces, open links to check them, which can use up a single-use link before the person clicks.

The usual fixes are a confirmation page behind the link, so a scanner’s visit does nothing, and a code in the same email for signing in on the original device. Like an email code, a magic link is only as safe as the mailbox.

SMS one-time codes

Almost everyone has a phone that receives texts, and a code by text feels familiar. That reach is why SMS codes are everywhere.

The weaknesses are in the phone network. An attacker who talks a carrier into moving a number to a new SIM, or porting it to another carrier, receives the codes. NIST treats SMS and voice codes as a restricted authenticator and asks verifiers to weigh signs such as a recent SIM change or number port before relying on them. Codes by text can also be phished and relayed, like codes by email.

There are practical costs too: every code is a paid message, delivery depends on carriers, and numbers are reassigned when people give them up. In Canada, a code whose only purpose is to sign someone in is generally not a commercial message under CASL, so it does not need marketing consent; keep promotions out of it.

SMS works best to confirm a phone number you need anyway, or as a second step next to another method, rather than as the only way into an account that holds money or sensitive data.

If you send codes by text to Canadian numbers, HonkIO Verify sends and checks them: 6-digit codes by default, valid for 10 minutes, five attempts, and all-zero codes with a test key. A verification costs $0.25 plus the text that carries it ($0.28 for a one-segment code).

Passkeys

A passkey is a key pair a device creates for your site under the WebAuthn standard. The private key stays with the person, unlocked by their fingerprint, face or device PIN; your server keeps only the public key. There is no shared secret to steal from your database, and nothing to type.

Passkeys resist phishing by design: the browser only offers a passkey on the domain it was created for, so a look-alike site cannot ask for it. Most passkeys are synced by the platform or a password manager, so they survive a lost phone; a passkey on a hardware security key never leaves the key.

The hard parts are recovery and coverage. People sign in on shared or older devices, and someone who loses every device that holds their passkey needs another way back in. That fallback, often email, then becomes the weakest link, so protect it with the same care.

Choosing and combining methods

• Offer passkeys to everyone who can use them, and suggest creating one right after a successful sign-in
• Keep a fallback that works on any device, usually an email code, with tight limits
• Use SMS to confirm a phone number or as a second step, not as the only way into high-value accounts
• Treat account recovery as sign-in: rate limit it, notify the person, and ask for more before changing the email address or phone number
• Tell people when a sign-in method is added or a sign-in comes from a new device

Where the data lives matters as much as the method. Codes and links travel through email and SMS providers, and sign-in records are personal information: the guide to data residency for sign-in covers what Canadian privacy law asks.

Questions

Which passwordless method is the most secure?

Passkeys. They only work on your domain, so a fake site cannot capture and replay them, and your server stores only a public key. Email codes, magic links and SMS codes can all be phished, and are only as safe as the mailbox or phone number behind them.

Are SMS codes still acceptable?

For many apps, yes, especially to confirm a phone number or as a second step. NIST treats them as a restricted authenticator because of SIM swaps and number porting, so avoid making them the only way into accounts that hold money or sensitive data.

Magic links or email codes?

Codes work across devices and survive email security scanners; links are one click when the person reads email on the device they are signing in on. Many apps put both in the same email.

What happens when someone loses their passkey?

They sign in with your fallback method and create a new passkey. Synced passkeys usually survive the loss of one device, because they are restored from the person’s platform account or password manager.

Do sign-in codes need consent under CASL?

A code whose only purpose is to let someone sign in is generally not a commercial electronic message, so it does not need CASL consent. Adding a promotion to it changes that. This is general information, not legal advice.

Sources

The laws, regulator guidance and standards this guide draws on, checked in October 2026. If something has changed, tell us at support@honkio.ca and we will correct it.

1. NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
2. Web Authentication: An API for accessing public key credentials, Level 2 (W3C)
3. Passkeys (FIDO Alliance)
4. Implementing phishing-resistant MFA (CISA fact sheet)
5. Canada’s Anti-Spam Legislation, S.C. 2010, c. 23 (Justice Laws)