Passwords leak. OTPs get phished, SIM-swapped, and intercepted. Build products for Indian users and you already know both problems first-hand. Passkeys are the first widely supported login method that drops the shared secret entirely, which finally makes phishing-resistant auth practical at scale. What they are, why they matter for products in India, and how to roll them out without breaking the users who still lean on OTP: all below.

What passkeys and WebAuthn are

A passkey is a cryptographic key pair that replaces a password. The private key stays on the user's device, protected by the device unlock (fingerprint, face, or PIN). The public key is registered with your service. When the user signs in, their device signs a fresh challenge with the private key, and your server verifies it against the stored public key. Nothing shared to steal, reuse, or phish.

Under the hood, passkeys are the consumer-friendly name for credentials built on the WebAuthn browser API and the FIDO2 standards from the FIDO Alliance. The browser and operating system handle the hard parts: key generation, secure storage, and the unlock prompt. Your application talks to a standard API and never touches the private key.

Two properties make passkeys different from passwords and OTPs:

They are bound to your domain. A passkey created for accounts.yourapp.in will not sign a challenge for a look-alike phishing domain. The browser enforces this. That is what "phishing-resistant" means in practice.
They sync, or they don't, by design. Platform passkeys (Apple, Google, Microsoft) sync across a user's devices through their account. Hardware security keys stay on the key. You support both with the same code.

The India case for passkeys

The case for passkeys in India is mostly a case against the alternatives.

OTP is the default second factor for most Indian products, usually over SMS. It works, but it carries real cost and real risk. SMS OTP delivery is metered, can crawl on congested routes, and is the target of SIM-swap fraud and OTP-relay scams. The Reserve Bank of India and CERT-In have both repeatedly flagged OTP social-engineering as a leading vector for account takeover. You can't read a passkey out over a phone call or type it into a fake page, because there's nothing to read out and nothing to type.

Then there's the device-reality argument. India is a mobile-first market where most users sign in from Android phones. Android and Chrome have supported platform passkeys for a few years now, and the unlock the user already uses to open their phone is the same gesture that signs a passkey. For most of your users, the hardware and the habit are already there.

Passkeys also shrink the personal data you collect and hold. You store a public key, not a password hash and not a stream of phone numbers tied to OTP logs. Under the Digital Personal Data Protection Act 2023, less stored personal data means a smaller surface for a breach and a simpler story for data-minimisation. For the broader compliance picture, our DPDP compliance checklist for SaaS covers where authentication fits. This is general information, not legal advice.

How adoption tends to go

Passkey adoption is rarely all-or-nothing, so don't plan it that way. A realistic rollout looks like a curve, not a switch.

Stage	What users do	What you should expect
Offer	You show a "create a passkey" prompt after login	A minority opt in at first, often power users
Default	New sign-ups land on passkey-first	Adoption climbs as friction drops
Nudge	You prompt OTP users to add a passkey	Steady conversion over weeks, not days
Reduce	You make OTP a fallback, not the front door	Most active users now sign in with a passkey

A few patterns hold true in practice. Users on shared or older Android devices may not have a synced passkey provider, so you can't remove the fallback entirely. Some create a passkey, then sign in on a new device that doesn't have it yet, which is exactly why you keep a recovery path. And the prompt copy matters more than you'd think: "Sign in faster next time, no OTP" converts better than "Register a FIDO2 credential."

The honest takeaway: FIDO2 passwordless is a destination, not a launch-day state. You move users toward it.

Passkeys with an OTP fallback

The right design isn't "passkeys instead of OTP." It's "passkeys first, OTP as the safety net." You need a fallback for new devices, lost devices, and users who haven't enrolled yet.

NamoID is built around a single OIDC issuer that puts passkeys and India verification rails behind the same authorization-code flow, so the fallback logic lives in the issuer instead of your application. The flow looks like this:

User starts sign-in. If they have a registered passkey for your domain, the WebAuthn ceremony runs first.
If no passkey is present, or the user chooses "another way," fall back to an OTP channel: WhatsApp OTP, SMS OTP on a DLT-compliant template, or email OTP.
After a successful OTP sign-in, prompt the user to add a passkey so the next login skips the OTP.

Since every step runs through the same issuer, the same audit and the same token rules apply whether the user came in by passkey or OTP. Weighing OTP channels for that fallback? Our WhatsApp OTP vs SMS OTP for India post breaks down deliverability and DLT.

NamoID also supports TOTP MFA and social federation (Google, GitHub, LinkedIn) through the same issuer, so a passkey, an authenticator app, and a Google login are all just credentials the issuer knows how to verify.

Implementation steps

You don't implement the WebAuthn protocol by hand. You point your app at an OIDC issuer that speaks it, and you handle the standard OAuth 2.1 authorization-code flow with PKCE. NamoID enforces PKCE on every flow, first-party clients included, so the public-client browser path is covered by default.

