DEV Community: vdelitz

Passkeys for Non-Technical Users

vdelitz — Wed, 09 Sep 2026 15:03:57 +0000

Why passkeys still stall with normal users

Passkey teams usually know the security case already. The harder part is adoption: how do you get someone non-technical to actually say yes when the current login still works?

That question matters because many passkey rollouts underperform for reasons that have nothing to do with cryptography. The pattern across real deployments is pretty consistent: users adopt when the benefit is obvious, the timing makes sense, and the first attempt succeeds.

A few case studies in the source material make that painfully clear. MakeMyTrip changed its prompt from “Create a passkey” to “Skip OTP next time” and got 2x enrollment. eBay moved the prompt from settings to right after biometric login and saw 102% higher enrollment. Same technology. Better wording and timing.

The prompt should name the pain removed

Most non-technical users are not asking about phishing resistance or FIDO standards. They are asking practical questions:

what is this?
does my fingerprint get sent to the website?
what happens if I lose my phone?
do I need to remember something new?

That changes how passkey enrollment prompt wording should work. Lead with the outcome, not the mechanism.

Better:

Skip the code next time
Sign in with your face or fingerprint
Log in without waiting for an SMS

Worse:

Create a passkey
Enable passwordless login
Set up FIDO2 authentication

The lesson is simple: if the user has two seconds, spend them on the friction you remove.

Timing beats explanation

One of the more useful takeaways from the source is that education has limits. A healthcare trial found that an explanation-heavy nudge raised adoption from 18.5% to 33.2%, but the stronger result came from making the passkey button visually dominant: 46.2%.

That does not mean copy is useless. It means copy cannot rescue a badly timed prompt.

The highest-leverage moments are usually:

right after login success
right after OTP or password friction
during recovery, when the old method has already become annoying

This is why post-login passkey nudges and passkey UX timing after OTP friction matter so much more than a passive settings page. eBay got 75% of new passkeys from the login-flow prompt and only 10% from settings. Uber found more than 90% of enrollments came from inline nudges inside login and signup.

If you ask in a calm moment, users wonder why they should change. If you ask after friction, the value is already obvious.

Product changes matter more than better copy

Some of the biggest adoption gains come from changing the flow itself.

Change	Why it helps	Tradeoff
Conditional Create passkeys	Creates a passkey in the background after password manager use	Can feel invisible unless the next login is clearly better
Automatic append after successful login	Uses a moment when identity is already proven	Native dialogs can feel intrusive if shown without warning
Identifier-first login passkeys	Avoids sending users into a dead-end “no passkeys available” dialog	Adds one step for users who do have a passkey
Suppression + visible fallback	Prevents prompts on devices likely to fail	Fallback remains available, so some users will keep using it

This is also where passkey recovery after lost phone becomes decisive. You should only promise the recovery path your service really supports. “You can still recover your account if you lose your phone” is useful if it is true. “The old way will always work” is risky if product policy may change later.

Observability is what turns advice into rollout decisions

A lot of passkey advice sounds good until you try it on real users. Then you find device-specific failures, broken credential manager paths, or cohorts that never should have seen the prompt at all.

That is where authentication observability passkeys becomes practical, not theoretical. If you cannot see which browser, OS, or authenticator caused abandonment, you are mostly guessing about prompt wording, placement, and suppression rules.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

The useful mindset here is not “how do we explain passkeys better?” It is “which users saw which prompt on which device, and what happened next?”

What to optimize first

If I had to prioritize one thing, I would start with this: stop treating passkey adoption non-technical users as a messaging problem only.

Start with the post-login and post-friction surfaces. Replace technical wording with concrete benefit language. Avoid passkey buttons that can open into failure. Make recovery visible. Then measure where ceremonies break by device and cohort.

That is usually worth more than writing a longer FAQ about public key cryptography.

Read the full breakdown.

Which Tool Really Measures Auth Success?

vdelitz — Mon, 24 Aug 2026 07:23:02 +0000

The authentication success rate problem is mostly a measurement problem

Authentication teams keep asking the same question: which tool reports the real authentication success rate?

The uncomfortable answer is that most enterprise stacks already have several tools claiming to answer it, and they are all measuring different points in the same login journey. That is how one team sees 94%, the identity provider reports 98%, and support still says users are stuck. Those numbers can all be internally correct.

The issue is not the math. It is the measurement point.

At its simplest, authentication success rate is successful authentications divided by authentication attempts. But a tool can only report that honestly if it counts the attempt before the outcome is known, measures the login itself instead of the page around it, keeps method as a dimension, attaches failure reasons, and survives cross-device flows.

Why most analytics tools miss the decisive moment

Modern login flows often fail in places that page and server analytics never see.

A passkey login is the clearest example. The important part happens inside the browser's WebAuthn call, where the system prompt opens, the user interacts, and a result comes back. That whole ceremony is client-side. No page load is required. Often no request is sent either.

That creates a blind spot for common categories of authentication analytics:

Tool category	What it sees well	What it usually misses
Web analytics	Traffic to login, post-login conversion	Failures with no click, render, or navigation
Product analytics	Funnels over defined events	Anything engineers never instrumented
Session replay	Friction in your own form UI	Browser and OS prompts outside the DOM
APM / RUM	Endpoint health, latency, server errors	User-side abandonment with no request
Identity provider	API-level auth outcomes and reason codes	Attempts that never reached the API
Authentication observability	The login ceremony itself	Marketing and broader page analytics

This is why identity provider login metrics and frontend funnel numbers rarely line up.

The browser is where login truth gets lost

The hardest failures are the ones that vanish between page tracking and server logs.

Take a cancelled Face ID prompt. Your web analytics tool may never get an event. Your APM stack sees no backend request. Your IDP never receives the authentication attempt. From those systems' point of view, nothing happened.

