Passkeys are a strong upgrade from passwords and SMS one-time codes for many customer and workforce logins, but the safest migration is usually passkey-first, not passkey-only on day one. Let users enroll a passkey, keep a controlled recovery path while adoption grows, require stronger credentials for administrators and high-risk actions, and measure support failures before removing legacy methods.

The timing is good for teams planning authentication upgrades. On 25 August 2026, the W3C published Web Authentication Level 3 as a Recommendation. WebAuthn is the browser standard behind passkeys: it lets a site authenticate a user with a public-key credential scoped to that site instead of relying on a reusable password.

What is the practical difference between a passkey and an OTP?

A password or SMS OTP depends on a secret or code that a person can type into a website. That makes the credential portable — and portability is exactly what phishing sites exploit.

A passkey works differently. The user’s device creates a public-private key pair. The service stores the public key, while the private key remains protected by the user’s passkey provider or authenticator. During sign-in, the service sends a challenge that the device signs. The browser and operating system also bind the credential to the correct site identity.

Google’s passkey guidance describes this as phishing-resistant because the credential is scoped to the website or app that created it. It also notes that biometric material used to unlock a passkey stays on the user’s device rather than being sent to the website.

This does not mean every OTP should disappear immediately. OTPs can still be useful as transitional fallback, account recovery or an additional check in a specific flow. The design question is whether OTP remains the main login factor after a safer credential is available.

Should customer apps use synced or device-bound passkeys?

There are two important operating models.

Synced passkeys can follow a user across devices through a passkey provider. They are convenient for consumer services because a customer who changes phone or laptop can often continue signing in without creating a new credential from scratch.

Device-bound passkeys stay on a particular authenticator, such as a hardware security key. FIDO Alliance guidance distinguishes these two models and notes that device-bound credentials can be appropriate for higher-assurance environments.

For most consumer portals, synced passkeys are usually the simpler starting point. For administrators, finance users or privileged operators, a business may choose device-bound credentials or hardware security keys where the risk justifies the extra operational work.

The right choice should follow the account’s risk, not a blanket rule for the whole company.

What happens when a user changes phone or laptop?

This is where a good passkey rollout succeeds or fails.

Google documents cross-device sign-in flows in which a user can authenticate on one device using a passkey available on another device, including QR-based flows supported by compatible platforms. Synced passkeys can also reappear on a new device through the user’s passkey provider.

But no authentication design should assume recovery will always work automatically. Users can lose all devices, lose access to a passkey provider account or need to recover a locked business account.

Build recovery as a first-class security flow:

  1. Let users register more than one passkey when appropriate.
  2. Show users which credentials are registered and let them remove old ones.
  3. For privileged workforce accounts, consider a backup hardware credential.
  4. Require stronger verification before replacing or resetting authentication on a high-value account.
  5. Notify the user when a new passkey is registered or a recovery event changes access.

A weak recovery process can cancel out the security benefit of a strong primary login method.

How should a business migrate without locking out customers?

Do not turn off passwords or OTPs for everyone in one release.

A safer migration can happen in four stages.

Stage 1: offer enrollment after a successful login

After a customer signs in normally, invite them to create a passkey. Explain the benefit in plain language: faster sign-in and stronger protection against phishing.

Keep the enrollment optional while you learn which browsers, devices and support cases matter most to your users.

Stage 2: make passkeys the preferred return path

Once a passkey exists, show it first on future visits. Google’s passkey use-case guidance describes autofill and passkey-first experiences that can coexist with username and password forms during migration.

This reduces friction without creating a hard cutover.

Stage 3: use stronger authentication for sensitive actions

Login is not the only moment that matters. Consider step-up authentication before high-impact actions such as changing payout details, adding an administrator, exporting sensitive data or resetting another user’s access.

A passkey can be used for reauthentication, but the action policy should still consider session age, device state, unusual activity and the value of the operation.

Stage 4: retire legacy methods only when recovery is ready

