From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
TL;DR: Magic links, the passwordless authentication pattern that emails a one-click sign-in URL to the user, solved a real friction problem for consumer apps. They have not held up well as authentication for financial services. The security of a magic link is bounded by the security of the user's email account, the link itself can be phished, and the model has no concept of binding the credential to a specific device. Here is where magic links work, where they don't, and what financial institutions are using instead.
Magic link authentication appeared in the mid-2010s as a passwordless pattern for consumer SaaS. The user types in their email, the service emails a sign-in URL, the user clicks it, and they are signed in. No password to remember, no MFA prompt, no friction beyond reading email.
The user experience win was real. Account creation simplified to typing an email. Account recovery was implicit: if you have access to the email, you have access to the account. Slack, Notion, Substack, and a long list of consumer-facing services adopted the pattern.
For services where the value at stake per session is bounded, magic links are a reasonable trade-off. For financial services, the trade-off has not aged well.
The fundamental issue with magic links is that the security of the credential is the security of the email account. When the bank emails a sign-in link, the link is a valid credential for whoever reads the email. If the user's inbox is compromised through credential stuffing, phishing, or a leaked password from another service, the attacker has access to every magic link the user is sent, indefinitely.
Cloud-based email accounts are routinely compromised. Credential stuffing against Gmail, Outlook, and Yahoo has been a continuous attack surface for years. Phishing kits target email credentials directly because the access is so leveraged. NIST SP 800-63B-4 treats email-based out-of-band authentication with the same skepticism it applies to SMS OTP for a similar reason: the channel cannot be assumed to be secure.
For a banking application, that boundary is below the threshold most regulators are comfortable with. The factor of possession is supposed to mean the user holds something the attacker does not. If both can read the inbox, the factor has collapsed.
The second issue is the phishability of the link itself. A magic link is, by design, a URL that grants access. An attacker running an adversary-in-the-middle phishing kit can prompt the user to enter their email on a lookalike banking site, the proxy passes the email to the real site, the real site sends a magic link to the user, and the proxy invites the user to click the link in a way that routes the resulting session through the attacker's infrastructure.
Even simpler: the attacker who has read access to the inbox can click the link before the legitimate user does. Magic links typically have a short expiration window, but the window is long enough for a real-time attack. The user requests a login, the attacker's inbox monitoring tool sees the email, the attacker clicks the link in milliseconds, the session is theirs.
None of this requires breaking cryptography. It requires controlling the inbox, which is a far lower bar than breaking the authentication protocol.
Even setting aside the email account boundary, magic links lack three properties that financial services authentication needs.
They are not phishing resistant by protocol. The user has to recognize a legitimate banking domain when they click the link, and recognition is unreliable at scale.
They are not bound to a device. A magic link sent to an email account can be opened on any device that has access to the inbox. The bank cannot authenticate against the same device every time because the model does not have a concept of the same device.
They produce no attestation. There is no cryptographic signature from a hardware authenticator that the bank can verify. The audit trail is a record that an email link was clicked, not a record that a specific device with known security properties signed an authentication request.
The replacement is the passkey, and for high-assurance flows, the device-bound passkey specifically.
Passkeys solve the phishing problem at the protocol level. The credential is bound to the relying party's origin. A passkey for one banking domain will not authenticate to a lookalike domain. The user does not need to recognize the URL because the protocol enforces it.
Passkeys solve the device binding problem. The credential is generated and stored in the device's secure enclave, not delivered through a third-party channel like email. The bank can be confident, on every authentication, that the device on the other end is one that has been enrolled.
For financial services specifically, the device-bound variant of passkeys carries an additional property. The credential does not sync across the user's iCloud Keychain or Google Password Manager, which means the security boundary is the device, not the cloud account. For high-value actions like wire transfers and beneficiary changes, that matters.
The pattern still has a place. For low-value, low-friction authentication where the user's email account is essentially the account of record, magic links are reasonable. Newsletter sign-ups, low-stakes content services, and enterprise SaaS where the IT team also controls the email account all fit the pattern.
Financial services does not fit the pattern. The asymmetry between possession of an email and possession of an account is too large. The institutions still using magic links as the primary authentication factor are running an architecture that does not match the regulatory or threat-model expectations of 2026.
For institutions running magic links today, the path is similar to the OTP migration path, just compressed.
Move high-value actions to phishing-resistant authentication first. Wire initiation, beneficiary additions, account recovery, and contact updates should require a passkey, not a magic link.
Replace the magic link as a primary login factor. New customers should be onboarded into passkey-based authentication. Existing customers who rely on the magic link should be migrated through a one-time enrollment flow that issues a device-bound passkey.
Keep the email channel for what email is good for: notification, confirmation, and audit trail. Email is a useful side channel. It is not a strong authentication factor.
Magic links were a reasonable answer for a kind of authentication problem that financial services does not actually have. Banks have sophisticated identity verification at onboarding, regulatory obligations to know the customer, and the resources to deploy stronger credentials than a clickable email URL. The institutions that move past magic links earliest will be the ones with the cleaner authentication architecture and the cleaner regulatory story.
The magic was always in the user experience, not the security model. The next generation of authentication keeps the user experience and fixes the security model.
NIST SP 800-63B-4 Digital Identity Guidelines
Sekoia.io: Global analysis of Adversary-in-the-Middle phishing threats
Most orgs running OTP-based MFA have 3–4 exploitable gaps they don’t know about. Our Authentication Assessment takes 2 minutes and shows you exactly where you stand — plus a phased migration roadmap.
Take the Assessment →Built by Ideem
Device-bound passkeys and A2A payment authentication. One SDK. No OTPs, no redirects.
Our 2-minute assessment scores your authentication setup and shows you exactly where the improvements are.
See Your Score →