Can FIDO2 Be Bypassed? How to Mitigate the Risk with Talisman

FIDO2 is one of the most significant advances in authentication security in a generation. It eliminates many of the attacks that defined a decade of banking fraud, particularly phishing and credential theft.

However, for CISOs and security leaders in banking, the critical question is not just how users log in, but how financial risk is controlled after authentication, for example when users make payments or approve transactions. Authentication is only one part of the threat model.

This article explains what FIDO2 genuinely solves, where its protection stops, and why hardware tokens like Talisman are designed to address the remaining gap. It also outlines how this model fits into real banking architectures, including integration, operational impact, and compliance requirements.

What FIDO2 Actually Solves

FIDO2 was built to eliminate attacks that had become routine: phishing for passwords, reusing stolen credentials across services, and intercepting one-time codes in real time. It works by removing shared secrets from the authentication flow entirely. Instead of transmitting something that can be stolen, the user's device performs a cryptographic operation using a private key that never leaves the authenticator. Each key pair is also bound to a specific domain, which means a convincing fake banking site cannot relay a valid authentication to the real one. There is no credential to intercept and nothing to replay.

The real-world results are well documented. After Google required all 85,000-plus employees to use hardware security keys in 2017, a company spokesperson confirmed that Google had no reported or confirmed account takeovers. In August 2022, a phishing campaign hit Cloudflare and dozens of other companies simultaneously. Some employees clicked the links. The attack still failed, because the hardware keys are bound to the correct origin and cannot be used on a spoofed domain, regardless of what the user does. CISA now identifies FIDO/WebAuthn as one of only two forms of multi-factor authentication it considers genuinely phishing-resistant.

For CISOs, this represents a material reduction in credential-based attack surface and a measurable improvement in identity assurance at login.

From an architectural perspective, FIDO2 introduces:

Public key cryptography with per-service key pairs
Origin binding enforced by the browser or platform
Authentication flows handled via WebAuthn APIs and CTAP protocols

In banking environments, FIDO2 typically integrates at the identity layer through:

IAM platforms or CIAM solutions
WebAuthn-compatible authentication servers
Mobile or browser-based authenticators, or external hardware tokens

This makes FIDO2 relatively straightforward to deploy for login use cases without major changes to transaction processing systems.

Where the Protection Stops

The boundary of what FIDO2 protects is specific, and it is worth being precise about where it sits. FIDO2 governs the authentication step. Once that step completes and a session is established, FIDO2 has no further role. As Yubico, one of the principal architects of the FIDO2 standard, states plainly in their own documentation:

"FIDO2 does not prevent: endpoint compromise (malware on the user's device), session hijacking after successful authentication, or social engineering for account recovery. FIDO2 ensures attackers can't get in by stealing credentials. However, if your computer is already compromised or someone steals your session after you've logged in, that's a different security problem requiring endpoint protection and session management controls."

^{- Yubico, FIDO2 Passwordless Authentication}^{documentation}

This is a precise and honest description of the standard's scope.

The problem it creates for banks is that the highest-risk actions, payment approvals, beneficiary changes, account modifications, all occur after login, inside the session that FIDO2 no longer covers.

From a technical standpoint, this limitation exists because:

Session tokens or cookies represent authenticated state after login
Backend systems trust the session rather than revalidating user intent per action
Malware or remote access tools can operate within a valid session context

Academic research has characterised the underlying issue directly: relying on session authentication only is fundamentally flawed in the presence of malware (including malicious web browser extensions), because taking control of the session lets an attacker interact with the service on behalf of a legitimately authenticated user without having broken the authentication itself.

For security leadership, this translates into a clear risk. Strong authentication does not equal transaction security.

Why Banking Needs More Than Login Security

Banks have been through versions of this transition before. When hardware tokens and one-time passwords became standard in the early 2000s, straightforward credential theft declined, and attackers shifted to session manipulation and social engineering instead. The pattern is consistent across every major change in authentication: what was previously the main attack surface gets hardened, and fraud moves to whatever is adjacent.

What makes banking different from most other digital services is that authentication carries legal and financial weight. A login on a content platform grants access. A login on an internet banking portal authorizes transactions with real consequences. The question is not only whether the right person authenticated, but whether they agreed to this specific action.

This distinction is not only technical. It is regulatory and financial.

