The user types their email; the platform emails a link; clicking the link signs them in. No code to type; no password to remember. The lowest-friction email-only sign-in.
Enable
Section titled “Enable”Authentication → Magic link. Toggle on.
Configuration:
- Link TTL — 15 minutes (default). The trade-off between user convenience and the window of risk if an attacker intercepts the email.
- One-time use — on (default). The link is invalidated after first click. Don't turn off; this is the whole point.
- Send rate — max 3 links per user per 15 minutes (default). Stops accidental double-click + brute-force.
- Same-device verification — on (default). The platform refuses to sign in if the click comes from a different device than the request. Defends against email-account hijacks where the attacker has the email but not the user's device. Some users find this annoying; turn off ONLY if you've thought about the trade-off.
Save.
What the user sees
Section titled “What the user sees”Sign-in page → "Send me a sign-in link" → enter email. The page shows "Check your email for a link". Email arrives:
Click below to sign in to Cymmetri Banking.
[Sign in to Cymmetri Banking]
Link expires in 15 minutes.Didn't request this? Ignore this email.Click. They're in. Their browser tab on the original page also gets the green-tick "you're now signed in" — same-device verification confirms the click came from the right browser.
Magic link vs email OTP
Section titled “Magic link vs email OTP”Both passwordless; both email-based. The trade-offs:
| Magic link | Email OTP | |
|---|---|---|
| Steps | Click | Type code |
| Same-device check | Yes (default) | Effectively no — once typed anywhere, in |
| Works on a device without browser | No | Yes |
| Common pitfall | User clicks on phone, expects to be signed in on laptop | User mistypes the code |
| Phishing resistance | Slightly better (the link's target is your domain) | Slightly weaker (the code is content-free) |
Many tenants enable both — the user picks. The sign-in page asks "send me a code" vs "send me a link" via a small toggle.
Same-device verification — the friction
Section titled “Same-device verification — the friction”The default behaviour: open the request on device A, click the link on device A (same browser). If the user opens the email on their phone but the original sign-in attempt was on their laptop, the click won't sign them in on the laptop.
This catches a real attack — an attacker with email access but not the user's device — but it's also a common cause of "the link doesn't work for me" support tickets. Two ways to soften:
- Turn off same-device verification. Trade-off: lose the defence.
- Show clear copy on the sign-in page: "Open the link on the same device + browser where you started." Saves about 80% of support tickets.
Cross-device flow (if you turn off same-device)
Section titled “Cross-device flow (if you turn off same-device)”The user requests the link on laptop, opens email on phone, clicks. The phone signs in to a new session; the laptop's "waiting" page eventually times out.
This is fine UX-wise but loses the protection. Most B2C tenants leave same-device on; most internal-tool tenants do too.
Phishing posture
Section titled “Phishing posture”Magic links land in the user's inbox. The user clicks. The link target is YOUR tenant's domain. If the user is paying attention, the link points to a familiar host.
Caveat: the email itself can be phished. An attacker who knows your design conventions can send a fake "Sign in to Cymmetri Banking" email that links to their own site. Mitigations:
- DMARC + reject policy on your sending domain (your real magic-link emails are signed; the fakes aren't).
- Brand the email recognisably — colours, your logo, your support contact.
- Email copy that mentions the tenant by name in the body, not just the subject.
Magic links AREN'T phishing-resistant the way WebAuthn is. They're meaningfully better than passwords + meaningfully worse than passkeys.
What if the user clicks the link after expiry?
Section titled “What if the user clicks the link after expiry?”The platform shows "this link has expired" with a button to request a fresh one. They re-enter email, get a new link, click. No state lost.
Disable
Section titled “Disable”Toggle off; existing magic links in flight are invalidated immediately. Users on the sign-in page no longer see the "send me a link" option.
If your tenant moved from magic-link-primary to password-primary, expect a brief support spike as users wonder where the option went. Brief comms helps.