DEV Community: vdelitz

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).

Why Passwordless B2C Rollouts Stall at 5% (and How to Reach 60%)

vdelitz — Thu, 21 May 2026 11:09:04 +0000

Passwordless for B2C at scale sounds straightforward in 2026 because every major CIAM now exposes WebAuthn APIs and markets passkeys as a standard feature. But the guide I’m referencing here looked specifically at 500k+ MAU deployments and makes a less comfortable point: enabling passkeys is not the same as driving passkey adoption.

That gap shows up fast in production. Teams launch passkeys, but daily logins still run through passwords or SMS OTP. According to the guide, CIAM-native passwordless rollouts usually stall at a 5–10% passkey login rate. The structural reason is simple: the CIAM can store credentials and run policy, but it usually does not control the prompt logic, device segmentation, recovery design, or client-side telemetry needed to move users into passkey-first behavior.

This is the passkey adoption fallacy in practice. “Our platform supports passkeys” is a feature statement. “We reached 60%+ passkey login rate” is an orchestration outcome.

The passkey adoption ladder matters more than the vendor

One of the most useful ideas in the guide is the passkey adoption ladder. It reframes rollout maturity as a journey design problem, not a platform selection problem.

Here’s the progression described for 500k MAU B2C environments:

Rollout shape	Enrollment	Usage	Passkey login rate
Settings-only availability	~4%	~5%	<1%
Simple post-login nudge	~25%	~20%	~4–5%
Optimized enrollment	~65%	~40%	~23%
Passkey-first return flow	~80%	~95%	>60%

What changes across these stages is not the underlying Auth0, Cognito, Ping, or Clerk tenant. What changes is the login-entry experience sitting on top: device-aware prompting, conditional create passkeys, one-tap return flows, and identifier-first recovery.

That’s also why large enterprises often need a WebAuthn orchestration layer. Without it, the rollout gets trapped at baseline because the native UI is too flat for the real device landscape.

Device fragmentation is the real implementation constraint

The guide is strongest where it stops talking about “passkeys” as one feature and starts talking about ecosystems. First-try web passkey enrollment is not uniform. The benchmark cited in the piece shows 49–83% on iOS and just 25–39% on Windows.

That spread has direct product implications:

iOS is generally the best environment for automatic and low-friction enrollment.
Android is workable but fragmented by browser and credential provider behavior.
macOS is viable in many cases, but not as predictable as iOS.
Windows needs more careful fallback and often cross-device handling.

This is where conditional create passkeys and identifier-first recovery become operationally important. If you prompt the wrong user on the wrong stack, you create dead-end ceremonies and your backend logs won’t even tell you why.

Authentication observability is the missing layer

A lot of teams assume IDP logs are enough to measure passwordless authentication CIAM success. The guide argues the opposite. The most expensive failures often happen before the backend sees anything meaningful.

That’s the “pre-identifier blindness” problem: users are still anonymous when browser overlays fail, autofill gets blocked, or a passkey prompt is confusing enough that they abandon the flow. Standard CIAM logs, APM traces, and SIEM data are not designed to capture that client-side ceremony.

The observability section gives a concrete example. Server-side passkey success can look nearly perfect, while user-facing completion is lower, and first-suggestion interaction is where the biggest drop-off happens. If you only inspect backend metrics, your passkey rollout KPIs look healthier than the actual user journey.

For technical teams, that changes rollout order. Instrument first, then optimize. Corbado is a passkey observability and adoption platform for large B2C enterprises.

Buy vs. build starts with TCO, not licensing

The guide’s TCO point is blunt and useful: licensing is not the main cost driver. Building passwordless natively into a CIAM stack at 500k MAU is estimated at 25–30 FTE-months, plus roughly 1.5 FTE per year for ongoing maintenance.

That effort covers more than API integration. It includes frontend control, device classification, recovery logic, testing across OS/browser changes, and support for fallback paths that do not collapse back to passwords.