But something absolutely happened to the user.

That is the gap authentication observability tries to fill. Instead of watching the page or the backend, it measures inside the login flow itself. For passkeys, that means WebAuthn ceremony measurement around the navigator.credentials call. For other methods, it means counting the actual password, OTP, social, or MFA step where success or abandonment occurs.

That measurement point matters for two reasons:

it captures attempts before the outcome is known
it makes client-side failures visible, including timeout, cancel, and drop-off behavior

It also makes NotAllowedError attribution possible in a more credible way. The browser does not tell you whether that error meant cancel, timeout, or no available passkey. You have to reconstruct it from timing, device capability, and what the user did next.

The real evaluation question is not features, it is measurement point

A lot of CIAM analytics buying decisions go sideways because vendors get compared by dashboard features instead of where they count attempts.

If you are evaluating tools for login funnel analytics, these five questions are more useful than a long feature list:

Where exactly is the attempt counted?
Can you show a cancelled passkey login as a row in a real report?
How do you distinguish cancel, timeout, and no passkey for the same browser error?
Can support inspect one user's full authentication path?
What happens in cross-device login tracking when the journey starts on desktop and finishes on mobile?

Those questions expose whether a product measures authentication or just activity around authentication.

There is also a bigger product question hiding above the tool comparison: does adding a new method actually get more people in? In measured deployments, the gap in total authentication success rate between users who could have used a passkey and users who could not runs from 7 to 15 percentage points. That is why passkey analytics cannot stop at passkey-only success rates. You need method and credential availability on the same dataset.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

Pick by measurement point, not by feature list

Every category reports a number that is true for the point it measures. The disagreement is the clue.

Web analytics can tell you how people reached login. APM can tell you whether the endpoint is healthy. Your IDP can tell you what reached its API. But if you want the real answer to whether authentication itself worked and why it failed, the measurement has to happen inside the login flow.

Read the full breakdown.

Passkeys Explained Clearly for Developers

vdelitz — Tue, 18 Aug 2026 08:45:53 +0000

What a passkey actually is

Vincent Delitz’s 2026 guide on passkeys is a practical explanation of the parts teams still mix up: what a passkey is, why it is phishing-resistant, and why shipping it does not guarantee anyone will use it.

The simplest mental model is this: a passkey is a cryptographic key pair for signing a user in to a service. It is not the same thing as Face ID, a fingerprint sensor, an OTP, or a hardware key, even if those often appear in the same conversation.

That distinction matters because the user gesture looks familiar while the security model is completely different. Local biometrics unlock something on one device. A passkey uses that same gesture to authorize the use of a private key, and the server verifies the result with a public key it already has.

So if someone asks what is a passkey, the short answer is: a passkey is a FIDO2/WebAuthn credential backed by a key pair, where the private key stays with the user and the server stores only a public key.

Why passkeys are not just biometrics

A lot of passkeys vs biometrics confusion comes from the UX. Users see a face scan or fingerprint prompt in both cases, so teams assume they are interchangeable. They are not.

Local biometric auth: proves the user can unlock the current device.
Passkey auth: proves the user controls a private key registered to a service.
Server visibility: local biometrics tell the server nothing; passkeys produce a verifiable signature.
Portability: passkeys can work across devices through synced providers or cross-device flows.

That is also why passkeys are often described as phishing-resistant MFA WebAuthn FIDO2 in one package. The device is one factor. The local unlock method is the second factor, whether that is biometrics or a PIN.

Where phishing resistance really comes from

The core security property is not “users are smarter” or “the prompt is harder to fake”. It is origin binding.

Passkeys are bound to a Relying Party ID, often shortened to rpID. At login, the browser checks whether the current site belongs to that rpID. If it does not, the passkey is not offered.

Passkey created for: example.com
Valid on: example.com, login.example.com
Invalid on: example-login.com, example.co, com

This is the key point behind RP ID relying party ID passkeys: the browser enforces the relationship between the credential and the real domain. On a fake site, there is no warning for the user to ignore because the passkey prompt never appears.

That is a fundamentally different security story from SMS OTP, TOTP, or push. Those methods can still be relayed through a phishing proxy. Passkeys cannot, because the credential is scoped to the legitimate domain from the start.

Synced vs device-bound passkeys

The synced vs device-bound passkeys split is where architecture decisions get real.

Type	Best for	Main advantage	Main tradeoff
Synced passkeys	Consumer apps and broad reach	Recovery and cross-device availability	Less strict device control
Device-bound passkeys	Regulated access and admin accounts	Sole control and attestation	No sync, so recovery is harder

This maps directly to NIST SP 800-63B AAL2 AAL3 passkeys discussions. Syncable passkeys top out at AAL2. Device-bound authenticators with attestation are what fit AAL3 requirements.

In practice, that usually means consumer services start with synced passkeys, while high-assurance or privileged accounts add device-bound options.

Why adoption fails after launch

The most useful product insight in the guide is that passkey adoption is not one number. It is creation times usage.

If users create passkeys but keep logging in with password plus OTP, adoption is weak. If the passkey option is buried in settings, creation is weak. A zero on either side kills the result.

Two implementation patterns matter a lot here:

conditional create passkeys: prompt right after a successful login, inside a trusted session
conditional UI: surface saved passkeys directly in the login field so they become the default path

And there is a strong production signal behind this work. The FIDO Passkey Index reports 93% login success for passkeys versus 63% for other methods.

The main engineering lesson is simple: WebAuthn correctness is not enough. You also need rollout logic, feature detection, and fallback paths, especially where conditional create support is uneven.

Read the full breakdown.

Layered Auth Beats One-Size-Fits-All Login

vdelitz — Fri, 07 Aug 2026 11:55:58 +0000

