Back at FIDO Authenticate 2026: From passkey deployment to everyday banking

Last year, I attended my first full Authenticate conference, presented by the FIDO Alliance, and wrote about the gap between understanding passkeys and deploying them at scale. Enrollment timing, platform differences, and recovery were among the lessons that stayed with me.

Returning to Carlsbad for Authenticate 2026, I had those questions in mind—and a session of my own to present.

What stood out this year was how often discussions moved beyond the login experience itself. Passkey deployments, recovery strategies, digital credentials, transaction approval, and even agentic commerce all pointed toward a broader shift: authentication is becoming less about a single login event and more about establishing identity, intent, and authorization throughout the customer journey.

That theme resonated with my own session, “Banking Security Customers Love: From Login to Payment.” Rather than focusing on a single authentication event, I used a familiar banking journey to explore the moments where trust decisions occur, from account access to high-value transaction approval.

My current focus is helping drive passkey adoption in banking. That gave me a practical lens for the conference: what can banks learn from organizations already deploying passkeys? How can they improve the experience around authentication? And what emerging technologies and implementation approaches should they be evaluating next?

Here are the lessons I’m taking into my work on passkey adoption in banking.

Making passkeys available is only the start

The deployment stories I heard at the conference made it clear that the decisions surrounding an implementation have a significant influence on whether people use it. Banks need an adoption strategy to complement the new technology.

Spotify described a gradual approach, with passkeys coexisting with other methods. eBay discussed a staged rollout supported by communication, governance and planning for different users and devices.

Both approaches have their merits. For me, however, the examples were useful because they elevated the questions that banks must answer when integrating passkeys into their authentication strategy:

• When does someone encounter the option to create a passkey?  
• Do they understand the prompt?  
• Can they use it again easily?  
• What happens when they change devices?

In banking, those questions become more complex, because they must account for a diverse customer base. Someone might enroll on a phone and later access their account from a laptop. Another customer might replace a device or need an alternative way to authenticate.

This elevates another important question: synced or device-bound passkeys. The choice needs to reflect the use case, assurance requirements, and device environment. Understanding their different properties helps teams make informed decisions about the experience they want to deliver.

Start with a defined customer use case and measure what happens. Enrollment numbers are useful, but repeat usage, successful sign-ins, abandonment, and support requests reveal more about whether the experience is working.

Try passkeys free with DigipassONE™ Authenticate

Evaluate passkeys designed for financial institutions with bank-grade security, superior customer experiences, enterprise readiness, and proven expertise.

Start your free trial

Recovery needs to be part of the original plan

Recovery featured in my reflections last year, and it remains one of the first things I would examine in an authentication plan.

From the outset, recovery must be part of the adoption discussion. Customers are more likely to embrace passkeys when they trust they can regain access if a device is lost, replaced, or unavailable. Likewise, support teams need a clear, consistent process for helping customers do that securely. The practical questions are straightforward, even when the answers take work. If a customer’s usual authenticator is unavailable, how do they regain access? What evidence establishes that they are the account holder? How do they register a replacement?

These decisions often involve authentication, fraud, application development, and customer service teams. Their responsibilities need to connect, because the customer experiences the result as one interaction with their bank.

Bringing the discussion from login to payment

Preparing my session meant deciding what I wanted people to remember after a short demonstration.

Authenticating a customer and confirming their approval of a specific action are connected but distinct decisions.

That idea shaped my demonstration. A successful login provides an important foundation, but it does not answer every security question that follows. I chose the progression from login to step-up to payment approval because it makes the broader role of authentication concrete. Not every action carries the same level of risk. Viewing a balance, changing account information, and approving a payment require different considerations and levels of confidence.

Risk information can help inform whether further verification is appropriate. Equally important, the customer needs to understand what they are being asked to approve, particularly when money is moving. When additional checks are required, they should be relevant, understandable, and directly relate to the action the customer initiated.

For me, that was one of the recurring themes at Authenticate 2026. Establishing identity is still essential, but increasing attention is being paid to intent, context, and authorization.

Digital credentials: Where would they help?

Digital credentials were already on my radar after last year’s conference. This year’s discussions encouraged attendees to consider their role in identity verification, recovery, and payments.

For example, Mastercard’s session explored digital payment credentials and how they complement payment passkeys in wallet-based experiences.

For banks, the more important question is where a credential can be trusted. Could a credential help establish identity during recovery? Could it reduce repeated information collection during onboarding or servicing? What would a bank need to know before accepting it?

The answer depends on context. The issuer, the information being asserted, its validity, and the assurance it provides all matter. So does the purpose for which it is being presented.

That makes acceptance an important part of the discussion. Issuing a credential is one step. Making it useful across services requires interoperability, clear operating responsibilities, and customer interactions that make sense.

I see meaningful opportunities to evaluate here. The key is distinguishing between  capabilities available today, pilots, and work that still depends on developing standards.

Agents put the boundaries of permission in focus

The discussions around AI agents connected with a familiar concern in banking: establishing what someone has authorized.

Sessions explored delegated authority, customer intent and evidence of approval, including developing approaches to agentic commerce.

Through a banking lens, the questions become specific. Who granted permission? Which action did they approve? What amount, recipient or time limit applies? How can that permission be withdrawn?

When software acts for a customer, those limits need to be explicit enough for systems to enforce. Approval may also happen before the final action, making the connection between permission and execution particularly important.

That is where I see a link to transaction security. Establishing what the customer approved and preserving evidence of that approval are familiar requirements. Agents introduce additional actors and complexity.

It is an area I want to follow closely, while remaining precise about what is deployed, what has been demonstrated and what remains unresolved.

My takeaways from Authenticate 2026

Three things stayed with me this year:

1. Adoption is an ongoing commitment. The deployment stories reinforced the importance of enrollment, recovery, communication and support. Making passkeys available is a milestone; making them a dependable part of everyday use takes continued work. 
    
2. The connection between identity and approval matters. From my banking demonstration to the discussions about agents, a common question emerged: how do we establish what someone actually authorized? It’s a practical link between authentication, transaction security and delegated authority. 
    
3. Digital credentials are worth evaluating against specific needs. Recovery, identity verification and payments offer concrete places to explore their value. Understanding what is ready, what is being tested and what still needs work will help organizations make informed decisions.

My focus now is helping banks turn interest in passkeys into adoption. The deployment lessons, recovery discussions and emerging credential use cases at Authenticate all inform that work. My “From Login to Payment” session illustrated how those decisions connect across a banking experience.  

I left Carlsbad with a clear priority: help banks take a practical next step, then build on it until passkeys become an everyday part of how their customers bank.