# Passkeys for MENA Apps: Build the Recovery Path First

Passkey demos usually begin at the pleasant part: a biometric prompt appears, the user approves it, and the session opens. Production systems have to handle a less polished moment. The user has replaced a phone, lost access to a synced credential provider, forgotten which account they used, or reached the service from a shared computer.

That is where a passkey programme succeeds or fails.

For teams building consumer, government-adjacent, fintech, healthcare, or workforce apps in Middle East and North Africa markets, the architecture should separate three jobs:

1. Authentication answers whether the person controls an accepted credential now.
2. Identity proofing or federation connects an account to an asserted identity through a separate process or provider.
3. Account recovery restores access after normal authenticators are unavailable.

Treating these jobs as one flow creates dangerous shortcuts. A national identity login is not automatically an account recovery policy. A device biometric is not identity proofing. A successful support interaction should not silently grant the same assurance as a phishing-resistant authenticator.

## What a passkey changes, and what it does not

A passkey is a WebAuthn credential. During registration, an authenticator creates a public-private key pair. The relying party stores the public key. During authentication, the authenticator signs a fresh challenge after user interaction. The [W3C WebAuthn Level 3 specification](https://www.w3.org/TR/webauthn-3/) defines these ceremonies, the origin and relying-party scope of credentials, platform and roaming authenticators, and the role of user consent.

The private key does not become another password in the application database. The [FIDO Alliance passkey overview](https://fidoalliance.org/passkeys/) describes passkeys as FIDO credentials unlocked with a device biometric, PIN, or pattern. That is an industry-body description, not evidence that every device and account ecosystem behaves identically.

A biometric used to unlock a credential is also easy to misdescribe. It normally acts as local activation on the device. It is not a facial image sent to the application for comparison. [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) distinguishes a local activation secret or biometric from a secret sent to the verifier. The same guidance requires an AAL2 service to offer a phishing-resistant option, while AAL3 requires a phishing-resistant authenticator with a non-exportable key. Those requirements only map to a product after its assurance needs and authenticator properties have been assessed.

Passkeys therefore improve the authentication layer, especially its resistance to credential phishing. They do not decide who originally opened the account, whether a national identity assertion is acceptable for a transaction, or what happens after every registered authenticator is gone.

## Keep national identity flows in their own lane

UAE PASS and Saudi Nafath belong in the identity and federation discussion, but product teams should avoid treating the names as interchangeable integration primitives.

The official [UAE PASS documentation](https://docs.uaepass.ae/) describes authentication, signature and eSeal capabilities, plus document and data sharing. Its [web authentication flow](https://docs.uaepass.ae/feature-guides/authentication/web-application/1.-obtaining-the-oauth2-access-code) uses an OAuth 2 authorization code, recommends `state` for CSRF protection, and supports `ui_locales` values for English and Arabic. The application then performs the documented [access-token exchange](https://docs.uaepass.ae/feature-guides/authentication/web-application/2.-obtaining-the-access-token). Those are federation mechanics. Your service still needs explicit rules for account linking, duplicate identities, changed attributes, revoked links, and recovery.

Saudi Arabia's official [Nafath login page](https://www.iam.gov.sa/) confirms app and username/password login options and identifies SDAIA as the operator. That public page alone does not establish API behaviour, eligibility, assurance, or recovery semantics for a relying service. Teams considering Nafath should verify those details through the applicable official integration channel instead of copying assumptions from another provider.

A federated identity event can supply evidence to a recovery decision, but it should not become an undocumented master key. Record the assertion, account-linking rule, and any additional recovery checks.

## Design the locked-out state before the happy path

Start by listing how access can disappear. A user may lose one device while retaining another. A synced passkey may reappear after the user restores access to the platform account. A hardware security key may be available in a drawer. A user may have none of these.

Platform recovery deserves precise wording. Google documentation says passkeys may be synced and supports cross-device, or hybrid, sign-in where a nearby phone authenticates on another device. Its [passkey overview](https://developers.google.com/identity/passkeys) says the public key is stored server-side while the biometric remains local. Apple says in its [iCloud Keychain security documentation](https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/web) that passkeys sync end to end between a user's Apple devices without exposure to Apple, and that keychain recovery is available. These vendor descriptions should inform UX copy, not replace your recovery model.

Give each account more than one credible route back in:

- Let users register multiple passkeys, including credentials on another device or a roaming security key where the risk warrants it.
- Show registered credentials with useful names, creation dates, and recent-use information. Let the user revoke one without deleting the rest.
- Issue recovery codes only if the product can store them safely, rotate them after use, and explain that each code is sensitive. NIST defines recovery codes and account recovery requirements in SP 800-63B.
- Apply a delay, notification, or restricted session when recovery uses weaker evidence than normal authentication. High-impact changes can wait until the account has regained a stronger authenticator.
- Separate customer-support access from recovery approval. An agent should see the minimum information needed and should not be able to bypass controls without an auditable policy path.

Recovery should end by enrolling a fresh authenticator and invalidating temporary recovery state. It should not leave the account permanently dependent on the weaker channel that restored access.

## Add passkeys before removing passwords

An additive rollout gives the team real evidence about device coverage and failure modes. Existing users keep their current sign-in method while the product offers passkey creation after a successful authentication. New users can be prompted after account setup, with a clear skip option during the early stages.

Avoid making a single passkey mandatory at enrolment. A user who creates one credential on a work laptop may later return on a personal phone. Someone on a shared household device may not want a discoverable credential associated with that device. Another user may rely on a QR-mediated cross-device flow rather than synchronising credentials.

Shared-device UX needs more than a generic "use a passkey" button. Explain where the credential may be saved, provide a route to use another device, and keep account switching visible. Do not reveal unnecessary account details on the chooser or lock screen. After sign-out, make the difference between ending the service session and deleting a device-held passkey clear.

Arabic and English flows need equal treatment at the failure edges. Translate authenticator naming, recovery instructions, device-transfer prompts, support messages, and the sign-in button. Test right-to-left layout with operating-system dialogs and QR screens. Preserve the user's language through redirects where supported, such as UAE PASS `ui_locales`, and return them to the same task after authentication.

## A reproducible implementation decision aid

Run this checklist for each account type and sensitive action. Record the answer, owner, and test evidence in the security design review.

- **Define the action:** Is this sign-in, credential enrolment, account linking, recovery, or approval of a sensitive change?
- **Set the assurance target:** Which threats matter, and does policy require a phishing-resistant or non-exportable authenticator?
- **Choose credential coverage:** Which platform, synced, and roaming authenticators will be accepted? Can the user register at least two?
- **Specify server verification:** Use a maintained WebAuthn library. Generate a unique cryptographically secure challenge for every attempt, then verify the challenge, origin, RP ID, signature, and relevant authenticator data. These checks follow [Google's server-side implementation guidance](https://developers.google.com/identity/passkeys/developer-guides/server-authentication), which is vendor documentation consistent with the WebAuthn ceremony.
- **Map every loss case:** Document the route for one device lost, all devices lost, platform-account loss, changed phone number, inaccessible email, and unavailable federation provider.
- **Grade recovery evidence:** State which evidence combinations restore full access, create a restricted session, trigger a delay, or require manual review.
- **Protect linking:** Require recent authentication before adding a passkey or linking a federated identity. Notify the user through an existing channel after the change.
- **Test language and device paths:** Cover Arabic and English, right-to-left layout, shared browsers, embedded webviews if supported, QR transfer, cancelled prompts, and account switching.
- **Instrument outcomes:** Capture ceremony type, result category, authenticator attachment where available, cross-device path, recovery start and completion, fallback used, and time to regain access. Do not log challenges, credential secrets, recovery codes, biometric data, or unnecessary identity attributes.
- **Write rollback rules:** Define the thresholds and incident conditions that pause prompts, restore a fallback, or disable a broken platform path.

![Three separate paths to account access: passkey authentication, identity federation, and graded account recovery converge at a policy gateway that issues a full session, restricted session, or denial.](https://cdn.hashnode.com/uploads/covers/60ecf4a0fc37a15ec15655e8/a80f90f4-b214-4247-99ce-e7cca4dafd48.png)

*Infographic caption: Authentication, identity federation, and account recovery use separate controls before an account session is issued. Credit: SultanByte original graphic; technical basis: W3C WebAuthn Level 3 and NIST SP 800-63B.*

## Roll out by evidence, not enthusiasm

A controlled rollout can begin with employees and test accounts, then move to opted-in users on compatible platforms. Later cohorts can receive post-login enrolment prompts. Passwordless-by-default should wait until recovery, fallback, device, and support data show that the service can handle ordinary loss events.

Track registration offer, start, completion, cancellation, authentication success, fallback, and recovery outcomes separately. A low completion rate may indicate unclear copy or an unsupported context. A rise in recovery starts after enrolment may point to poor credential portability or users misunderstanding where a passkey was saved. Segment only where there is a product reason, and avoid collecting identity data that the diagnosis does not need.

Security telemetry needs abuse signals too. Watch repeated recovery attempts, bursts of new credential enrolment, rapid removal of older credentials, account-link changes, and recovery followed by sensitive actions. Tune controls against observed abuse and false positives. Do not turn every unfamiliar device into an emergency, especially when cross-device authentication is an intended path.

The decision to retire passwords belongs at the end of this sequence. It should be scoped by account population, supported devices, recovery strength, and operational readiness. A passkey programme is ready for that discussion when losing a phone is a tested product flow rather than an exception handed to support.

*Cover artwork: SultanByte original illustration.*