This is what PSD2 formalized with dynamic linking. The EBA Regulatory Technical Standards require that the authentication code be cryptographically tied to the specific amount and payee of a transaction, not to identity in general. The relevant provision states that the authentication code shall be specific to the amount of the transaction and the payee agreed to by the payer when initiating the transaction. PSD3/PSR extend this requirement further.

From an implementation perspective, dynamic linking requires:

Transaction data to be included in the authentication challenge
Cryptographic binding between the challenge and the approval
A trusted display channel that cannot be altered by the endpoint

For CISOs, this is critical:

It defines what strong customer authentication actually means in practice
It directly impacts fraud liability and compliance posture
It determines whether authentication investments translate into reduced financial risk

Without transaction-level binding, even the strongest authentication leaves the authorization step exposed.

How Talisman Addresses This

Wultra's Talisman is a hardware FIDO2 token built for banking environments. It combines standard FIDO2 and WebAuthn authentication with a two-line display that shows transaction details directly on the device before the user confirms them. The user sees the amount and recipient on the hardware, not on the browser screen that malware can alter. This is the principle the industry refers to as WYSIWYS: What You See Is What You Sign.

From a CISO perspective, this reduces dependency on endpoint trust and introduces a controlled, verifiable channel for transaction approval.

From a technical architecture perspective, Talisman extends the standard FIDO2 flow with transaction signing:

The bank backend generates a challenge and includes transaction details to be authorized
The challenge is sent to the client application via the WebAuthn flow
The hardware token receives the data and displays the transaction details on its screen
The user verifies and confirms using a PIN
The token signs cryptographic data that is bound to both the authentication request and the transaction details
The backend verifies the signature, ensuring both user authentication and transaction integrity

Because Talisman is a separate physical device connected by USB, transaction verification is independent of whatever state the user's computer is in. A compromised endpoint cannot change what appears on the token's display. Combined with a PIN requirement for every operation, this satisfies the dynamic linking requirements of PSD2 and PSD3/PSR in a way that software authenticators running on the same device as the browser cannot.

Talisman also stores up to nine separate service credentials on a single device, requires no software installation, and runs all cryptographic operations on a dedicated secure element.

From an integration and operations standpoint:

It works with standard WebAuthn flows, minimizing changes to IAM infrastructure
Transaction data formatting must be standardized for display on the device
No mobile dependency reduces support complexity in regulated or restricted environments
Lifecycle management includes device provisioning, PIN management, and revocation

For banks, this translates into:

Reduced fraud exposure from session-level attacks
Regulatory alignment with PSD2 and PSD3/PSR dynamic linking
A viable strong authentication method for users without smartphones
Lower operational dependency on mobile ecosystems

Where FIDO2 Fits in Banking Security

FIDO2 represents a genuine step forward in authentication security. The attacks it eliminates were responsible for a substantial share of account fraud for years, and its adoption across browsers, operating systems, and major services has made those attacks structurally harder to execute at scale.

The limitation is not that FIDO2 is weak. It is that authentication and authorization are two different problems, and solving one does not automatically solve the other.

For CISOs and security leaders, the implication is straightforward:

FIDO2 should be treated as a baseline for secure authentication
Transaction-level controls must be layered on top to ensure integrity of high-risk actions

In practical terms, a complete banking security model includes:

Phishing-resistant authentication such as FIDO2
Session monitoring and anomaly detection
Transaction signing with dynamic linking
Independent verification channels for high-risk operations

In banking, where every transaction carries financial and regulatory risk, security must ensure not just who logs in, but what they approve.

Frequently asked questions

Can FIDO2 be bypassed?

Not at the credential level. FIDO2 prevents phishing, credential replay, and man-in-the-middle attacks during login. Attackers can, however, target authenticated sessions through malware on the endpoint or remote access tools operating after login. Yubico explicitly notes that endpoint compromise and session hijacking fall outside FIDO2’s scope.

What is dynamic linking in banking authentication?

Under the EBA Regulatory Technical Standards for PSD2, the authentication code for a payment must be tied to the specific transaction amount and payee. This ensures that a valid approval cannot be reused or redirected to a different transaction.

What attacks does FIDO2 not protect against?

FIDO2 does not protect against session hijacking after login, malware manipulating an active session, or social engineering attacks conducted within a legitimate session. These require controls at the authorization layer, not just authentication.