Passkeys can make customer logins faster and harder to compromise, but they do not eliminate the need for well-designed account recovery. This article explains when the investment makes sense and what your web agency must be able to answer before launch.
A customer who sees the “Sign in with a passkey” button on their phone may gain access with a single touch, yet still get stuck when opening the same account on a shared computer or after changing phones. The value of passkeys therefore depends not only on how seamless the first login feels, but also on what happens when the device is unavailable, the process is interrupted or the account must be recovered. A poorly planned implementation can shift the cost from forgotten passwords to more support requests and abandoned purchases. This article helps owners of small and medium-sized e-commerce businesses and customer portals assess when the technology is worthwhile and how to introduce it without locking customers out.
Passkeys only pay off when password friction is a genuine business problem
Imagine two hypothetical businesses. The first runs a store where most visitors check out as guests and rarely return to an account. The second has a customer portal where users regularly download documents, track cases and update their details. Both can technically offer passkeys, but the second business has considerably more occasions when a fast, secure customer login can affect self-service, loyalty and the burden on support.
The first thing we examine is therefore not whether the identity platform has a button for enabling passkeys. We begin with the existing friction. Do forgotten passwords prevent customers from completing purchases? Are portal visits abandoned when a password needs to be reset? Does the support team repeatedly spend time identifying customers and helping them regain access to their accounts? If the answers are unclear, the business must first establish an understandable baseline. Otherwise, passkeys risk becoming a technology investment without a clearly defined business problem.
The value of the account to an attacker also matters greatly. An account containing saved addresses, order history, reward balances or sensitive portal information is more attractive to hijack than one containing almost no persistent information. For these accounts, passkeys can reduce both password problems and the risk of phishing. However, the technology does not automatically protect a compromised email inbox, a stolen authenticated session or a poorly staffed recovery process. Security must be assessed as a chain, not as a feature of a single login button.
Technically, passkeys are based on WebAuthn, the browser interface for authentication using cryptographic keys. When a customer registers a passkey, a key pair is created for that particular service. The website stores the public key, while the private key is managed by the customer’s device, security key or compatible password manager. During login, the server sends a challenge that is signed with the private key. The website therefore never receives a reusable password that the customer might later enter on a phishing site. A technical introduction to the model is available in MDN’s overview of the Web Authentication API.
The business interpretation is straightforward: customers do not need to remember or type a password, and attackers find it harder to trick them into providing the same credential on another domain. The database still contains information that must be protected, but the public key cannot be used like a password to log in. Passkeys therefore make passwordless login practical for many web journeys without requiring the website to receive the customer’s fingerprint or facial data.
The benefits are less obvious when customers log in infrequently. A passkey created a long time ago may have been forgotten, may belong to another account ecosystem or may have disappeared with an old device. In those situations, an email link or a well-designed traditional login can still feel easier. For an e-commerce business with a high proportion of guest purchases, improving checkout, clarifying account creation and reducing mandatory fields may therefore have a greater impact than immediately rebuilding authentication.
Here is how we would set the initial priority: the more frequently customers return, the more valuable the account and the more clearly password problems affect purchases or self-service, the stronger the case for a pilot. If only one of these conditions applies, an optional addition is often more appropriate than a new default requirement. If there is neither recurring use nor documented password friction, the business can afford to wait without feeling technologically behind.
A cautious introduction usually begins after the customer has already verified their identity, for example on the account page following a successful password login or when an account is confirmed. The customer can then be offered the option of creating a passkey for their next visit. This reduces the risk of presenting a new user with two unfamiliar tasks at once: understanding the service and understanding a new authentication method. The password or another established method remains available as a fallback during the pilot.
Finally, browser support for WebAuthn is not the same as a coherent end-to-end journey. Registration and login may be presented differently depending on the operating system, browser, password manager and whether the page appears in an embedded web view within an app. A pilot must therefore reflect the environments customers actually use. Otherwise, it may look stable on the development team’s computers while creating friction for the mobile customers who account for the most commercially important traffic.
Fallback login must not become the easiest way around passkey protection
Imagine that a customer has protected their account with a passkey, changes phones and selects “I can’t access my passkey.” If the next step is merely a link sent to an email address, the account’s actual security has shifted back to the email account. An attacker does not need to attack the passkey at all; they only need to choose the weakest alternative route.
This pitfall arises when fallback login is treated as a usability detail that can be added later. In reality, it is part of the security model. A password that still works, an email link and a one-time code can all be reasonable fallback methods in the right context, but each creates a dependency. A password can be phished, an email link depends on the security of the email account, and a code sent through the same channel provides no independent verification.
Fallback login and account recovery should also mean different things. A fallback login can give the customer temporary access using a previously registered method. Account recovery, by contrast, changes which credentials are allowed to control the account, for example by adding a new passkey and removing an old one. The latter should be treated as a security-critical account change because it can provide long-term access even after the recovery event itself has ended.
For an account requiring a moderate level of protection, an existing password combined with an already established additional check may be a proportionate fallback during a pilot. The assessment needs to be stricter for accounts where a takeover could provide access to payment details, sensitive documents or valuable orders. The goal is not to make recovery painful, but to avoid a situation in which security looks strong in the main journey while actually depending on personal information that is easy to find or guess.
One practical way to reduce the need for recovery is to let customers register more than one passkey. This might mean one passkey on a phone and another on a computer, a combination of synced and device-bound keys, or a passkey managed in a compatible password manager. Multiple registered routes reduce dependence on a single device, but they must be manageable. Customers should be able to see meaningful names, when each passkey was created and which device or environment last used it, enabling them to revoke the correct credential.
Naming matters more in practice than it may initially appear. Entries called only “Passkey 1” and “Passkey 2” do not help customers determine which one belongs to an old work phone. A suggested name such as “My iPhone” or “Password manager on my home computer” can be a starting point, but the user should be able to change it. Device information must also be worded carefully because the website cannot always know exactly where a synced passkey is stored.
Recovery codes can provide an additional fallback for some services, but only if they are treated as valuable credentials. They should be displayed when created, be suitable for storage away from the device the customer normally uses and be consumed when used. When new codes are generated, the old ones must stop working. The codes themselves do not belong in analytics tools, support notes or email messages that make them easier to copy.
Support is often the most difficult part to design. A stressed customer wants help quickly, while an attacker may use the same urgency to pressure staff into making an exception. Support staff should therefore follow a documented process and must not be able to change the account owner or add a new authentication method solely by checking a name, address, order details or other information that may be readily available. Accounts requiring greater protection may need several previously established signals, and unusual cases should be escalated without improvised shortcuts.
When recovery is completed, the customer should receive clear notifications through contact channels that were already registered before the change. The message needs to explain what changed and what the customer should do if the recovery was unexpected. Depending on the service’s risk profile, old passkeys, recovery codes and sensitive sessions may need to be reviewed or revoked. This creates an opportunity to detect an account takeover rather than allowing the attacker’s new passkey to become permanently invisible.
A shared computer illustrates why the fallback route must also be easy to understand. The customer may not want or be able to create a passkey locally, but may be able to use their phone to approve a login through a QR-based flow. If that fails, the customer needs to be able to choose another method without believing the account has been lost. At the same time, the interface must not promote the weakest method so aggressively that everyone chooses it out of habit. The balance lies in making the most secure route easy and the fallback route visible, while applying controls proportionate to the consequences of an account takeover.
The interface must work even when customers do not know what a passkey is
A technically accurate button can still create a usability problem. Imagine a returning customer who understands the words “fingerprint” and “screen lock” but has never heard of WebAuthn. If the page merely says “Use a passkey,” the customer is forced to make a security decision based on an unfamiliar product term. Many will choose the familiar password instead or abandon the process.
The button can still say “Sign in with a passkey,” but it should be accompanied by a short explanation, such as: “Use your device’s screen lock, fingerprint or facial recognition.” Nearby help text can clarify that biometric information is not sent to the website. The fingerprint or face is used locally by the device to unlock the private key; the service receives the cryptographic response, not the biometric information.
The wording also needs to work across different platforms. If the website promises “Sign in with Face ID,” the text is wrong for customers using Android, Windows Hello, a PIN or a physical security key. The platform’s own dialogue will also use language and a visual style that the website cannot fully control. The website’s role is therefore to prepare customers for what will happen and explain how to continue if the dialogue does not match their expectations.
Conditional mediation can make the introduction more seamless. It allows the browser to suggest an available passkey in the usual username field, much like other autofill suggestions, without requiring the customer to choose a separate technical route first. Where supported, it can reduce the number of decisions on the login page. A clear passkey button and a visible link to other methods are still needed because not every environment displays the same suggestions and the customer may be using a new or shared device.
The interface must not promise that a passkey will automatically be available everywhere. Some passkeys are synced between devices within an account or compatible password manager, while others are tied to a particular device or physical security key. A customer moving from one ecosystem to another may therefore not have the passkey that worked on the old phone. It is better to say “Use a passkey available on this or another device” than to promise it will always be available on the next computer.
Error messages need to distinguish between situations that require different customer actions. If the user closes the platform dialogue themselves, a neutral message is appropriate: “Login was cancelled. Try again when you’re ready.” If no passkey is available, the page should instead offer another device or fallback method. If a QR flow was started but could not be completed, the customer needs to know that the connection between the devices failed rather than simply seeing “Something went wrong.”
Browser error codes can sometimes be ambiguous, so the implementation cannot always diagnose every cause perfectly. However, the application can know which step was displayed, whether the customer actively chose to cancel and whether a flow from another device had started. This context is often enough to provide more useful instructions than a generic error. The same categories should then be used in measurement so the product team can distinguish user abandonment from technical integration problems.
Passkey registration works best in a context where the customer has already confirmed their identity. On the account page, the service can explain the benefits, launch the platform dialogue and then ask the customer to name the key. If registration is cancelled, the account should continue to work as before. This principle makes the pilot reversible and reduces the risk that an incomplete registration leaves the customer believing their password has already been removed.
Account management must be as carefully designed as the login itself. Customers should be able to add more passkeys, recognise and revoke an old key, and understand which fallback methods remain active. These actions need to work with a keyboard, clear focus indicators and assistive technologies, not only through small icons or gestures. This is practical quality: customers who cannot manage their own credentials will otherwise become dependent on support.
Do not overlook embedded web views either. A link from a newsletter, payment app or social platform may open the store in a restricted internal browser where the passkey flow behaves differently from Safari, Chrome or Edge. If the service detects that the environment cannot handle the flow well, it can provide a clear route to the system’s standard browser. To the customer, this is not a WebAuthn problem; it is the difference between accessing their order and giving up.
Measure the entire login journey—not just how many people create a passkey
Suppose many customers accept the offer to create a passkey immediately after logging in. This may look like a success, but it says nothing yet about what happens on their next visit. Customers may choose passwords out of habit, try to log in from another device or enter recovery after changing phones. Business value only emerges when they can genuinely return more easily and securely.
The measurement plan should therefore begin before launch. A baseline covering password logins, abandonment, recovery attempts and categorised support requests provides something against which to compare the pilot’s progress. The aim is not to collect everything that can be collected, but to answer specific questions: does the customer complete registration, does the next login work, and does dependence on fallback routes increase or decrease?
The following events provide a practical foundation. The names are examples and can be adapted to the existing analytics model, but their meaning should remain consistent across the frontend, backend and support team.
| Event | What it shows | Business question | Privacy boundary |
|---|---|---|---|
| Offer displayed | The customer has been offered the opportunity to create a passkey in a relevant context. | Is the pilot reaching the right returning customers, or is the offer being shown where the benefit is limited? | Do not log unnecessary page details or content from the customer’s account. |
| Registration started | The customer has actively chosen to launch the platform dialogue. | Does the customer understand the offer and consider it relevant? | Do not send the challenge or authentication response to the analytics tool. |
| Registration completed or cancelled | The flow succeeded, was cancelled by the user or was stopped by a categorised technical error. | Where does friction occur, and is it caused by wording, the environment or the implementation? | Never store private keys, biometric information or complete WebAuthn responses. |
| Passkey login started and completed | A registered customer attempts to return, and the result can be classified. | Does returning login genuinely become easier over time? | Do not use persistent key identifiers in the standard analytics tool. |
| Fallback method selected | The customer leaves the passkey flow for a password, email link or another registered method. | Is the choice caused by habit, a missing passkey, a device change or a technical error? | Record the method category and outcome, not a password, link token or one-time code. |
| Account recovery started and completed | The customer needs to change which credentials control the account. | Do passkeys create new recovery needs after events such as device changes? | Identity evidence and support notes must not be copied into product analytics. |
| Support contact categorised | A case can be associated with issues such as terminology confusion, a missing device or recovery. | Is the cost shifting from password questions to other types of support demand? | Use a broad case category rather than free text containing personal data. |
The distinction between user abandonment and a technical error is crucial. A customer who closes the dialogue because they feel uncertain needs better communication, while a failure in domain verification, the server challenge or authentication response requires technical troubleshooting. If both fall into the same category, the team is likely to prioritise the wrong action. Analytics categories should therefore reflect the decisions the product and development teams can actually make.
Segmentation is necessary, but it should remain at a level that is useful without creating a detailed fingerprint of every customer. Browser family, operating system family, standard browser or embedded web view, and local or QR-based flow may be enough to identify clear patterns. Combining too many technical attributes makes the analysis both difficult to interpret and unnecessarily detailed. The authentication server’s security log and product analytics also serve different purposes and should not be combined by default.
One important area of measurement is what happens after a passkey has been registered. If the same customers frequently proceed to a password, recovery or support, the cause may be missing synchronisation, a switch between ecosystems or unclear account settings. If returning passkey logins are instead completed without additional steps, there is evidence that the solution is delivering its intended benefit. The assessment should be connected to business outcomes by tracking whether customers can complete their purchase, find their order or finish a self-service task after logging in.
A controlled rollout makes the results easier to interpret. Begin with users who are already logged in and choose to participate, while keeping the established fallback method intact. Feature flags make it possible to adjust wording, placement and technical flows without changing the experience for everyone at once. Support should know which customers are in the pilot group and use the same error categories as the product team so recurring problems are not lost in free-text notes.
Avoid defining success solely as a high registration rate. A more sustainable assessment combines successful subsequent logins, a low rate of unexplained abandonment, proportionate use of fallback routes and manageable support demand. Only then can you decide whether passkeys should receive more prominent placement, remain an optional feature or be paused while recovery and the interface are improved.
Four criteria that determine whether passkeys are the right investment
Assess passkeys based on customers’ actual login problems, not only the technology’s potential. The following criteria help you evaluate business value, security, usability and measurability as parts of the same customer journey.
Confirm that password friction affects the business
Determine whether forgotten passwords, abandoned logins and recovery cases genuinely obstruct purchases, self-service or recurring use. Look for the connection between login problems and what customers are trying to achieve, not merely technical errors. If problems are rare or customers log in infrequently, a better checkout, clearer email links or simplified account management may deliver greater value than a passkey solution.
Indicator: The decision should be supported by data from the entire login and recovery journey, not merely by a desire to introduce new technology.
Review fallback login as part of security
Passkeys offer limited security benefits if an attacker can easily choose a weaker route through email, a password or customer service. Identity verification, lost devices, registration of new passkeys and revocation of old credentials should therefore be assessed as a connected chain. The provider needs to explain what happens during both standard fallback login and complete account recovery.
Indicator: Be cautious if the provider describes the passkey flow in detail but cannot demonstrate how fallback login, support and account recovery are protected.
Test the interface without requiring knowledge of passkeys
Customers should understand what is happening, why the option is useful and what the next step is without knowing anything about WebAuthn. Wording and choices need to work when the customer uses a new phone, shared computer, external password manager or QR flow from another device. Testing should include people who have never created a passkey, not just developers already familiar with platform dialogues.
Indicator: A well-designed solution can demonstrate working journeys for new, returning and uncertain users on the devices and browsers used by the business’s customers.
Measure the entire journey from offer to successful return
The number of passkeys created does not reveal whether the solution reduces friction or improves business performance. Track the offer, registration, subsequent login, abandonment, fallback routes, recovery and customer support. Then connect authentication with the customer’s intention, such as completing a purchase or handling a portal case, without exposing sensitive credentials.
Indicator: Confirm that the solution provides separate, privacy-conscious events for every significant step while keeping private keys, biometric information and complete authentication responses out of analytics tools.
Start here: introduce passkeys step by step
-
Map login, accounts and recovery flows
Document the current registration, login, any two-factor authentication, fallback methods, account recovery and customer support processes in Miro or Lucidchart. Mark where identity is actually managed: this may be Microsoft Entra External ID, Auth0, Amazon Cognito, an e-commerce platform or a custom solution. Include how email addresses are changed, how old sessions are terminated and what support staff are allowed to do, as these routes can alter who controls the account. The result should be a shared basis for decision-making that shows whether passkeys can be enabled through an existing provider or whether the business needs to build parts of the WebAuthn flow itself.
-
Verify support in your identity platform before development
Read the provider’s documentation and test the features in a separate environment. Do not merely confirm that the word “passkeys” appears. Check how the platform handles multiple keys per account, synced and device-bound credentials, fallback login, recovery, notifications and event logs. Passkeys.dev can provide technical guidance, while the provider’s own documentation must determine which features are actually available in your configuration. Compile the answers into a short requirements list, then make a documented choice between standard functionality, the provider’s SDK or a custom implementation.
-
Build a limited pilot for existing customers
Allow customers who are already logged in to register a passkey from their account settings rather than immediately rebuilding the entire registration and checkout flow. Start registration only after an appropriate identity check, let the customer name their passkey and clearly confirm when it is ready. In JavaScript environments, the provider’s SDK or an established library such as SimpleWebAuthn can reduce the amount of custom protocol code, but the server must still verify the correct domain binding, challenge and expected account. The pilot should be optional and retain password login or another established method as a fallback until measurement shows that the complete journey works.
-
Test devices, browsers and critical edge cases
Test real combinations of iOS, Android, Windows and macOS with current versions of Safari, Chrome and Edge. BrowserStack can supplement physical hardware, but some platform dialogues, biometric checks and cross-device flows need to be tested on real devices for the experience to be assessed accurately. Run scenarios involving a new phone, lost device, shared computer, multiple passkeys, cancelled registration, missing synchronisation, an embedded web view and a failed QR login. The result should be a specific issue list, clear customer messages and a recovery process that support staff can actually follow under pressure.
-
Launch gradually and track the entire login funnel
Enable passkeys for a limited customer group using feature flags in tools such as LaunchDarkly, Unleash or your own configuration. Track offers, registration starts, completed registrations, subsequent successful logins, user abandonment, categorised technical errors, fallback to passwords and support cases in Matomo, GA4 or the organisation’s observability platform. Authentication secrets must remain in the systems that need them; product analytics only requires outcomes, journey steps and broad technical context. When support observations and login data point in the same direction, the business gains an evidence-based foundation for adjusting the interface, strengthening recovery or expanding the rollout without locking customers out.
Prioritise a robust recovery process and clear customer communication just as highly as the WebAuthn integration itself. This is how we at FLAR AB would approach the issue: first map the real friction and fallback routes, then build a measurable pilot that can be reversed without affecting every customer. Once the pilot works reliably, passkeys can become the recommended primary option. Passwords and other fallback methods should only be phased out or repositioned when your own usage data shows that customers can return securely even after changing devices or encountering unexpected interruptions.
