Passwordless looks finished in a staging environment. A magic link lands in Mailhog. A one-time code arrives in a test inbox. The happy path feels almost rude in how simple it is. Production is where the first three failure modes show up in the same afternoon, usually before the dashboard for the rollout has finished rendering.
I have helped ship passwordless as a primary login path for consumer products more than once. The pattern is consistent enough that I now schedule the first production week around the things that break, not around the demo. If you are planning a staged rollout, budget for these failures explicitly. They are not edge cases. They are the rollout.
Delivery is the real authentication surface
The first thing that breaks is not cryptography. It is delivery.
Magic links depend on email arriving quickly and looking trustworthy. One-time codes depend on SMS or email reaching the user before the code expires. Both channels have failure modes that your unit tests will never see. Corporate filters quarantine the message. Mobile carriers delay SMS under load. Users have three inboxes and check the wrong one. Apple Private Relay rewrites addresses in ways that confuse your "same email" identity join. A link that worked in staging for ten engineers will bounce, delay, or look like phishing for a slice of real users large enough to move your support queue.
When delivery fails, users do not wait politely. They click "resend" four times. If your system issues a fresh code each time and invalidates the previous one, the code that finally arrives is already dead, and the user is now locked in a loop of near-misses. Rate limits that felt responsible in design review become the mechanism that traps legitimate users. I prefer a short window where the latest code is valid and earlier codes in the same window are also accepted, with a hard cap on how many can be outstanding. Perfect security theater loses to a user who can finish login.
Link expiry is the cousin of this problem. Five minutes feels tight and secure. It is also shorter than the time many people take to find the message on a phone while walking between meetings. Fifteen minutes is usually fine for email magic links. SMS codes can stay shorter because the channel is faster when it works. Pick the number based on observed open times from your first canary cohort, not based on what sounded disciplined in a threat model meeting.
Device and browser assumptions fail next
The second cluster of breaks is about where the login finishes.
A magic link opened on a phone while the original request started on a laptop creates a split-session problem. Some products intentionally allow the link to complete login on whichever device opens it. Others require the original browser to finish. Both are valid. Mixing them without saying so is how you get "I clicked the link and nothing happened" tickets that take an engineer an hour to reproduce.
WebViews inside mobile apps are another regular offender. In-app browsers strip cookies, break redirects, or open the link in a context that cannot talk back to the app that started the flow. If a meaningful share of your traffic comes from Instagram, Gmail, or a partner app WebView, test those paths before the percentage rollout crosses five percent. The bug reports will otherwise arrive as vague "login broken on mobile" notes with no useful reproduction steps.
Deep links deserve the same attention. If your mobile app claims the magic-link domain, the OS may open the app instead of the browser session that started the login. That can be the correct product behavior. It can also strand a web-only user who never installed the app. Decide which surface owns completion, document it, and make the email copy match the decision. Mismatched copy is a support incident generator.
Account recovery and MFA collide with "no password"
The third break is organizational, not technical, and it arrives as soon as a real user loses access to the passwordless channel.
Passwordless does not remove account recovery. It moves it. If the user's email is compromised, the magic link is compromised. If the phone number is recycled, the SMS code belongs to someone else. Teams that remove passwords without rebuilding recovery end up with a support process that is slower and more manual than the password reset they were trying to escape.
MFA complicates this further. A product that required a password plus an authenticator app cannot simply swap the password for a magic link and keep the rest unchanged. The threat model shifted. Decide whether the magic link replaces the first factor, replaces both factors for low-risk sessions, or sits beside a second factor for sensitive actions. Write that decision down in language a support agent can use. Ambiguity here becomes inconsistent enforcement, and inconsistent enforcement becomes a security review finding later.
There is also the quiet cohort of users who cannot use the passwordless channel you chose. Shared family emails. Shared work phones. Regions where SMS delivery is unreliable. Accessibility contexts where opening a separate email client mid-flow is painful. A staged rollout should keep a password fallback for longer than engineering wants, with clear metrics for when that fallback can shrink. Cutting it early because the happy-path conversion looked good is how you strand the users who already trust you least.
How to stage the rollout without learning everything the hard way
Start with employees, then a small opt-in cohort, then a percentage of new signups before you touch existing login. Existing users have muscle memory and a lower tolerance for a login path that fails once. New signups will accept a different flow if it works the first time.
Instrument the boring counters from day one: messages sent, messages delivered if the provider gives you that signal, codes accepted, codes expired, resends per attempt, time from send to success, and support tickets tagged to passwordless. Watch resends and expiry together. A spike in both usually means delivery delay, not user confusion. A spike in resends with normal delivery usually means your UI is unclear about where to look.
Keep a kill switch that returns users to the previous login path without a deploy. I have used that switch twice on launches that looked fine in the first hour and then degraded when a regional email filter started quarantining the template. The rollback was dull, which is the highest compliment a rollback can get.
Passwordless can be a better login experience than passwords. It can also concentrate risk into delivery, device context, and recovery. Treat those three as the production surface area. The crypto will mostly behave. The inbox, the phone, and the support queue will tell you whether the rollout is actually ready.