The practical takeaway is that passwordless at scale is mostly an orchestration and observability problem. If your rollout is stuck at baseline, the highest-ROI move is usually to measure where users drop, segment by device stack, and fix the flow on top of your existing CIAM rather than replace it.

Read the full breakdown.

The Digital Identity Gap Needs Better Telemetry

vdelitz — Fri, 15 May 2026 07:58:01 +0000

The hidden denominator problem

Digitization is a board-level KPI in banking, healthcare, insurance, and other regulated sectors, but most dashboards still measure only the people who already made it into digital channels. That creates a blind spot: the digital identity gap.

In the source article, that gap means customers who exist on file but never activated or used an online login. The scale is not small. FDIC data says about one third of banked households did not use online banking in 2023. In healthcare, HINTS/JMIR 2025 reports 38.7% of US adults did not access a patient portal in the last 12 months.

This matters because a nice-looking adoption chart can still hide a 10–40% segment that never signed up, never came back, or keeps failing before the backend sees anything.

Why backend login metrics miss the real problem

The most uncomfortable point in the article is simple: over 80% of sign-up and login failures happen client-side and never reach the backend IdP.

That means your server logs can report a healthy success rate while users are dropping off because of:

missing email verification
SMS OTP delivery issues
browser or OS-specific WebAuthn problems
timed-out prompts
blocked popups
password managers fighting the form

For identity teams, this is the difference between seeing request outcomes and seeing the actual user journey. If your telemetry starts at the API boundary, you are blind to most of the funnel.

Not every failure is the same failure

One of the better distinctions in the article is that teams often collapse three different problems into one “adoption” metric:

Problem type	What it looks like	What usually fixes it
Conversion problem	User logs in with SMS OTP but never upgrades to passkey	Better upgrade prompts, timing, messaging
Funnel problem	User starts sign-up and drops at step three	Better onboarding UX, recovery, delivery reliability
Identity problem	Customer has no online profile at all	Assisted enrollment, supervised onboarding

If those are mixed together, roadmap decisions get distorted. A passkey adoption campaign will not help the customer who never completed sign-up. A better signup form will not help the user who refuses biometric binding and needs a hardware key or PIN-unlocked device credential.

The metrics that actually expose the gap

The article argues for authentication telemetry as a client-plus-server event layer that captures every sign-up and login step, including failures that never hit the backend. That is what makes the gap measurable.

A practical starter set of metrics includes:

Sign-up completion rate by device and browser
Login success rate (LSR)
Authentication error rate (AER) by reason code
Authentication drop-off rate
Reach rate by cohort, measured against the full customer base
Time-to-first-authenticated-action

The key idea is segmentation. An overall sign-up completion rate may look fine, while one browser version or one branch-acquired cohort is failing badly. The article even notes that once enterprises instrument client-side events, reported success rates often turn out to overstate reality by 10–25 percentage points.

Why this is becoming a product-reach issue

This is not only about support costs or password resets. The article connects the digital identity gap to agentic AI digital identity and authentication, embedded finance, shrinking branch footprints, and self-service regulation such as PSD3 and eIDAS 2.0.

Those models assume the customer can authenticate digitally. If they cannot sign up, cannot recover, or cannot use a smartphone in their work context, they are unreachable by the product itself.

That is why the remediation is broader than passkey rollout alone. The article recommends:

instrument the login funnel first
fix client-side failure causes before optimizing backend success rates
match credentials to segment, not ideology
use supervised onboarding and cross-device credential provisioning for customers who cannot complete enrollment alone

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

The big takeaway: if your denominator starts with “active users,” your digitization KPI is already biased. Read the full breakdown.

Why the FBI Is Pushing Device-Bound Passkeys

vdelitz — Tue, 12 May 2026 08:13:07 +0000

The FBI finally said the quiet part out loud

Operation Winter SHIELD matters because the FBI is no longer talking about authentication as a generic “use MFA” problem. It explicitly tells organizations to adopt phishing-resistant authentication, prioritize high-impact accounts, and deploy FIDO2-compliant security keys or device-bound passkeys for authentication, remote access, and critical systems.