Identiverse 2026 had a more useful message than the AI hype

At Identiverse 2026, the loudest theme was agents. The more practical takeaway for CIAM and authentication teams came from the fraud track: identity fraud prevention is still mostly about executing fundamentals better, not betting on a single new control.

That matters because AI is changing fraud economics fast. As one speaker put it, many old fraud schemes are still the same schemes from the last 5 to 10 years, but AI makes them cheaper, faster, and easier to scale. So the real design problem is not “what magic product stops fraud?” It is how to build layered authentication and risk-based authentication that raise friction only when a session actually looks risky.

A good benchmark from the conference: VicRoads discussed taking passkeys live for more than 5 million users with 70–90% activation, later referenced as 80% mobile passkey activation across 5M+ users, and doing it without replacing the IDP.

The core idea: assess passively first, step up second

The strongest pattern from the conference was simple: start with passive signals, then apply step-up authentication only when the risk justifies it.

That means looking first at signals such as:

device reputation
behavioral signals
name, address, and date of birth
anomalies in the current session
the risk level of the attempted transaction

Then decide what happens next. If a user shows up on their usual device to check an insurance policy, they should not be forced through the same challenge as a suspicious session attempting a high-risk change.

This is why passkeys fit so well into consumer login security. The default path should be the low-friction, phishing-resistant one. Extra friction belongs in exceptions, not in the baseline.

The anti-pattern is familiar: every user gets the same OTP, the same knowledge questions, the same clunky fallback. That taxes 100% of users to maybe catch a small fraction of bad sessions.

Fraud is a lifecycle problem, not just a login problem

One of the sharpest points from the article is that fraud does not line up neatly with IAM system boundaries. The same identity appears at onboarding, enrollment, authentication, recovery, and payments, but many organizations still defend those stages in separate silos.

Here is the practical model:

Lifecycle stage	Main control	Common failure mode
Onboarding	KYC / KYB proofing	A synthetic identity gets in
Enrollment	Credential binding	A fraudster binds their own device or passkey
Authentication	Login and step-up	Often the strongest point
Recovery	Reset and re-proof	SMS and knowledge-based recovery become the trapdoor
Payments	High-risk actions	The user is authenticated, but the action is fraudulent

That leads to a useful rule: focus on the weakest handoff, not the strongest door.

Passkeys can harden authentication, but they do not fix a bad enrollment or a weak account recovery fraud prevention flow. If the wrong person binds the credential at enrollment, later login can be cryptographically correct and still operationally wrong.

Deepfakes and synthetic identity attacks hit verification first

Deepfake attacks matter, but mostly in identity verification, not routine authentication. The article makes this distinction clearly.

Passkeys prove possession of a private key scoped to a domain. They do not depend on what a face looks like on camera. That means deepfakes are more relevant in onboarding KYC, recovery, and high-risk step-up than in ordinary sign-in.

The same is true for synthetic identity fraud and the “fraud from the inside” pattern. CrowdStrike investigated more than 320 North Korean IT worker cases in twelve months, a 220% year-on-year increase. In those cases, the attacker often gets legitimate access through a legitimate process. Authentication controls do not catch that, because nothing is being bypassed.

That is why layered defenses need to extend beyond login to verification, least privilege, and continuous assessment.

Observability is what turns theory into operations

Most teams say they want risk-based authentication. Fewer can actually see where friction happens, where fallback gets abused, or which devices break the intended flow.

That is where authentication observability and process mining become operationally important. Login, signup, recovery, and transaction step-up should be measured as one connected journey, not as isolated events in separate dashboards.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

The broader lesson is straightforward: if you cannot see your enrollment and recovery paths with the same clarity as your happy-path login, attackers will find the window while you keep polishing the front door.

Read the full breakdown.

Passkeys in India: What changed by 2026

vdelitz — Thu, 30 Jul 2026 14:18:12 +0000

Why India is suddenly a serious passkey market

India is becoming one of the most important passkey markets because regulation, payment scale, and ecosystem activity are all moving in the same direction at the same time.

The biggest trigger is the RBI Authentication Directions, 2025. They require two independent authentication factors, with at least one dynamically generated, for all domestic digital payment transactions by April 1, 2026. That does not mandate passkeys by name, but it creates a strong push away from SMS OTP and toward phishing-resistant authentication.

On top of that, the payment surface is enormous. In December 2025 alone, UPI processed over 21.6 billion transactions worth around ₹27.97 lakh crore. When authentication sits on top of a system that large, weak factors stop being a UX annoyance and become a national-scale security problem.

Why passkeys fit the Indian shift away from OTP

A passkey is a FIDO2/WebAuthn credential stored on a user device. Instead of sending a shared secret like a password or OTP, the device signs a one-time challenge with a private key that never leaves the authenticator.

That matters because the failure modes are different:

Passwords can be reused and stolen
SMS OTPs can be phished, intercepted, or socially engineered
Passkeys are bound to the real domain, so look-alike phishing pages cannot replay them

In practical terms, the user approves login or payment with a fingerprint, face unlock, or device PIN, but the security comes from the cryptographic origin binding underneath. That is the part many teams miss when they equate passkeys with “just biometrics.”

India already has strong consumer familiarity with biometric confirmation. But device biometrics alone are not the same thing as passkeys. A biometric prompt can unlock many different authentication methods. What makes passkeys different is the WebAuthn credential and the relying-party binding behind the gesture.

Regulation is broader than just payments

The RBI framework is the clearest adoption driver, but it is not acting alone.

The DPDP Act, 2023 requires reasonable security safeguards to prevent personal data breaches, with penalties of up to ₹250 crore for failure. The DPDP Rules, 2025 add examples such as encryption, access controls, logging, and monitoring. Passkeys map naturally to that direction because they reduce the value of stolen credentials and lower phishing exposure.

