Search for a command to run...
Passkeys remove a common phishing target, but a weak reset flow can undo the security gain. Start with recovery, then add credentials without locking users out.
No comments yet. Be the first to comment.
ADNOC connects 120+ rigs to one AI operations centre, with large reported gains and unanswered questions about evidence, control and resilience.
Saudi clearance and UAE Peppol exchange demand different country adapters, not two billing platforms.
July funding rose to $172.6 million, but debt and two Gulf markets accounted for most of the increase.
A mobile-friendly guide to cloud availability, residency, procurement and recovery across four Gulf markets.
Sultan Byte
16 posts
Articles addressing day-to-day development challenges
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:
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.
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 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 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 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.
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 describes authentication, signature and eSeal capabilities, plus document and data sharing. Its web authentication flow 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. 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 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.
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 says the public key is stored server-side while the biometric remains local. Apple says in its iCloud Keychain security documentation 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:
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.
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.
Run this checklist for each account type and sensitive action. Record the answer, owner, and test evidence in the security design review.
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.
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.
