Passkeys can remove phishable shared secrets from the front door. The durable security gain comes when recovery, privileged access, transaction risk, and mobile-app integrity evolve with them.
Executive briefing
Latin America no longer needs to treat passkeys as an experimental sign-in feature. A 2026 FIDO Alliance case study of Banesco Banco Universal reports a deployment serving 2.2 million users across mobile and web banking. The bank says passkeys now protect high-value transfers, fast person-to-person payments, and fraud-alert resolution.
That is meaningful regional evidence, but it should not lead executives to compress identity strategy into a single migration slogan. Passwordless authentication solves a specific class of problems: stolen, reused, relayed, and socially engineered shared secrets. It does not by itself secure account recovery, privileged administrators, compromised mobile runtimes, transaction authorization, or an AI agent acting on a customer’s behalf.
The strategic task is therefore larger than replacing a password field. Organizations need an identity control plane that makes passkeys the default front door while applying stronger authenticators, recovery evidence, device and app signals, and transaction-level controls where consequences rise.
Regional scale is now visible
Banesco’s published implementation is notable for both scale and sequencing. According to the FIDO case study, the Venezuelan bank moved through technical evaluation, a low-risk pilot, and mass deployment over seven months. It then connected passkey verification to high-value transactions and to events raised by its fraud-monitoring systems.
The reported results are substantial:
- 2.2 million regular passkey users, about 92% of the bank’s active users;
- 12 million passwordless transactions during the reported year;
- 8.3 million high-value transactions using passkeys; and
- a 65% decline in identity-theft-related fraud reports.
Those are bank-reported outcomes presented through an industry alliance, not an independently audited regional benchmark. Even with that caveat, the case demonstrates that passkeys can operate at consumer-banking scale in Latin America and can be attached to business events rather than limited to login.
The reusable lesson is the deployment shape. Banesco validated compatibility, piloted lower-risk flows, measured adoption, and expanded into high-friction moments where stronger authentication could also reduce support work.
What passkeys actually fix
Traditional passwords and one-time codes ask the user to recognize whether a prompt is legitimate. Attackers exploit that burden through lookalike sites, social engineering, vishing, and real-time relay.
NIST Special Publication 800-63B defines phishing resistance as preventing authentication secrets or valid outputs from being disclosed to an impostor verifier without depending on user vigilance. It explicitly says manually entered OTP and out-of-band codes are not phishing-resistant because an attacker can relay them.
Passkeys change that model. They use public-key cryptography and bind authentication to the relying party. The server stores a public key rather than a reusable shared secret, while the user proves control of the corresponding private key through a device, credential manager, or hardware authenticator.
That removes password reuse, credential stuffing, phishing pages collecting reusable credentials, and real-time OTP relay. When implemented well, stronger authentication no longer has to mean more codes, typing, and support calls.
The five-layer control plane
1. Make passkeys the broad default
For consumers and most workforce users, synced passkeys provide the best route to large-scale adoption. They travel through supported credential providers, survive ordinary device replacement, and use local biometrics or a PIN to activate the credential without sending biometric data to the relying party.
The first deployment target should combine fraud exposure and user friction: login, account unlock, high-value payment confirmation, or fraud-alert resolution. Measure enrollment, successful use, fallback, support, and fraud outcomes before expanding.
Do not preserve password and SMS fallbacks indefinitely without monitoring them. If the weakest path remains universally available, attackers will steer users toward it.
2. Separate ordinary and high-consequence authenticators
Not every passkey has the same lifecycle property. Synced credentials can move through a provider fabric; device-bound keys are designed not to leave their protected boundary.
NIST’s assurance levels are a useful design lens beyond federal systems. Its current guidance requires a phishing-resistant option at AAL2; AAL3 requires a phishing-resistant authenticator with a non-exportable key, excluding synced authenticators.
The practical implication is not that every customer needs a hardware token. It is that privileged administrators, payment approvers, recovery operators, cryptographic custodians, and other high-consequence roles deserve a different authenticator policy from ordinary users.
A mature program should define who may use synced credentials, which roles require device-bound protection, how backup and revocation work, and when a high-risk action requires step-up authentication.
3. Treat recovery as an authentication system
Account recovery can reintroduce every weakness removed from login. Attackers will target a phishable email, SMS, or help-desk recovery path instead.
The FIDO Alliance’s synced-passkey deployment guidance warns that recovery becomes a weak point when it lacks solid identity proofing. For consequential services, it points to stronger processes such as electronic know-your-customer checks.
Recovery design should cover lost devices, contact-channel changes, compromised sessions, and support-agent abuse. Use delayed sensitive changes, independent notification, prior-authenticator revocation, auditable operator actions, and stronger evidence when both device and contact channel change.
Recovery success rate is not enough. Measure fraudulent recovery attempts, reversals, support overrides, time to revoke a compromised credential, and the percentage of accounts that still depend on phishable fallback.
4. Bind authentication to transaction risk
A successful sign-in does not prove that every later action is intended. High-value transfers, new payees, privilege changes, security-setting changes, and agent-initiated purchases need their own authorization logic.
Banesco’s public case is useful here because passkeys are reportedly invoked when fraud monitoring flags a transaction. That connects authentication with context instead of treating it as a one-time gate at session creation.
Risk-based authorization can consider transaction value, beneficiary novelty, device history, session age, location changes, impossible travel, behavioral anomalies, and app integrity. The response should be proportional: allow, challenge, delay, require an additional approver, or route to investigation.
The challenge must also describe the action clearly. A cryptographically strong ceremony can still authorize the wrong thing if the user sees only a generic “confirm” prompt.
5. Protect the mobile runtime and keep authority server-side
For many Latin American financial and commerce services, the mobile app is the primary branch. Passkeys strengthen the identity ceremony, but the app around that ceremony can still be instrumented, modified, hooked, or run in a hostile environment.
OWASP MASVS-RESILIENCE describes anti-tampering, anti-debugging, code obfuscation, and runtime application self-protection as defense-in-depth measures for threat-specific client-side attacks. It also makes the boundary explicit: these controls do not replace sound architecture, strong cryptography, or server-side validation.
Runtime controls can raise attacker cost and produce risk signals, but they can be bypassed, hurt performance, and create false positives. Treat app integrity as a policy input, not proof of safety.
Critical authorization, limits, fraud decisions, and audit evidence must remain enforceable on systems the attacker does not control.
Agentic commerce raises the stakes
Software agents are beginning to search, decide, and pay. Visa’s 2026 Agentic Ready expansion says more than 85 partners across Asia Pacific and Latin America will test enrollment, tokenization, authentication, authorization, and agent-payment controls.
An agent changes the meaning of authentication. The human may authenticate to delegate authority, while the agent later acts under constrained permissions. Organizations must record who enrolled it, what it may buy or approve, applicable merchant and amount limits, when human step-up is required, and how authority is revoked.
Passkeys can strongly authenticate the human at delegation and step-up moments. They do not define the agent’s authorization envelope. That belongs to the control plane.
A practical deployment scorecard
Executives should expect one view across security, customer experience, and operations:
- passkey enrollment, active use, and completion by platform;
- password, OTP, recovery, and help-desk fallback frequency;
- fraud, identity-theft, account-takeover, and lockout outcomes;
- privileged-role coverage and transaction-bound step-up; and
- mobile-integrity false positives and time to revoke credentials, sessions, devices, and agents.
Segment the scorecard: high adoption can still hide weak administrator recovery, legacy-device gaps, or mobile-integrity rules blocking legitimate users.
What to watch next
- Latin American banks publishing more deployment metrics beyond enrollment, including fraud, recovery, and support outcomes.
- Hardware-protected credentials becoming standard for privileged and high-value business workflows.
- Account recovery moving from contact-channel possession toward stronger identity evidence.
- Transaction prompts becoming more explicit about the action being authorized.
- Mobile-app integrity signals feeding risk engines without becoming opaque denial mechanisms.
- Agentic-payment programs defining revocation, spending boundaries, and human step-up semantics.
Passkeys are a material security improvement and the region now has evidence that they can scale. The organizations that capture the full benefit will be those that resist treating passwordless as a finished product. The front door is changing; recovery, privilege, applications, transactions, and delegated authority must change with it.
Sources
- FIDO Alliance: Banesco Banco Universal — Scaling Phishing-Resistant Authentication to 2.2 Million Users
- NIST Special Publication 800-63B: Authentication and Authenticator Management
- FIDO Alliance: Replacing Password-Only Authentication with Passkeys in the Enterprise
- FIDO Alliance: Synced Passkey Deployment — Emerging Practices for Consumer Use Cases
- OWASP Mobile Application Security: MASVS-RESILIENCE
- Visa: Global Expansion of the Agentic Ready Program