That is a different message from the older “turn on MFA everywhere” playbook. The same guidance also says to eliminate SMS-based MFA and disable legacy authentication. That is the real shift.

Microsoft added useful context around the attack pressure behind this move: 7,000 password attacks per second in 2024, with 97% of identity attacks involving password spray or brute force. If your login stack still depends on passwords plus phishable backup factors, attackers already know where to aim.

Why “MFA” is no longer a useful endpoint

A lot of teams still treat MFA as the finish line. It is not.

SMS codes, OTP apps, and push approvals all improve things compared to passwords alone, but they are still vulnerable to phishing and real-time relay attacks. Winter SHIELD reflects that reality. The FBI guidance is not asking for one more factor. It is asking for a factor that is structurally harder to phish.

That aligns with broader U.S. guidance:

CISA calls phishing-resistant MFA the gold standard
FIDO/WebAuthn is the only widely available phishing-resistant authentication model CISA points to
NIST says properly implemented syncable authenticators can be phishing-resistant and support AAL2

This is why passkeys matter in 2026. They improve both security and usability. The source article cites Microsoft data showing passkey sign-ins succeed about 98% of the time, versus 32% for passwords.

Why the FBI specifically mentions device-bound passkeys

This is the nuance many teams will miss.

A device-bound passkey stays on one physical device and does not sync through a cloud keychain. A synced passkey, by contrast, is available across devices connected to platforms like iCloud Keychain or Google Password Manager.

The FBI’s wording makes sense because Winter SHIELD focuses on administrators, executives, remote access, and critical systems. In those environments, assurance and administrative control often matter more than portability.

Here is the practical tradeoff:

Model	Best fit	Main advantage	Main tradeoff
Device-bound passkeys	Workforce IAM, privileged access, critical systems	Stronger device control and cleaner trust boundaries	Less flexible recovery and cross-device use
Synced passkeys	CIAM, broad employee adoption, public-facing login	Better portability, recovery, and adoption	Less tightly bound to a managed enterprise device

This does not mean synced passkeys are weak. It means the assurance model should match the use case.

What rollout teams should do next

If you read Winter SHIELD as an implementation guide, the sequencing is pretty clear:

Inventory phishable auth paths, especially SMS MFA, push-only approvals, and legacy protocols
Rank accounts by impact, not by organizational chart
Move admins, remote access users, executives, and critical operators first
Use device-bound passkeys or FIDO2 security keys where device governance is essential
Use synced passkeys where recovery and multi-device access are required
Remove fallback paths, or the strongest method will be bypassed by the weakest one

That last point is easy to underestimate. A passkey rollout does not buy much if legacy auth or SMS remains the convenient recovery path.

For workforce IAM, Winter SHIELD is really about shrinking escape hatches. For CIAM, the takeaway is different: design toward phishing-resistant login as the long-term baseline, but do not force high-assurance enterprise assumptions onto mass-market customer journeys.

Read the full breakdown.

3 Things Teams Still Underestimate When Rolling Out Passkeys

vdelitz — Thu, 07 May 2026 07:17:38 +0000

For World Passkey Day, we published the Passkey Benchmark 2026 to look at what passkey adoption actually looks like in real deployments.

One thing became clear very quickly: shipping passkeys is only one part of the problem.

What teams often underestimate is everything around adoption, fallback, and operational visibility.

Here are three recurring patterns from the benchmark.

1. Readiness is not the main bottleneck anymore

Mobile passkey readiness is already at 97–99%.

That means many teams are no longer blocked by platform support. The bigger challenge is converting ready users into actual passkey users.

2. Enrollment is highly sensitive to rollout quality

Passkey enrollment can reach up to 83% when the prompt and flow are designed well.

This is an important reminder that implementation quality matters. Prompt timing, UX clarity, and recovery setup directly affect passkey creation.

3. Conditional UI is the most underused UX lever

When passkeys surface directly in the login field (Conditional UI), desktop logins complete 94% of the time.

Most teams still trigger passkeys via a button or modal — moving them into the input field changes the outcome dramatically.

