From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
TL;DR: Time-based one-time password (TOTP) generators in apps like Google Authenticator, Microsoft Authenticator, and Authy were a meaningful upgrade over SMS OTP. They removed the telecom channel from the equation. They did not, however, change the underlying threat model. TOTP codes can still be phished in real time by adversary-in-the-middle kits, the seed can be exposed during enrollment, and the user is still the security control. Here is where authenticator apps stand in 2026 and why financial services authentication is moving past them.
TOTP was specified in RFC 6238 as an open standard built on top of HOTP (RFC 4226). The mechanics are simple. The server and the authenticator share a secret seed at enrollment. Both sides combine the seed with the current Unix time, hash the result, and produce a six-digit code. The code rotates every 30 seconds. The user reads it from the app and types it into the login flow. The server runs the same calculation and confirms the match.
For a long time, this was the practical bar for strong MFA. The seed never traveled over the telecom network. SIM swap fraud no longer affected the second factor. The codes could be generated offline. Authenticator apps were the recommended upgrade path for security-conscious users.
The structural improvement was real. The structural problem remained.
TOTP is not phishing resistant. The user reads a six-digit code from the authenticator app and types it into a login screen, and the user has no way to verify whether the login screen is real. NIST is explicit on this point: TOTP authenticators are not phishing resistant, even though they are stronger than SMS OTP.
The adversary-in-the-middle (AiTM) phishing kit defeats TOTP the same way it defeats SMS and email OTP. The attacker stands up a reverse proxy that mirrors the legitimate banking site. The user enters their password into the proxy, the proxy passes it to the real site, the real site requests the TOTP, the user opens their authenticator app and reads the current code, the user types the code into the proxy, and the proxy passes it to the real site within the 30-second window. The session cookie comes back to the proxy. The attacker steals it and replays it.
From the user's perspective, the authenticator app worked perfectly. From the bank's perspective, a valid TOTP was presented within the valid window. The attacker did not need to break the cryptography or compromise the seed. They just needed the user to type the code into the wrong domain, which the user does not have a reliable way to detect.
The second TOTP weakness is at enrollment. The shared seed has to get from the server to the authenticator app somehow, and the standard delivery method is a QR code displayed on the screen. If a user enrolls on a compromised device, on a screen-shared session, or in any context where the QR code is observed by a third party, the seed is now in the attacker's hands.
Once an attacker has the seed, they can generate the same TOTP codes the legitimate user generates, indefinitely. There is no rotation, no notification to the user, no signal to the bank that the seed is in two places at once. TOTP has no built-in concept of binding to a specific device, so the system cannot distinguish the real authenticator from a clone.
For consumer applications this risk is bounded by the rarity of QR code interception. For high-value financial services accounts, particularly business banking, it is a real attack surface.
The popular authenticator apps now support cloud sync as a default. Microsoft Authenticator backs up to the user's Microsoft account. Google Authenticator syncs across devices via Google account. Authy was built sync-first.
For users, sync is a usability win. Lose the phone, recover the seeds, no problem. For institutions trying to bind a credential to a specific device, sync removes the binding entirely. The seed now lives in the cloud account, which means the security of the TOTP credential is only as strong as the security of the cloud account it is synced through. If an attacker compromises the user's Google or Microsoft account, they compromise the authenticator and every account that depends on it.
The trade-off is real. The institutions that recommend authenticator apps as the strong factor are also recommending an architecture in which a single cloud account compromise can cascade across every relying party that trusted the synced TOTP.
The replacement is FIDO passkeys. The protocol does what TOTP cannot.
The credential is bound to the relying party's origin. The browser will not present a passkey for one banking domain to a lookalike domain. The user does not have to recognize the right URL because the protocol enforces it.
The private key never leaves the authenticator. There is no shared seed to be observed at enrollment, intercepted in transit, or extracted from a synced cloud backup.
The authentication ceremony requires a user gesture on the authenticator itself, which prevents silent server-side impersonation.
For financial services specifically, the device-bound passkey is the variant that matters. A device-bound passkey lives on a specific device and does not sync across the user's iCloud Keychain or Google Password Manager. The bank can be confident that the credential it is talking to today is the same credential it talked to yesterday. Synced passkeys are an improvement over TOTP, but they reintroduce the cloud-account-as-single-point-of-failure problem that synced authenticator apps already have.
Most financial institutions running TOTP today have it as the strong second factor for security-conscious customers, with SMS OTP for everyone else. The migration is not all-or-nothing.
Move high-value actions to phishing-resistant authentication first. Wire initiation, beneficiary additions, account recovery, and any change to registered contact details should require a passkey, not a TOTP code that can be phished in real time.
Keep TOTP available for users who prefer it during the transition, but deprecate it from the new-customer enrollment flow. New customers should be onboarded directly into passkey-based authentication.
Track the proportion of authenticated sessions still running on TOTP and set quarterly targets to bring it down. The metric matters because it gives the security team and the customer experience team a shared number to align on.
TOTP and authenticator apps were a meaningful improvement on what came before. They are also showing the structural limits of any authentication scheme that asks the user to be the security control. The institutions that move past TOTP earliest will be the ones with lower fraud loss, fewer support calls, and a cleaner regulatory story.
The code generator did its job. The next layer does not need it.
NIST SP 800-63B-4 Digital Identity Guidelines
IETF RFC 6238: TOTP Time-Based One-Time Password Algorithm
Sekoia.io: Global analysis of Adversary-in-the-Middle phishing threats
Microsoft Security: Defending against evolving identity attack techniques
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 →