A UAE shopper opens a retailer's app on a new phone while travelling. The basket is ready, the promotion ends tonight and the old number no longer receives a one-time code. Support asks for a screenshot, then sends the customer between email and WhatsApp. The account is secure only in the sense that nobody can use it.
This is the real decision behind passkeys for UAE ecommerce. Passkeys can remove a password, reduce typing and resist common phishing flows. They do not decide who owns an account, how a customer recovers it or whether the purchase survives a change of device, number, browser or platform.
My argument is straightforward: do not launch passkeys as a login feature. Launch them as an account-lifecycle change. Design enrolment, sign-in, step-up, device change, recovery and support as one commercial journey before judging the technology by a successful demo.
The W3C's current Web Authentication specification explains the useful foundation. A public-key credential is scoped to a relying party, and the authenticator provides cryptographic proof of user presence or verification. The biometric, when used, stays with the authenticator rather than being revealed to the retailer. The standard defines a ceremony. The retailer still owns the journey around it.
Passkeys for UAE ecommerce begin with the customer journey
Choose one starting point. Returning customers on supported mobile devices are usually a clearer cohort than every visitor on every channel. Decide whether the first passkey is offered after a successful password or OTP sign-in, after checkout, inside account security or after a sensitive reauthentication.
Write the target in business language: fewer failed returning-customer sign-ins without increasing account recovery fraud or checkout abandonment. Then preserve a fallback while adoption is optional. Removing the familiar route on day one turns a security improvement into forced migration.
1. Bind identity before creating the credential
Passkey registration should follow a trustworthy account verification. Do not allow a weak session, an unverified email change or a customer-service shortcut to attach a strong credential to the wrong person. Record the account, credential identifier, creation time, platform context and verification path.
Domain structure matters. WebAuthn credentials are scoped to a relying-party identifier. Map the web shop, app, country storefronts, checkout domains and identity provider before implementation. The specification requires servers to verify the challenge, expected origin and relying-party details. A passkey button placed over confused account architecture is still confused architecture.
2. Make the prompt understandable in Arabic and English
“Create a passkey” describes the mechanism, not the customer benefit. Explain that the shopper can use the way they unlock their device and that the store does not receive their fingerprint or face data. Keep the choice clear. Do not bury “not now” or imply that the shopper is giving biometric data to the merchant.
Google's passkey journey guidance recommends offering creation at moments such as sign-in, account settings, recovery and reauthorisation, and establishing a recovery method for new accounts. It also recommends clear management of multiple passkeys. Test those moments in both languages, on small screens, with right-to-left layout and with the device combinations customers actually use.
This resembles the lesson in UAE ecommerce accessibility: test whether a person can complete the purchase and recover from errors, not whether one new control looks correct on the homepage.
3. Treat recovery as the security boundary
A phishing-resistant sign-in loses its value if a criminal can call support, change the phone number and reset the account through a weaker process. Map every recovery path: synced credential on a new device, another registered passkey, trusted email, mobile number, support-assisted recovery and an account with no usable factor.
NIST's current authentication guidance explains why manually entered OTPs are not phishing-resistant: they are not cryptographically bound to the session and can be relayed. That does not mean every retailer must eliminate OTP immediately. It means the team should stop calling the whole account phishing-resistant while its recovery depends on a transferable code and a hurried support agent.
Set different authority for recovery outcomes. A newly recovered account might browse orders immediately but require another check before changing payout details, redeeming stored value or shipping a high-risk order to a new address. Notify the customer through existing trusted channels and provide a rapid way to report an unauthorised change.
4. Preserve guest checkout and channel continuity
Do not make account creation the price of buying. Guest checkout can remain the right path for an occasional shopper. For known customers, preserve the basket when sign-in changes method or moves between app and browser. A cryptographically successful login that returns the shopper to an empty basket is a commercial failure.
UAE retail journeys are rarely one clean screen. A shopper may start from a social advertisement, continue in an app, ask a question on WhatsApp and finish on the web. Keep identity, consent, basket and order ownership explicit across those seams. The adjacent note on Saudi e-commerce checkout makes the same operating point: payment success depends on the promise and recovery path around the button.
5. Roll out by failure mode, not registration count
Start with employees and test accounts, then a small customer cohort using supported platforms, then broaden. Test creation, autofill, multiple credentials, lost device, changed number, deleted passkey, cross-device sign-in, shared device, app-to-web movement and support recovery. Include Arabic and English account names, old customer records and duplicate accounts.
Track passkey offer, creation, successful use, fallback, failure reason, recovery start, recovery completion, support contact, checkout completion and suspected takeover. Registration rate alone rewards prompts. The business outcome is a recognised customer completing a safe purchase with less friction.
Keep a manual stop rule. If recovery contacts, duplicate accounts or blocked checkouts rise, pause expansion and inspect the exact device and journey. Do not blame “user education” before checking whether the product explains the action and preserves a sensible escape.
Use a six-journey release gate
Before a broad launch, require evidence for six journeys: enrol on a trusted account; sign in on the familiar device; sign in across devices; add and remove credentials; recover after losing every credential; and complete a purchase after recovery. Each needs an owner, expected evidence, prohibited shortcut and customer message in both languages.
A business automation engagement in the UAE should connect those identity events to fraud, customer service, checkout and order systems. Authentication cannot be improved in isolation when every surrounding team can change the account.
Passkeys for UAE ecommerce are worth testing because strong authentication can become easier for the customer. But ease at the front door is only real when the side door—recovery—is usable, observable and at least as carefully controlled.
Ship the complete account journey. The passkey will then do its narrow job very well.