Then there is CERT-In. Its directions require specified incidents, including phishing, spoofing, identity theft, and unauthorized access, to be reported within 6 hours. That does not create a passkey mandate either, but it raises the operational cost of weak authentication. Preventing account takeover becomes more valuable when incident handling windows are that tight.

A smaller but still important RBI signal is the migration to the .bank.in domain, with a deadline of October 31, 2025. That is about securing the first point of customer contact before authentication even starts.

Where passkeys are actually live in India

The clearest production movement is in payments.

Area	What happened
Mastercard	Launched Payment Passkey Service in India in August 2024 with Axis Bank, Juspay, Razorpay, PayU, and bigbasket
Visa	Launched Payment Passkey in India in July 2026 with IDFC First Bank as first issuer
Banks	Retail banking front-door passkey adoption is still early and uneven
Consumer platforms	Google, Amazon, WhatsApp, Sony PlayStation, and Zoho already expose Indian users to passkeys

That pattern matters. India is not starting from zero, but adoption is uneven across layers.

Card networks are pushing first. Consumer platforms are normalizing the UX. Banks are still catching up. And India’s digital public infrastructure, including Aadhaar, DigiLocker, and Jan Parichay, does not yet use passkeys at its core.

That last point is probably the biggest long-term opportunity. If passkeys move from checkout flows into the identity systems used by more than a billion people, India could become the most important large-scale phishing-resistant authentication deployment story anywhere.

The real technical and product challenge

The hard part is not enabling WebAuthn. The hard part is rollout across a fragmented device and habit landscape.

Teams in India have to deal with:

entrenched OTP behavior across banking and government journeys
user confusion between biometrics, Aadhaar face auth, and actual passkeys
legacy integration cost in banks and public-sector systems
device diversity and fallback needs for users without modern passkey-ready setups

That is why passkey projects in India should be treated as adoption and migration work, not just feature delivery.

Read the full breakdown.

QR Login Failure: Why QR Code Login Breaks

vdelitz — Fri, 17 Jul 2026 08:31:23 +0000

QR login is a cross-device flow, not one click

QR code login looks clean in a demo. Show a code on desktop, scan it with a phone, confirm, done.

In production, it is much messier. The article “QR Login Failure: Why QR Code Login Breaks” maps out why a simple-looking QR flow often fails across scan, handoff, proximity check, confirmation, or callback. That is the core problem with debugging QR code login not working: most teams only see the final outcome, not the failing step.

This gets worse in passkey QR code login with WebAuthn cross-device authentication (CDA). Once the browser and operating system take over, the relying party usually sees only coarse ceremony outcomes like success, error, timeout, or server verification result. The hidden middle is where the real failure often lives.

Not all QR login flows fail the same way

A useful distinction from the source material is that there are really two different flows people call “QR login.”

Flow type	What the team can usually observe	Main blind spots
Custom QR login	QR shown, scan, app open, confirmation, callback	Wrong app routing, wrong account, abandoned confirmation
WebAuthn CDA passkey QR flow	Ceremony start, completion/failure, timeout, verification result	QR scan success, Bluetooth proximity check passkeys, phone-side prompts

That distinction matters because instrumentation strategy changes completely.

In a custom flow, you can often track almost every step directly. In WebAuthn CDA, you cannot honestly claim direct visibility into scan or proximity unless your own app or SDK exposes it. You have to separate observed facts from inferred phases.

That sounds subtle, but it is the difference between useful authentication observability and hand-wavy dashboards.

The boring failures are the real failures

QR login failure is usually not caused by some exotic cryptographic edge case. It is usually a chain of small, very human problems.

Typical examples from the source:

the QR code is visible but hard to scan on a dim screen or kiosk
the user scans with the default camera app when the flow expected a specific app
the wrong phone, work profile, or account handles the challenge
Bluetooth or network restrictions break CDA proximity checks
the user confirms on mobile, but the desktop never gets the final callback
the desktop just spins, so support hears “QR login not working”

That is why QR login conversion rate can look acceptable in a demo and brittle in production. Demos control screen quality, lighting, network conditions, and device state. Real users do not.

Debugging QR login issues needs a stitched funnel

Most analytics setups are too shallow for this problem. They record “clicked sign in with QR” and maybe “login success.” Everything that matters sits in between.

A better model is an authentication analytics login funnel stitched across desktop and mobile.

For custom QR login, the article recommends tracking steps like:

QR code shown
QR code scanned
Mobile session opened
Confirmation shown
Confirmation completed
Desktop callback received
Session established

For WebAuthn CDA, the observable events are different:

passkey ceremony started
challenge created
WebAuthn call completed or failed
error name
timeout
elapsed duration
server verification result
session established

That still does not expose every phone-side step, but it gives you enough structure to infer where failures cluster.

Segmentation is where root causes appear

Once events are stitched, the next step is segmentation. This is where vague support complaints turn into patterns.

You want to compare:

custom app QR vs passkey QR vs other QR-based login methods
iOS vs Android
desktop browser differences
app versions and mobile browser behavior
abandonment vs technical failure

That last split is especially important. A user walking away from a QR screen and a Bluetooth timeout both hurt conversion, but they are not the same problem and should not get the same fix.

Corbado is a passkey observability and adoption platform for large B2C enterprises. The useful idea here is not the product name, though. It is the operating model: connect desktop start, browser or app events, server verification, and final session outcome into one journey.

If you only measure final success, every QR login failure looks identical. If you instrument the missing middle, you can finally tell whether the issue is scan quality, app handoff, WebAuthn timeout, callback failure, or user confusion.

Read the full breakdown.

Why GA4 Can't Debug Login Failures

vdelitz — Mon, 13 Jul 2026 09:49:11 +0000

The gap most teams notice too late

