You shipped passwordless login. The demo was flawless - one click from the inbox, no password to forget. Then it went live to business customers, and your support inbox grew a recurring subject line: "the link doesn't work."

Here's the frustrating part: you can't reproduce it. It works on your laptop, your phone, every account you own. But your users are finance teams, IT admins, operations staff - people whose email runs through a corporate security gateway. For them, magic links fail in a way that never shows up in your testing, and every failure is a login your customer couldn't complete and a ticket your team has to answer.

This isn't a bug you can patch. It's a mismatch between a consumer-app default and how business email actually works. Here's what's happening, and why one-time codes (OTP) are the more reliable default the moment your users are on work email.

The failure you don't see in testing

Magic links work perfectly on your laptop and your personal Gmail. That's exactly why this bites in production and not in QA: the thing that breaks them isn't in your app or the user's browser. It's the mail pipe in between.

Corporate email security gateways - Microsoft Defender for Office 365 (Safe Links), Mimecast, and Proofpoint - scan inbound mail for malicious URLs. To do that, they fetch every link in the email before the recipient ever sees it. A magic link is, by design, a single-use URL that logs the user in and then invalidates itself.

Put those two facts together:

1. The email arrives at the gateway.
2. The gateway pre-fetches the magic link to scan it - this consumes the one-time token.
3. The email lands in the user's inbox.
4. The user clicks the link and gets "invalid or expired token."

The user did everything right. The link was dead before it reached them. And this isn't a rare edge case in B2B - it's the default behavior of the email infrastructure your customers' IT departments have deliberately installed.

Two more ways magic links misfire on work accounts

The scanner problem is the headline, but it travels with two quieter siblings.

Wrong-browser landing. A magic link opens wherever the email client decides - the webmail app's in-app browser, or the OS default browser. That is frequently not the browser the user started the login in. They authenticate successfully… in a tab they aren't looking at.

No cross-device path. Started the login on your desktop but only have your phone handy? With a link, you're stuck: clicking it on the phone logs the phone in, not the desktop.

Why OTP dodges all of it

A one-time passcode inverts the delivery model. Instead of emailing a URL that must be clicked, you email a short code that must be read and typed.

That single change neutralizes every failure above:

• Scanners can't consume it. There's nothing to click. A gateway pre-fetching links doesn't invalidate a six-digit number sitting in the body as text.
• It's device-agnostic. Start on your laptop, read the code off your phone, type it into the laptop.
• It lands where the user already is. No browser hand-off, no "which window am I signed into?"

The cost is one extra beat of friction: typing six digits instead of clicking once. For business software where a failed login costs a support ticket and erodes trust, trading a click for reliability is an easy call.

The honest counterargument

OTP isn't free of trade-offs:

• It's slightly more friction on the happy path.
• Codes get phished too. If phishing is your threat model, passkeys (WebAuthn) are the real answer.
• Deliverability still matters. Both OTP and links live or die on your transactional email setup.

The point isn't that OTP is universally superior - it's that for an audience on corporate email, OTP's failure modes are milder and rarer.

If you must keep the link

Sometimes the link UX is a hard requirement. Two mitigations make it survive corporate mail:

1. POST-to-confirm. The link lands on a page with a single "Confirm login" button; the token is only consumed on that click. A scanner's GET never triggers it.
2. OTP as the fallback channel. Offer the link as primary, with a "didn't work? get a code instead" path on the check-your-email screen.

The takeaway

The advice "passwordless means magic links" quietly assumes consumer email. The moment your users are on managed corporate inboxes, that assumption breaks - because the thing that breaks it lives in their infrastructure, not yours.

Default to OTP for B2B. Keep social SSO as the frictionless primary path. Reach for passkeys if you're optimizing against phishing.

The broader lesson is the one that decides whether business software gets trusted or worked around: the defaults that look right in a demo often fail silently for real business users, and you only find out from the support queue. Getting the unglamorous details right - auth, deliverability, the edge cases a customer's IT department creates - is most of what separates software people rely on from software they route around. It's exactly the kind of thing we sweat when we build custom software at Bruvora.