If you are building or rolling out passkeys, these are the areas worth paying close attention to.

Full benchmark: Passkey Benchmark 2026

Why Hardware-Bound Passkeys Still Struggle

vdelitz — Wed, 06 May 2026 13:06:48 +0000

Hardware-bound passkeys offer AAL3 assurance, but synced passkeys dominate consumer adoption. Here’s why distribution and UX matter more.

Hardware-bound passkeys have a market problem, not a crypto problem

Hardware-bound passkeys are the strongest consumer passkey model on paper. The private key stays inside a physical secure element, which is why they can reach NIST AAL3, while synced passkeys are capped at AAL2.

But consumer adoption tells a different story.

The FIDO Alliance Authentication Barometer 2024 shows that hardware-bound passkey activation in consumer banking is still below 5 percent in 2025. That is the core tension: the highest-assurance option exists, standards are mature, and yet almost nobody uses it at scale in consumer apps.

The reason is not weak hardware. It is distribution and default UX.

Apple and Google control over 99 percent of mobile share, and they decide which passkey option users see first. Synced passkeys get the prime placement through iCloud Keychain and Google Password Manager. A hardware authenticator usually sits one to three clicks deeper. Once that prompt hierarchy is set, even strong FIDO2 security keys or FIDO2 smart cards start the race from behind.

The real split: storage policy changes the whole deployment model

At the protocol level, synced and hardware-bound credentials are both WebAuthn credentials. The difference is where the private key lives and whether it can be recovered from the cloud.

Type	Key storage	Recovery	Assurance
Synced passkeys	Cloud-synced manager like iCloud Keychain or Google Password Manager	Easy across devices	AAL2
Hardware-bound passkeys	Physical secure element on a security key, smart card, or TPM	Harder, often manual	AAL3

That storage-policy difference drives everything downstream:

Regulatory fit: hardware-bound credentials align better with stricter possession-factor requirements such as PSD2 and PSD3 interpretations.
Recovery burden: synced passkeys recover smoothly, while hardware loss can push users into risky fallback flows.
Consumer behavior: most users choose the default option that appears in the autofill flow.

This is why WebAuthn Conditional UI matters so much. It favors the credential manager already integrated into the platform. Hardware is technically supported, but rarely promoted.

Security keys and smart cards face different bottlenecks

The consumer race is mostly a contest between two hardware forms:

FIDO2 security keys, usually sold directly to users
FIDO2 smart cards, often distributed by banks or issuers

Each has a clear weakness.

Security keys are expensive for broad consumer rollout. A typical device costs 40 to 80 USD, which works in enterprise settings but not for mainstream consumer login.

Smart cards solve distribution better because banks already issue physical cards. They can also fit regulated journeys like transaction confirmation and account recovery. But they depend heavily on NFC passkey authentication, and that is where deployment gets messy. Android NFC behavior varies across manufacturers, and a tap flow that works on one device may fail on another.

So the market is not blocked by cryptography. It is blocked by prompt design, NFC fragmentation, recovery design, and support economics.

The winner will combine hardware with observability and routing

This is why passkey adoption engineering matters more than many teams expect.

A hardware vendor can ship excellent silicon and still lose if it cannot answer basic deployment questions:

Did the user ever see the hardware option?
Did they abandon at the NFC tap?
Did the browser suppress the preferred path?
Did the relying party trigger unnecessary recovery?
That is an observability problem.

The article’s strongest takeaway is simple: hardware alone will not win consumer authentication. The winner will pair hardware with passkey observability, device-aware routing, and continuous iteration across broken browser and OS combinations.

In other words, the best product is not necessarily the strongest authenticator. It is the one that can get users through the full ceremony reliably.

Banks have a real opening here because they already control card distribution and operate under stronger regulatory pressure. Hardware vendors also have a path, but only if they move beyond device sales into software, onboarding, recovery, and measurement.

If you are evaluating device-bound passkeys for consumer use, the practical question is no longer “Is the hardware secure enough?” It is “Can we make this usable, measurable, and recoverable at scale?”

Find out more in the full breakdown