GA4 login tracking is good at telling you that a login funnel conversion drop happened. It is much worse at telling you why.

That sounds obvious, but it becomes a real problem once authentication stops being a simple username-and-password form. Modern login flows now include passkeys, WebAuthn prompts, social login redirects, OTP retries, native credential pickers, in-app browsers, and fallback paths. When one of those breaks, generic analytics usually shows a missing conversion, not the root cause.

That is the core boundary here: product analytics measures funnel movement, while authentication observability explains authentication failures.

What GA4 actually does well

To be fair, GA4 is useful for login-related reporting.

It works well for questions like:

How many users reached the login page?
Which login method gets clicked most?
Did checkout completion change after we reordered buttons?
Did sign-in friction hurt return visits or signup completion?

If your question is about funnel shape, business outcome correlation, or experiment measurement, GA4 can do the job.

For example, you can model events like login_started, passkey_clicked, and login_success, then compare variants across cohorts. That helps product and growth teams see whether a change improved overall conversion.

But that only answers what happened at the funnel level. It does not explain the failed authentication journey underneath it.

Why GA4 breaks down during login debugging

The main problem is simple: GA4 stores events, not authentication journeys.

A real login attempt can include:

a capability check
a native passkey prompt
a credential-provider selection
a biometric step
a redirect to a social provider
an OTP fallback
a final session creation

If one of those steps fails, GA4 usually has no native way to understand the ceremony context. Unless a team builds separate instrumentation for method, step, environment, error, and fallback path, the failure often shows up as abandonment.

That is especially painful for client-side failures. A user can hit a WebAuthn timeout, cancel a biometric prompt, lose a redirect cookie in Safari, or run into credential manager issues on Android. From a funnel dashboard, those can all look almost identical: the user started and never completed.

The missing context you need for root cause analysis

Debug login failures requires more than event counts. You need to know the exact environment and the exact step where the flow diverged.

A typical auth investigation might need dimensions like these:

Dimension	Why it matters
Login method	Passkey, password, OTP, social login all fail differently
Ceremony step	Prompt shown, credential selected, biometric started, redirect returned
Environment	Browser, OS, app version, in-app browser, device model
Provider context	Credential provider or social provider involved
Error detail	Timeout, cancel, blocked redirect, provider outage
Recovery path	Retry, fallback, abandonment, eventual success

This is also where timing matters. Incidents often live in narrow, high-cardinality slices, like one browser version inside one in-app browser or one Android credential picker regression. GA4 is not optimized for that kind of fast diagnostic slicing.

The article puts it well: GA4 can help confirm a drop, but it usually cannot tell whether the root cause was a WebAuthn timeout, Safari blocking a redirect cookie, an Android credential picker regression, a social provider outage, or a user canceling a biometric prompt.

Why authentication observability is a separate layer

Authentication observability complements GA4 instead of replacing it.

Use GA4 for broad reporting: funnel trends, experiment outcomes, and downstream business impact. Use authentication observability for the auth-specific questions GA4 does not answer well: which method failed, which cohort was affected, which step broke, and whether users recovered.

That matters beyond engineering. Product managers, growth teams, IAM owners, support, and incident responders all need the same underlying auth journey, just at different levels of detail.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

The practical takeaway is straightforward: if your dashboard says login conversion dropped, GA4 is often the start of the investigation, not the answer.

Read the full breakdown.

Windows passkeys on managed devices: debug the client

vdelitz — Tue, 07 Jul 2026 07:44:58 +0000

Windows passkey failures usually aren't one bug

The article "Windows Passkey not working on managed Devices?" argues that enterprise passkey failures on Windows are usually multi-cause problems, not a single broken login path. On managed fleets, the same user complaint can come from missing Windows Hello enrollment, the wrong credential provider being selected, a managed policy blocking prompts, Bluetooth issues in hybrid QR cross-device passkey Windows flows, or a passkey that exists in a password manager the user cannot access on that machine.

That matters because the backend often sees almost nothing useful. In many cases, Windows passkey failures happen before the server even receives a WebAuthn response. So if your telemetry only says "login failed," you're blind to the exact ceremony step where things actually broke.

Why enterprise troubleshooting is different

Consumer troubleshooting assumes one user, one device, one browser, one account. Enterprise passkey rollout analytics need a different model.

A single login journey can involve:

managed Windows laptops and BYOD devices
Edge or Chrome
Windows Hello, hardware security keys, or synced passkeys
password managers like 1Password, Dashlane, iCloud Passwords, or Google Password Manager
cross-device authentication with phone handoff

This is why Windows passkeys enterprise troubleshooting gets expensive after launch. Support tickets say "Windows Security passkey not working," but the real question is whether it's one user's setup problem or a fleet-wide regression tied to a specific Windows, browser, and provider combination.

The key debugging boundary is the ceremony, not the server

The most practical insight in the source article is where to instrument. If you want useful Windows passkey enterprise troubleshooting, collect data at the authentication ceremony boundary, not just in IdP or backend logs.

The article recommends capturing at least these dimensions:

Signal	Why it matters
Exact Windows version	Windows 10, Windows 11 23H2, and Windows 11 24H2 can behave differently
Browser and version	Edge and Chrome can route users differently
Credential provider and transport	Separates Windows Hello from password manager or hardware key paths
Ceremony step and result	Tells you whether the prompt showed, biometrics started, or the flow timed out
User journey outcome	Shows fallback to password, retry, abandonment, or support contact

This is also where errors like WebAuthn NotAllowedError timeout Windows become meaningful. A NotAllowedError after a timeout is not the same as a user cancel, and backend logs alone usually cannot tell you which one happened.

The failure modes are often policy-shaped

Managed device policy passkey issues are easy to underestimate because they create partial breakage. A browser policy, security product, or device-management change can affect passkey prompts, Bluetooth access, USB security key use, or extension behavior for only a subset of the fleet.