The shape of the integration is a normal OIDC redirect. Discover the issuer's endpoints:

curl https://issuer.example.in/.well-known/openid-configuration

That returns the authorization_endpoint, token_endpoint, jwks_uri, and supported scopes. Your client then runs the standard authorization-code-with-PKCE flow. Generate a code verifier and challenge, send the user to authorize, and exchange the returned code at the token endpoint:

# 1. Send the user to the authorization endpoint (passkey prompt happens here)
#    https://issuer.example.in/authorize
#      ?response_type=code
#      &client_id=YOUR_CLIENT_ID
#      &redirect_uri=https://yourapp.in/callback
#      &scope=openid%20profile
#      &code_challenge=GENERATED_CHALLENGE
#      &code_challenge_method=S256
#      &state=RANDOM_STATE
 
# 2. Exchange the code for tokens
curl -X POST https://issuer.example.in/token \
  -d grant_type=authorization_code \
  -d code=AUTH_CODE_FROM_CALLBACK \
  -d redirect_uri=https://yourapp.in/callback \
  -d client_id=YOUR_CLIENT_ID \
  -d code_verifier=ORIGINAL_VERIFIER

The passkey ceremony runs on the issuer's hosted pages during step one, so your application never handles the WebAuthn challenge directly. You receive an ID token and an access token at the end.

Verify the ID token against the issuer's public keys. The issuer publishes only its public key at the JWKS endpoint; the private signing key never leaves it:

curl https://issuer.example.in/jwks.json

A verified RS256 ID token gives you the user's stable subject identifier and the claims you scoped. From there, your session handling stays the same whether the user authenticated with a passkey, a social login, or an OTP fallback. NamoID rotates refresh tokens on every use, and reusing an old one revokes the whole chain, which closes the replay window if a token is stolen.

A short checklist before you ship:

Serve auth pages from a stable domain, because passkeys are bound to it. Moving domains later means re-enrolment.
Always offer a visible "use another way" path so a user without a passkey is never stuck.
Prompt for passkey creation after a successful OTP login, not before, so you do not block first-time users.
Log enrolment and sign-in as audit events so you can prove who authenticated and how.

A migration path from passwords and OTP

You can't flip every user to passkeys at once, and you shouldn't try. Treat migration as a gradual reduction of weaker factors, not a hard cutover.

A workable sequence:

Keep your current login working. Passwords and OTP stay live. Nothing breaks on day one.
Add passkey enrolment behind the existing login. After a user signs in the old way, offer to create a passkey. This is opt-in and reversible.
Make passkeys the preferred path. When a user has a passkey, present it first and push OTP and password down to "another way."
Default new sign-ups to passkey-first. New users never form a password habit, which is the cheapest adoption you will get.
Demote, do not delete, the old factors. Keep OTP as a recovery and new-device path. Removing it entirely will lock out the long tail of users on devices without a passkey provider.

Since NamoID runs every method through one issuer, this migration doesn't make you rewrite your application for each step. You change which methods the issuer offers and in what order; your OIDC client code stays the same. Every transition appends to an append-only events table, so you keep a DPDP-grade record of when a user enrolled a passkey, when OTP was used as a fallback, and when an old factor was retired. For why that audit trail matters under the Act, see our note on DPDP audit trail requirements. This is general information, not legal advice.

FAQ

Are passkeys safe if a user loses their phone?

Yes, with a recovery path. Platform passkeys from Apple, Google, and Microsoft sync through the user's account, so a new phone signed in to the same account restores the passkey. To cover the gap, keep an OTP or email fallback so a user on a fresh device can still sign in and re-enrol.

Do passkeys work on Android phones common in India?

Yes. Android and Chrome have supported platform passkeys for a few years, and the device unlock the user already uses doubles as the passkey gesture. Users on very old devices without a synced provider fall back to OTP, which is why you keep that path.

Can passkeys replace OTP entirely in India?

Not on day one, and usually not completely. New devices, lost devices, and not-yet-enrolled users all need a fallback. The realistic goal is passkeys for most active sign-ins, with OTP demoted to a recovery and new-device path rather than the front door.

Are passkeys really phishing-resistant?

Yes, by design. A passkey is cryptographically bound to your domain, so it will not authenticate against a look-alike phishing site, and there is no code or password for a user to be tricked into revealing. This is the core reason the FIDO Alliance promotes them over shared secrets.

See where this fits for your product

NamoID puts passkeys, OTP fallback, social login, and India verification rails behind a single OIDC issuer, with DPDP-grade audit built in. Want to talk through a passkey rollout or a migration off OTP? Book a 30-minute demo or reach us at hello@namoid.in.