Remove password or OTP fallback only after you have measured passkey adoption, recovery success, unsupported-device cases and support volume.

If a legacy method remains active, attackers may target that weaker path. If it is removed too early, legitimate users may be locked out. Migration quality matters as much as cryptography.

What should Saudi businesses consider?

For a Saudi business, passkeys should fit into the organization’s wider cybersecurity and identity governance rather than be treated as a standalone login feature.

The Saudi National Cybersecurity Authority’s Non-CNI Private Sector Entities Cybersecurity Controls (NCNICC–1:2025) establish minimum cybersecurity controls for private-sector entities outside critical national infrastructure. The controls do not make a universal technology choice for every login scenario; each organization still needs to map authentication, access control, recovery and monitoring to its own systems, risks and applicable requirements.

NCA also launched a phishing simulation service in September 2025 for Saudi entities, underlining that phishing remains an operational risk that organizations need to manage through both technology and awareness.

For practical implementation, document who can enroll credentials, how administrators recover access, how lost credentials are revoked, which actions require reauthentication, how authentication events are logged and how helpdesk staff verify a caller before changing account access.

This article is technology guidance, not legal or regulatory advice.

A hypothetical rollout for a Saudi customer portal

Imagine a Saudi services company with a bilingual website and mobile app. Customers currently sign in with email, password and SMS OTP for some sensitive actions.

A controlled upgrade could look like this:

  1. Add passkey enrollment to the account-security page.
  2. Invite already authenticated users to enroll after a successful login.
  3. Keep password and OTP fallback during the transition.
  4. Prefer passkey autofill on returning visits.
  5. Require passkey reauthentication before changing payout, identity or administrator details.
  6. Let users register a second passkey and remove old credentials.
  7. Send security notifications when a new credential is added.
  8. Monitor successful passkey sign-ins, fallback frequency, recovery failures and support tickets.
  9. Move privileged workforce accounts to a stricter policy, potentially including device-bound hardware credentials.
  10. Retire weaker fallback paths only after the recovery design has been tested.

The goal is not “passwordless” as a marketing label. The goal is a login and recovery system that is harder to phish, easier to operate and appropriate for the account risk.

What should the engineering team test?

Authentication changes deserve more than a happy-path test.

Test passkey registration, returning-user sign-in, cross-device sign-in, removal of a credential, account recovery, new-device notifications, session expiry, reauthentication for sensitive actions and support-assisted recovery.

Also test Arabic and English interface text, right-to-left layouts, browser and mobile compatibility, and what happens when a user declines biometric or device-unlock prompts. A secure flow that customers cannot understand will create fallback pressure and support work.

Google’s server-side implementation guidance recommends using maintained FIDO/WebAuthn server libraries rather than implementing the full protocol from scratch. That is a sensible default for most application teams.

FAQ

Are passkeys the same as biometrics?

No. A fingerprint or face scan may unlock a passkey on a device, but the website receives a cryptographic proof, not the biometric data itself.

Are passkeys better than SMS OTP?

For primary authentication, passkeys have a major security advantage because they are scoped to the legitimate site and do not rely on a reusable shared secret or typed code. SMS OTP can still play a transitional or recovery role, depending on the risk and user population.

Can one passkey work across devices?

Synced passkeys can be available across devices supported by the same passkey provider, while cross-device authentication can let a nearby device approve a sign-in. Device-bound passkeys stay with a specific authenticator.

Should administrators use the same setup as customers?

Not necessarily. Higher-risk administrator accounts may justify device-bound credentials, hardware security keys, tighter recovery rules and stronger monitoring.

Where Masar Next can help

If you are modernizing authentication in a customer portal or internal platform, treat the login experience, recovery path and backend controls as one system. Masar Next’s Web Development, Mobile App Development and Custom Services can help design and implement bilingual authentication flows around your existing application and APIs.

Discuss your authentication upgrade with Masar Next.

Sources

Editorial note: This article was prepared with AI assistance and checked against the primary sources linked above. It does not claim human expert, legal or regulatory review.