That's why a passkey rollout can look healthy overall while a specific cohort is failing.

A useful workflow from the article is:

Start with the affected user's last attempts.
Check device, browser, provider, transport, and ceremony step.
Expand to the cohort with the same combination.
Compare current success to that cohort's earlier baseline.
Decide whether this is a support issue, fallback issue, or rollout regression.

That last step is important. If Windows Hello passkey failure is really a Chrome plus hybrid transport regression on Windows 11 24H2, sending users another password reset email just wastes time.

Observability turns vague complaints into actionable cohorts

The source article's core argument is simple: if users report "Windows passkey not working on managed devices," your team needs client-side authentication observability for passkeys to understand what happened before the backend ever saw the login.

Corbado is a passkey observability and adoption platform for large B2C enterprises. In the article, Corbado Observe is presented as a way to capture client-side ceremony events, device and browser context, failure outcomes, and fallback behavior that standard logs miss.

For technical teams, the real value is not just per-user debugging. It's the ability to answer rollout questions like: did a Windows/browser/policy cohort start failing after a rollout, or is this just one user's setup issue?

Read the full breakdown.

Android 17 Passkeys Get Real Portability

vdelitz — Wed, 01 Jul 2026 07:57:31 +0000

Android 17 continues a quiet but important shift in passkeys: making them less fragile in real-world use. The release starts rolling out to Pixel devices in June 2026, with broader availability later, and it focuses on three things that developers actually care about: credential portability, theft resistance, and stronger high-security defaults.

The big story is not a new login UI. It is that Android 17 makes passkeys easier to move, harder to steal, and more credible as a long-term authentication baseline. That matters because passkeys have always had a perception problem: users like the convenience, but many still worry that creating one means getting trapped inside a single vendor ecosystem.

Credential Exchange fixes the lock-in problem

Android 17 adds support for the FIDO Alliance Credential Exchange standard through Google Play services 26.21. Concretely, that means users can move passwords and passkeys between Google Password Manager and third-party managers like 1Password, Bitwarden, and Dashlane.

The practical improvement is simple. Instead of exporting a CSV or JSON file and hoping sensitive data does not get left behind somewhere on disk, the transfer happens directly app-to-app and is end-to-end encrypted.

At a high level, the flow works like this:

The user starts from either import in the destination manager or export in Google Password Manager
The source and destination establish a secure channel
The user authenticates with biometrics
Credentials move directly without being written to an intermediate file

That is a meaningful upgrade for passkey portability on Android. It removes a major reason users hesitate to adopt passkeys in the first place.

There is also a broader ecosystem implication here. Apple introduced similar secure import/export in iOS 26, and Android 17 now mirrors that direction with open FIDO standards. A passkey starts looking less like a proprietary artifact and more like a portable user-controlled credential.

What developers need to implement

For credential provider developers, Android 17 turns migration into a platform capability instead of a custom workaround. The relevant integration point is the ProviderEventsManager family in androidx.credentials.

The split is straightforward:

Role	API	What it does
Importing provider	`importCredentials`	Launches provider selection and starts the transfer
Exporting provider	`registerExport`	Registers the app as a credential source

A provider that wants to export also needs to declare a transfer activity in its manifest so the framework can route requests correctly. Under the hood, Android passes data through a content URI and includes security context such as CallingAppInfo, so the exporter can verify who is requesting the transfer. A credId is also used to validate the selected export entry.

The technical detail that matters most: the secure channel is negotiated per transfer using Diffie-Hellman key exchange, and the exported payload is formatted with Credential Exchange Format (CXF). This is not just a prettier export flow. It is a safer model for moving high-value credentials.

Android 17 also hardens the device itself

Passkeys are phishing-resistant by design, but their real security still depends on the device storing them. Android 17 addresses that with stronger theft protection.

Two changes stand out:

Mark as lost in Find Hub now lets the owner lock the device with biometrics, which means even someone who knows the passcode cannot access the phone’s information or disable tracking.
PIN brute-force throttling gets tighter, with fewer allowed guesses and longer delays between failed attempts.

That matters for a very specific threat model: a thief who has both the phone and an observed PIN. Android 17 narrows that gap and gives the credential store stronger protection in exactly the scenario people worry about most.

Advanced Protection keeps passkeys at the top tier

Android 17 also strengthens Advanced Protection mode, Google’s highest-security device profile. For authentication, the signal is consistent: FIDO2 credentials, whether passkeys or hardware security keys, remain the enrollment baseline, while passwords are not considered sufficient for this tier.

That is an important message for enterprise teams. Android is no longer treating passkeys as just a convenience feature. It is treating them as the security baseline for high-risk users and stronger account protection.

For adoption, the opportunity is obvious, but execution still is not automatic. Android fleets remain fragmented across OS versions, OEM variants, and Play services rollout timing. Corbado is a passkey observability and adoption platform for large B2C enterprises. One useful benchmark from the source material: VicRoads reports 80% mobile passkey activation across 5M+ users.

Read the full breakdown.

Passkeys vs SMS OTP for Real-World Logins

vdelitz — Tue, 23 Jun 2026 15:48:34 +0000

SMS OTP is still the default second factor for a lot of banks, retailers, and marketplaces because every phone can receive a text. But that reach hides three separate questions: does it convert, what does it cost at scale, and how much security are you actually getting?

That is the useful frame for passkeys vs SMS OTP. Not hype. Not “what’s newer.” Just whether one method gets more users through login, costs less per successful authentication, and holds up better against phishing.

For most returning users, passkeys have a structural advantage on all three.

Conversion is really about ceremony length

The main passkeys conversion rate advantage is simple: there is no code ceremony.

