Why we chose passwordless magic-link sign-in for Axos
When we sat down to design the sign-in flow for the Axos workspace, we already knew we did not want passwords. We nearly built one anyway, because that is the default and the default is comfortable. Then we counted, three times, the number of hours our previous team had spent over five years resetting forgotten passwords, chasing down leaked-credential alerts, and shipping the tenth revision of a password policy that nobody read. We decided we would rather spend those hours on the workspace itself.
The three objections
Every time we announce the passwordless design at a conference or in a customer call, the same three objections come up. Here is our short answer to each.
Objection 1 — "But I want a password"
You do not want a password. You want the certainty that only you can open your workspace. Passwords are a particularly poor mechanism for delivering that certainty: they are reused across services, they are typed into fake sign-in pages, they are written on sticky notes, they are cracked from leaked hashes with commodity GPU rigs. The magic link delivers the same certainty by proving control of the workspace email, which is the identity anchor you already trust to receive password-reset links on every other service.
Objection 2 — "What if my email account is compromised?"
Then every service you use is compromised, because that email address is the reset anchor for all of them. The magic-link design does not make this worse — it exposes it. If it worries you, protect the email account with a strong password, a hardware security key and 2FA, then apply the same 2FA on the Axos workspace itself. That is the layered defence that actually works.
Objection 3 — "What about offline sign-in?"
The workspace is a cloud workspace. Signing in offline is signing in to nothing. The magic-link flow requires exactly one round-trip to your email, which needs the same network the workspace itself needs. We do ship a service-worker cache for reading recent notes offline, but reading a cached note does not require signing in — the browser already holds the session cookie.
What magic-link buys us in exchange
The obvious win is that we never store a password. There is no password database to leak, no hash algorithm to worry about migrating in five years, no rate-limit strategy to design against credential stuffing. The less obvious win is that the sign-in page is trivial to reason about. It has one field and one button. When something goes wrong, the failure mode is either "the email did not arrive" or "the link expired", both of which are diagnosable in one glance. We do not spend engineering cycles on "the password contains an invisible zero-width space".
The third win, and the one we care most about, is that support tickets almost never contain the sentence "I forgot my password". The tickets we do get are qualitatively different — someone lost access to their workspace email, or their 2FA app was on a phone that fell into the Spree, or they need help configuring SSO for a fifteen-person consulting practice. Those are actual problems that deserve a human answer.
The security details
The magic link is a signed HTTPS URL, roughly 180 characters long, valid for 15 minutes, single-use. The token is signed with an Ed25519 key rotated every 30 days; older keys are retained for verification during a 24-hour transition window. On tap, the token is verified, the session cookie is issued, the token is marked consumed and cannot be replayed. Rate limiting is per email and per source IP, five requests per hour on each dimension. The whole flow is auditable from /session-and-devices.
If you want the deeper technical writeup, the security whitepaper has the full spec including the threat model and the two known limitations.