With WebAuthn passkeys, the device prompts the user, they confirm with biometrics or device PIN, and the session is established. With SMS OTP, the user has to wait for the message, open it, switch context, read the code, type it, and hope delivery worked in the first place.

Every step in that wait-read-switch-type flow is a place to lose users. And many of those failures are silent in standard analytics:

the code arrives late
the code lands in the wrong app context
the user mistypes it
retries inflate friction before the backend sees a clean completion or failure

That is why “SMS reaches everyone” is not the same as “SMS converts well.” Reach measures coverage. Conversion measures completed sessions.

If you are comparing passkeys security vs SMS or debating a passkey adoption strategy, this distinction matters more than most teams expect.

Cost is not per message, it is per successful login

SMS OTP authentication cost is often underestimated because teams look at carrier pricing instead of completed outcomes.

The article’s point here is practical: SMS has a per-message fee on every send, including retries. Those fees range from fractions of a cent in the US to well over USD 0.30 in some markets. Then add support load, fraud exposure, and the infrastructure around delivery and verification.

Passkey logins do not carry a per-authentication messaging fee. So the more traffic you have, and the more countries you operate in, the more the cost gap widens.

A fair comparison looks like this:

Axis	SMS OTP	Passkeys
User steps	Wait, read, switch, type	Confirm on device
Marginal auth cost	Per-message fee, plus retries	No messaging fee
Failure pattern	Delivery and transcription issues	Device / platform support issues
Security model	Human-readable code	Domain-bound cryptographic credential

This is also why login funnel analytics matter. If SMS needs retries to produce one completed login, the real cost is not the headline message price.

Security is where the gap is clearest

Phishing-resistant authentication is the strongest technical argument for passkeys.

A passkey is bound to the exact domain. There is no shared secret to steal, copy, or replay on a phishing site. SMS OTP is the opposite: a human-readable code that can be phished, intercepted, or abused via SIM-swap attacks and malware.

So on passkeys security vs SMS, the difference is not subtle. SMS may still be useful operationally, but it remains a weak factor against modern phishing.

That matters even more in regulated environments. The article points out that markets like the UAE are already phasing out SMS OTP for banking.

The right rollout is not “replace SMS overnight”

The common mistake is the migration trap: a team sees the conversion, cost, and security upside of passkeys and decides to rip out SMS immediately. That usually backfires because some users still depend on SMS for first contact, older devices, or non-ideal app/browser environments.

The better SMS OTP fallback strategy is:

make passkeys the primary option
keep SMS OTP as an explicit fallback
segment by OS, browser, and device class
track method switches and cost per successful login
shrink SMS only when the remaining users have a clean alternative

This is where authentication observability becomes essential. Most stacks only record “logged in” or “did not log in.” That is not enough. You need per-method funnel visibility from method chosen to session_established, plus segmentation by environment.

Without that, you are guessing. With it, you can make decisions like: passkeys outperform SMS on iPhone Safari, but SMS still covers a legacy Android segment we cannot strand yet.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

Read the full breakdown.

Choosing a CIAM in 2026: Passkey Adoption, MCP Support and TCO at 500k MAU

vdelitz — Thu, 11 Jun 2026 08:02:46 +0000

Why CIAM selection changed in 2026

The 2026 CIAM market looks different from even a year ago. The shift is not just about adding passkeys or checking an OAuth box anymore. For large-scale B2C deployments, especially around 500k monthly active users, the real decision is about three things at once: passwordless execution, AI agent identity, and total cost of ownership.

A recent market evaluation compared CIAM platforms including Auth0, Clerk, Descope, Ory, Ping Identity, IBM Verify, Stytch, Zitadel, Amazon Cognito, FusionAuth, Firebase, and Supabase at that scale. The headline is simple: most platforms now expose WebAuthn or passkey APIs, but that alone does not produce strong outcomes.

That gap matters because web passkey readiness is already around 89% of completed logins in 2026. Readiness is no longer the bottleneck. Adoption is.

The passkey problem is not API availability

This is the part many teams still underestimate. Enabling passkeys in a CIAM dashboard is not the same thing as driving passkey usage.

The comparison shows that generic CIAM implementations often stall at 5-10% passkey adoption. At 500k MAU, that still leaves roughly 450k users relying on passwords or SMS OTP. So the question for the best CIAM platform for B2C is no longer “does it support WebAuthn?” but “can it actually move users onto passkeys?”

The market data breaks passkey rollouts into distinct outcomes:

settings-only availability: roughly 5% passkey login rate
simple post-login nudge: about 23% in better cases
passkey-first return flow with automatic creation and recovery: 60%+

The important technical takeaway is that the CIAM backend is rarely the thing causing that spread. Prompt timing, device classification, recovery design, and return-user flows are what move passkeys WebAuthn adoption.

Vendor tradeoffs at 500k MAU

If you are comparing CIAM solutions 2026, the tradeoffs are pretty clear once you separate base platform features from orchestration quality.

Vendor	Passkey position	Estimated pricing at 500k MAU	Main tradeoff
Auth0	Universal Login + API/SDK	$15k-30k/mo	Mature and extensible, but expensive and no adoption tooling
Clerk	Toggle in pre-built components	~$9k/mo	Excellent DX, but React-centric
Descope	Visual passwordless workflows	Custom	Strong orchestration and A/B testing, but less flexible with own frontend
Amazon Cognito	Passkeys in Managed Login v2	~$7.3k-10k/mo	Good AWS scale, but hidden engineering overhead
Stytch	WebAuthn API/SDK	~$4.9k/mo	Strong fraud tooling, but more implementation work
Firebase / Supabase	No native passkeys	~$2.1k/mo / $599/mo	Cheap, but not suitable for enterprise passwordless CIAM

A useful example is Amazon Cognito passkeys Managed Login v2. Native support exists, but only on the Essentials tier and above. That makes the base price look reasonable, yet teams still absorb substantial engineering cost if they need custom UI or better passkey adoption flows.

AI agent identity is now part of CIAM

The second big change is that CIAM is no longer only about humans. AI agents are now participating in workflows, calling APIs, and acting through MCP-based patterns.

That is why AI agent identity MCP and Model Context Protocol OAuth 2.1 support are becoming real buying criteria. The evaluation notes that 95% of organizations cite identity concerns around AI agents.

For technical buyers, that means looking for support around:

OAuth 2.1
PKCE
tool-level scopes
machine and agent identity controls
MCP-compatible authorization models

Descope, Clerk, Stytch, Ping, and IBM are all discussed through that lens, but not equally mature. If your roadmap includes agent access to tools or services, this is no longer optional future-proofing.

TCO is bigger than license cost

A lot of CIAM evaluations still stop at monthly pricing. That is a mistake.

The comparison estimates that building passkeys natively on top of any CIAM platform typically requires 25-30 FTE-months across product, engineering, and QA, plus about 1.5 FTE per year for maintenance. That changes how you should think about CIAM total cost of ownership 500k MAU.

Even platforms with lower sticker prices can become expensive if they require:

custom passkey UX
cross-platform retesting
recovery flow design
frontend maintenance
support and analytics work

This is also why the Auth0 vs Clerk vs Descope passkeys debate is not just about feature checklists. Auth0 is extensible but expensive. Clerk is fast for modern frontend teams but narrower in ecosystem fit. Descope is strong on orchestration, especially for passwordless journeys, but comes with different frontend tradeoffs.

Corbado is a passkey observability and adoption platform for large B2C enterprises.

The interesting conclusion from the market review is that many enterprises should not replace their CIAM at all. They should optimize what sits on top of it: passkey orchestration and analytics.

Read the full breakdown.

Authentication Process Mining in CIAM

vdelitz — Mon, 01 Jun 2026 13:28:08 +0000

Why passkeys exposed a CIAM blind spot

Authentication process mining is the idea of applying process-mining techniques to login journeys, using per-session event logs to reconstruct what users actually did instead of what the auth flow was supposed to do.

That matters now because passkeys moved critical parts of authentication to the client. Traditional IDP logs can tell you attempt, success, and failure. They usually cannot tell you whether Conditional UI fired, whether the browser showed a biometric prompt, which credential manager was selected, or whether the user silently abandoned before any assertion hit the backend.

This is why many teams think their rollout is healthy when it is not. A 92% aggregate success rate can still hide a 40% abandonment rate on the passkey path alone. Averaged metrics flatten the journey. Process mining rebuilds it.

Authentication observability is the prerequisite

A lot of teams want passkey analytics, but they still lack the event model required to make it real. Authentication process mining only works after you have client-side observability in place.

At minimum, the event model needs to capture:

initiation type: text-field, one-tap, or Conditional UI
client-side ceremony events: page load, prompt display, biometric interaction, assertion return
richer outcomes than success/failure: explicit abort, implicit abort, no-start, not-loaded, suppressed flows
environment data: OS, browser, device brand, app, authenticator, transport
credential inventory context: Apple, Google Password Manager, iCloud Keychain, Windows Hello, security keys, and others

Without that, you do not have process-mining event logs. You have outcome counters.

The practical shift is important: authentication observability asks “what happened?” Authentication process mining asks “which path did this session take, where did it diverge, and what should we change next?”

The designed login journey is rarely the lived one

The most useful insight in the article is not theoretical. In observed deployments, only about 30% of eligible users follow the designed passkey happy path.

That means the majority of sessions drift somewhere else: password fallback, social login, magic links, dismissals, retries, or silent exits. Once you reconstruct the per-session graph, you can rank those variants instead of guessing.

A simple comparison looks like this:

View	What it tells you	What it misses
IDP outcome logs	success/failure by method	pre-assertion friction, abandonment cause, UI behavior
Passkey analytics dashboard	adoption and conversion trends	exact deviation paths per session
Authentication process mining	lived journey variants and deviation frequency	requires front-end instrumentation first

Another useful pattern: the top five deviation variants typically account for 85% of all deviations. That is why fixing two broken variants often moves passkey adoption more than another A/B test on the happy path.

Why this changes step-up authentication

This gets more interesting when you connect login journey analytics to risk.

A lot of step-up authentication still works like a blunt threshold rule: if transaction value is high, trigger OTP. The article frames the tradeoff clearly: teams often add friction to 95% of legitimate traffic to catch the 5% that looks suspicious.

With authentication process mining, the decision can become session-specific instead of rule-only. Signals can include:

deviation from the user’s normal path
cohort baseline success rate
time-of-day anomalies
device reputation
IP reputation
credential manager identity

That is the bridge from CIAM observability to step-up authentication risk scoring. You stop treating every high-value action the same and start using the session’s actual path as a risk input.

Why IDPs are unlikely to solve this natively

The article makes a useful distinction: IDPs own the control plane, while authentication process mining is a data-plane problem.

That sounds subtle, but it has real architectural consequences. Orchestration products in Okta, Ping, ForgeRock, and Auth0 are good at defining policy and journey logic. They are not built to normalize high-cardinality front-end telemetry across browsers, operating systems, authenticators, and credential managers.

That is why terms like cohort drift detection, credential manager selection, and variant analysis are becoming first-class concerns for CIAM teams. Browser updates and OS rollouts change behavior silently. Aggregate success rate often catches that too late.

The near-term takeaway is simple: if you care about passkey rollout KPIs, start by measuring happy-path share and the top deviation variants on the passkey path. That is usually where the real leverage is.

Read the full breakdown](https://www.corbado.com/blog/authentication-process-mining).