DEV Community: vdelitz

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

The hidden blocker in regulated digitization

vdelitz — Tue, 28 Apr 2026 11:03:13 +0000

Reported adoption often starts too late in the funnel and misses the customers who never become digitally reachable.

Most regulated enterprises are measuring digitization wrong. Not because the numbers are false, but because the denominator is off.

Adoption dashboards typically start with customers who already made it into digital channels at least once. That sounds reasonable until you realize how many people it excludes: customers who exist on file, pay for products, interact with the business, but never activated an online login. In US banking, about one in three banked households did not use online banking in 2023. In healthcare, 38.7% of US adults never accessed a patient portal in the last 12 months.

If your dashboard starts at "active digital users," those people vanish from the metric entirely.

Why this is not just a UX problem

The tempting diagnosis is friction. Make the app easier and people will come. But the gap runs deeper than that.

Every customer who cannot sign up or log in digitally becomes more expensive to serve over time. They sit outside the reach of agentic AI, embedded finance, self-service support, and digital cross-sell. In regulated environments this compounds fast because onboarding and authentication are already more complex than in consumer apps. Extra verification steps, recovery flows, and step-up requirements create more places to fail.

The harder problem is that non-adoption is not one thing. Someone who abandons sign-up halfway through is a funnel problem. Someone who uses SMS OTP but never upgrades is a conversion problem. Someone with no digital profile at all is an identity problem. Treating all three as one adoption number leads to the wrong roadmap.

Why backend logs miss the real failure rate

Here is where most teams get surprised: over 80% of sign-up and login failures happen client-side and never reach the backend IdP at all.

That means backend success rates can look healthy while real users are dropping off on specific browsers, device types, or operating systems. The IdP sees a clean log because it only receives the requests that made it through. The failures stay invisible.

This is why authentication telemetry across client and server matters. Without it, teams redesign aggregate flows while the actual failures stay concentrated in one browser family, one device segment, or one acquisition channel nobody was watching.

What to measure instead

The metrics that connect authentication performance to business outcomes:

Sign-up completion rate by cohort segmented by device and browser
Login Success Rate (LSR) across the full authenticated surface
Authentication Error Rate (AER) broken down by reason code
Reach rate calculated against the full customer base, not just active users
Time-to-first-authenticated-action as an onboarding health signal

These are not vanity metrics. Failed logins correlate directly with churn, support volume, and abandoned-session revenue loss.

One credential type will not fix this

Mobile-first customers may respond well to passkeys. Field workers often need options that do not depend on a personal smartphone. Privacy-averse users tend to prefer hardware keys or PIN-unlocked credentials over biometric binding. Some customers will still need supervised onboarding through channels they already trust, like a branch or call center.

The goal is not to pick the best authentication method. It is to maximize successful logins across the full customer base.

The key takeaway

The biggest blocker in regulated digitization is often not low engagement inside digital channels. It is the unseen population that never becomes digitally reachable in the first place.

Honest adoption numbers and a realistic path to closing the gap both start with the same thing: telemetry that captures the full authentication journey, not just the backend slice that already succeeded.

Find out more at corbado.com/blog/digital-identity-gap

Brave Passkeys: Clean WebAuthn, Messy UX

vdelitz — Wed, 15 Apr 2026 16:43:21 +0000

Brave's passkey story in 2026 is a good example of why standards compliance does not automatically produce a clean user experience.

At the implementation level, Brave is almost entirely upstream Chromium for WebAuthn. The code path is essentially untouched, with only one visible customization: a string change from Chrome's "Incognito" to Brave's "Private" in the passkey save dialog. No C++ patches alter the WebAuthn flow itself.

That matters because it explains why Brave usually behaves like Chromium, but also why many reported problems sit outside the core WebAuthn implementation.

The practical takeaway for developers: do not assume Chrome parity just because Brave shares Chromium. The biggest failures are not about attestation formats or RP configuration. They show up in surrounding layers:

OS integration
Extension prompts
Platform services

Where Brave actually breaks

As of April 2026, there are 24 open Brave issues matching passkey or WebAuthn searches. The problems are not random. They cluster around three themes.

1. Android on de-Googled devices

The sharpest issue is dependency on Google Play Services. Issue #45415 documents that on GrapheneOS, CalyxOS, /e/OS, and similar setups, passkey registration and authentication can:

Time out completely
Fail to open the dialog at all

Chromium can use Android's Credential Manager on newer versions, but that does not eliminate the failure mode across all devices and configurations.

Key lesson: "Android support" is too broad a test label. If your users include privacy-focused Android distributions, Brave needs separate validation.

2. Windows Hello prompts

Issue #51858 shows a different boundary problem. Disabling Brave's own passkey-saving settings does not stop Windows Hello from being offered as a WebAuthn platform authenticator. That is because:

The site talks to WebAuthn
The OS advertises Hello directly
Brave's settings do not control that OS-level offer

Key lesson: If your product team expects a browser toggle to suppress Windows Hello, that expectation is wrong in Brave today.

3. Extension interception

Issue #37762 tracks the native passkey UI overriding Bitwarden and 1Password prompts. This has been active since April 2024, and a previous workaround using the web-authentication-new-passkey-ui flag disappeared in Chromium 146.

Storage choice is the real product decision

Passkey reliability in Brave depends less on browser branding and more on where the credential lives. Brave does not provide Chrome-style browser-profile passkey sync through Google Password Manager. Instead, it delegates to the platform authenticator or to third-party extension flows.

That creates a clear storage tradeoff:

Storage option	Portability	Limitation
iCloud Keychain	Works across Safari, Chrome, Brave on Apple devices	Tied to Apple ID
Windows Hello	Clean on one device	Effectively device-bound
Password manager extensions (Bitwarden, 1Password)	Only broadly workable cross-platform sync	Most unstable in Brave (see below)
Cross-device auth (CDA)	QR code + Bluetooth from another device	Not a sync strategy

macOS nuance: A passkey created in Brave can be used in Safari on another Apple device only if it was saved into iCloud Keychain. A browser-local credential does not magically become cross-browser portable.

The extension problem is the most important regression

If you support users across Windows, macOS, Linux, and Android, extension-based vaults are still the most practical answer. But this is also where Brave is most unstable.

If your login relies on extension-owned passkeys, don't just test whether WebAuthn succeeds. Test:

Prompt ownership — does the right dialog appear?
Fallback behavior — what happens when it doesn't?
Recovery UX — what does the user see when the browser routes them into the OS dialog instead of the extension they expected?

For high-value accounts: keep a hardware security key as fallback. In Brave today, that is not just a security recommendation. It is an operational safety net.

Read the full breakdown here: https://www.corbado.com/blog/passkeys-brave-browser

Why you need Authentication Observability for CIAM

vdelitz — Thu, 09 Apr 2026 14:58:07 +0000

Passkeys tend to look "done" when you can complete a WebAuthn ceremony and your IdP logs show green checkmarks. In CIAM, that's a trap. The FIDO Alliance Passkey Index (2025) reports passkey sign-ins achieve a 93% success rate vs. 63% for passwords and SMS OTP, yet many real-world rollouts still see a passkey adoption rate stuck around 5% to 15%. The gap is usually not your backend. It's the user's device, browser, OS UI, and credential manager.

What "Authentication Observability for CIAM" actually means

Authentication Observability for CIAM is about seeing the full consumer login journey, including everything that happens on the client before your server receives a request. That matters because over 80% of passkey failures can happen on the consumer's device before any request reaches the backend, so IdP logs literally cannot explain them.

Client-side WebAuthn telemetry should capture more than "success" or "error." You want to know:

How the ceremony started (Conditional UI autofill, a passkey button, or manual identifier entry)
Whether the device was even capable
Which credential manager took over (iCloud Keychain, Google Password Manager, Windows Hello, Samsung Pass, browser extension)
What happened at biometrics (success, timeout, cancel)
Which specific WebAuthn error code ended the attempt

The CIAM-specific blind spot: pre-identifier abandonment

Workforce IAM assumes the user exists before login. CIAM does not. If a consumer lands on your login page, gets confused by a native prompt, or an extension overlays the UI, then bounces before typing an email, your backend has nothing. That "pre-identifier blindness" is where funnel leakage hides.

This is why passkey analytics cannot start at /token or /authorize. It has to start at page load or app screen render, with a silent capability probe that determines whether passkeys and Conditional UI are available before you show any UI. Without that, you can't tell the difference between "users don't want passkeys" and "eligible users never saw a usable passkey entry point."

The KPIs that matter: activation and usage (not just success)

A passkey dashboard that only tracks Login Success Rate (LSR) misses the point. You need two adoption KPIs that map to behavior change.

Passkey activation rate is the share of eligible users (devices that support passkeys) who actually create one when prompted. In practice, you can't compute this reliably from backend logs or generic product analytics because those tools don't know eligibility. Client-side probes make eligibility measurable, so activation becomes a real denominator, not a guess.

Passkey usage rate is the share of daily logins that happen with passkeys, not just "has a passkey." Lots of users enroll once and still type passwords out of habit, or because autofill is buried, or because Conditional UI doesn't render due to CSS or custom inputs.

Why GA4 and generic analytics break on passkey debugging

You can push custom events into GA4 or Mixpanel, but passkey performance depends on high-cardinality combinations: OS version, browser version, credential manager, device model, authenticator type, and cross-device login method. GA4 high-cardinality passkey data quickly collapses into (other) once you exceed the platform's practical limits, which is exactly where the long tail of passkey bugs lives.

Also, the most important states are native WebAuthn and credential-manager states that generic analytics does not model:

Whether Conditional UI tracking fired but wasn't selected
Whether a user attempted Cross-Device Authentication (QR + Bluetooth)
Whether the platform authenticator was detected
Whether the request got intercepted by an extension

WebAuthn error code diagnostics that lead to actions

If you only store "NotAllowedError happened," you still need interpretation. In production, WebAuthn error code diagnostics should map to a concrete response:

NotAllowedError — Often user cancel or timeout. Treat spikes as a UX messaging and retry problem, not a server outage.
NotSupportedError — A capability or environment issue. Suppress passkey UI and route to a fallback.
SecurityError — Often points to HTTPS, RP ID, or domain configuration issues that require immediate investigation.
UnknownError — Can indicate credential-manager crashes or extension interference. Segmenting by browser + extension presence becomes critical.

The key developer takeaway: error codes become valuable only when they are enriched with client context and segmented into cohorts. Otherwise you'll waste weeks debating whether you have a "passkey problem" or a "Samsung Pass on a specific Galaxy + One UI version" problem.

Conditional UI is a silent failure point (and you need telemetry for it)

Conditional UI often runs invisibly in the background. If the user doesn't select the passkey from the autofill dropdown, your backend never learns that Conditional UI was invoked. That means you can have "passkeys are supported" and "Conditional UI is firing" while usage stays low because the dropdown is suppressed by styling, rendered below the fold, or visually crowded by password manager overlays.

Instrumentation should record invocation and selection separately. If invocation is high and selection is low, the fix is almost always UI, layout, or input styling — not cryptography.

Rollout safety: a CIAM passkey kill switch is not optional

CIAM environments include unmanaged devices, old OS builds, regional Android OEM skins, and multiple password managers. So you need a CIAM passkey rollout kill switch that can suppress passkey prompts for known-bad device and OS cohorts and route users to a stable fallback before they hit a broken native modal.

This is not about giving up on passkeys. It's about protecting conversion and support costs while you isolate systemic breakage. The same telemetry that identifies broken cohorts also identifies high-confidence cohorts (for example, a specific macOS + Safari segment) where you can be more aggressive with prompting.

Nudging based on cohorts, not gut feeling

Once you can segment by device capability and actual funnel behavior, you can nudge the right people at the right time. A recurring high-conversion moment is "after pain" — immediately after a password reset, when user motivation is high. Observability lets you prove whether this increases passkey activation rate in your own traffic, and whether the effect holds by cohort.

Likewise, usage rate improvements often come from initiation UX. If users with an existing passkey still type into fields, you likely need a more prominent passkey entry point, better autofill positioning, or better cross-device instructions when QR + Bluetooth completion is dropping.

Build vs. buy: the hidden maintenance cost is taxonomy drift

A lot of teams start by wrapping WebAuthn calls and sending events to an internal pipeline. The hard part is keeping the taxonomy correct across browser releases, OS updates, new WebAuthn error behaviors, and a growing list of credential managers and extensions. You also need to fix issues quickly, ideally via config, not a full frontend deployment cycle.

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

What to take away

If your passkey adoption rate is stuck in single digits, don't assume "users hate passkeys." Measure passkey activation rate and passkey usage rate with client-side WebAuthn telemetry, add Conditional UI tracking, make GA4 high-cardinality limitations explicit in your strategy, and implement a kill switch so broken cohorts don't poison your rollout.

Find out more on corbado.com/blog/authentication-observability

Australia's Payday Super: SMS OTP Cost Crisis 2026

vdelitz — Tue, 31 Mar 2026 07:54:16 +0000

Australia's Payday Super reform (effective 1 July 2026) quietly turns SMS OTP into a line item that scales like a tax. When super contributions move from quarterly to every pay cycle, member engagement shifts with it. If your app nudges members with "your contribution arrived" notifications, logins per member can jump from 4 to 24+ per year. That's the core driver behind the Payday Super SMS OTP costs 2026 problem.

The 1 July 2026 pile up is the real risk

Three deadlines collide on 1 July 2026: Payday Super, SuperStream 3.0 upgrades (including NPP and Member Verification Request MVR), and the ACMA SMS Sender ID Register 1 July 2026. Layer on APRA CPS 230 operational risk management (effective 1 July 2025) and existing APRA CPS 234 MFA requirements, and you get a compliance and cost squeeze at the same time. The practical outcome is that SMS based authentication becomes both more expensive and harder to defend.

The cost model is brutal and has no economies of scale

The article's cost model makes the problem concrete. With SMS OTP priced at 0.05 AUD per message, a mid tier fund with 1 million members sees annual authentication costs surge:

Metric	Pre-Payday Super	Post-Payday Super
Logins per member/year	~4	~24+
Annual SMS OTP cost	$230,000	$1,380,000
Cost increase		~500%

That is a SMS OTP cost increase 500% driven mostly by login frequency. The model also adds a realistic overhead: segment length multipliers and failure charges mean you can pay even when messages do not arrive.

ACMA SMS Sender ID Register changes deliverability and pricing dynamics

From 1 July 2026, branded sender IDs become a governance requirement under the ACMA register. Without verification, messages can land in a generic "Unverified" thread, which undermines trust and increases support calls when members hesitate to enter codes. Carriers are also signaling premium pricing for verified A2P traffic, so even if you optimize message length, per message cost pressure can still rise.

Payday Super drives "bank scale" IAM loads inside super funds

Payday Super makes superannuation feel real time. A fortnightly paid member goes from 4 contribution events per year to 26, and each event can trigger a login. At fund scale, that turns Australian super funds authentication into a high volume system:

Fund Size	Auth Events (Before)	Auth Events (After)
2-4 million members	8-12 million/year	48-72 million/year

If your primary step up method is per login SMS OTP, your OpEx grows with engagement.

SuperStream 3.0 and NPP reduce fraud response time, not just settlement time

SuperStream 3.0 introduces near instant settlement via the New Payments Platform and introduces the Member Verification Request (MVR) service to pre validate whether a fund will accept a contribution. NPP's speed changes the fraud equation. If an attacker gets into a member account, the window to detect and reverse activity shrinks dramatically compared to batch settlement. This is where APRA CPS 234 MFA requirements become operationally sharp, not theoretical.

Why SMS OTP is increasingly hard to justify for security

SMS OTP concentrates risk in the telecommunications layer. The post calls out SIM swapping, reverse proxy phishing (MitM toolkits like Evilginx), and OTP flooding as practical bypass routes. Even if your password hygiene improves, SMS can become the weak link, and under CPS 230 operational risk management you still have to treat that dependency as a material operational exposure.

Passkeys remove the marginal cost problem entirely

FIDO2 passkeys for superannuation fix the "variable cost per login" issue. Once a member is enrolled, each additional authentication is effectively zero marginal cost, which decouples security spend from Payday Super driven engagement. They also provide phishing resistance because WebAuthn binds the credential to the relying party origin, so a lookalike domain cannot successfully trigger the same authentication.

Corbado published data showing that passkeys achieve 93% login success vs 63% for passwords, which matters in super portals where failed logins turn into helpdesk volume and member churn.

UniSuper passkeys implementation is the local proof point

UniSuper is cited as an early mover rolling out passkeys on its member web portal. The useful takeaway is not "passkeys are possible", it's that members will actually enroll when the UX is positioned as a convenience upgrade and integrated into normal flows, rather than treated as an optional security setting buried in menus.

A practical migration pattern: shadow enrollment to OTP eradication

The article's recommended passkey migration strategy shadow enrollment friction engineering OTP eradication is structured like an adoption funnel rather than a big bang cutover. Shadow enrollment prompts passkey creation right after a successful legacy login, friction engineering preferentially routes returning users to passkeys (Conditional UI helps), and OTP eradication phases SMS out while keeping a non SMS fallback such as TOTP for edge cases. This aligns better with CPS 230 resilience goals than a sudden change that spikes support and lockouts.

What to do before 1 July 2026

If you own authentication in a super fund, treat 2026 as a deadline for economics, not just compliance. Model your post Payday Super login frequency, then stress test it against SMS pricing, failure rates, and sender ID verification requirements. Then pick an MFA path that scales without per event costs and reduces exposure to telecom based attacks.

Find out more on corbado.com/blog/payday-super-sms-cost

WebAuthn credProtect + security keys: why Chrome works and Safari “does nothing”

vdelitz — Tue, 03 Mar 2026 17:23:00 +0000

The confusing failure: YubiKey registered in Chrome, login fails in Safari

A common FIDO2 security keys interoperability issue: you create a credential in Chrome, everything works, then Safari on the same machine can’t use that “same” YubiKey—often with no PIN prompt and basically no actionable error.

The usual root cause is WebAuthn credProtect (a.k.a. credentialProtectionPolicy, CTAP 2.1). Chrome silently hardens discoverable credentials on roaming keys in ways Safari can’t reliably satisfy.

The trigger combo: discoverable credentials + UV="preferred"

This mainly hits RPs that register/login with:

residentKey: "required" (aka discoverable credentials / resident key)
userVerification: "preferred" (chosen to avoid “hard fail” edge cases at scale)

With that combo, Chromium may escalate the credential to credProtect Level 3 (UV required at the authenticator), even if you didn’t explicitly request it.

CTAP 2.1 credProtect levels (why Level 3 is special)

credProtect controls whether a credential can be discovered/used without user verification:

Level 1 (UV optional): max compatibility.
Level 2 (UV optional with credential ID list): hides resident creds unless you provide allowCredentials.
Level 3 (UV required): key refuses assertions unless UV succeeds (PIN/biometric).

Level 3 is great security-wise, but it becomes an interop footgun when browsers don’t implement the same CTAP flows.

Why Safari is the odd one out (roaming authenticator limitations)

Safari’s WebAuthn stack is optimized around platform passkeys (Secure Enclave ≈ “always UV”). For roaming authenticators, Safari (as of early 2026 per the article):

doesn’t reliably send/handle credentialProtectionPolicy for external keys
often won’t prompt to set up a PIN when UV is only preferred
may fail the UV/PIN handshake a Level 3 credential requires

Result: a credential that Chrome created with Level 3 can look like “no credential found” in Safari.

Practical signal: Chrome-to-Safari breakage is mostly Level 3

The article’s testing summary is basically:

Chrome + UV="required" → tends to produce credProtect Level 2 → works in Safari/Firefox ✅
Chrome + UV="preferred" (with RK required) → escalates to Level 3 → fails in Safari ❌

That “counterintuitive” matrix is the heart of the bug reports.

Firefox 139+ is catching up (but behaves differently)

Firefox 139 added credProtect support (authenticator-rs). It’s closer to spec parity now, and generally sticks more to what the RP explicitly requests (less implicit escalation than Chrome).

What to do as an RP (2 viable strategies)

If security keys might be involved: set userVerification: "required" 🔐
- avoids Chrome’s Level 3 escalation
- aligns PIN prompts across browsers
- yields credentials that interop better
If you must keep UV="preferred" at scale:
- check UV flag server-side after registration
- use getClientExtensionResults() to see whether credProtect applied
- downgrade trust / require extra factor (Google-style) when UV wasn’t performed

Final note

credProtect itself isn’t “bad”—the pain comes from inconsistent browser behavior (especially Safari + roaming authenticators). If you’re seeing the “Safari does nothing” bug: look at credProtect Level 3 + UV preferred vs required first. 🧪🔑

Find out more on the full write-up: https://www.corbado.com/blog/webauthn-credprotect-security-keys

Go passwordless: delete passwords for secure access

vdelitz — Wed, 25 Feb 2026 17:26:40 +0000

Modern organizations are increasingly adopting passwordless authentication to boost security and improve user experience. While passkeys represent a significant step forward, simply adding them to your authentication flow does not guarantee full protection. This article outlines the essential steps and considerations for enterprises moving toward complete password elimination, with a focus on phishing-resistant security and robust account recovery.

Why Passkeys Alone Aren't Enough for Passwordless Security

Passkeys leverage public-key cryptography to provide strong, phishing-resistant authentication. They eliminate common risks like credential reuse and brute-force attacks. However, many implementations retain passwords as fallback or recovery options. These "backdoors"—such as SMS OTPs, email magic links, or legacy password prompts—introduce vulnerabilities that attackers frequently exploit, as seen in incidents like the MGM Resorts and Okta breaches.

The Four-Phase Passwordless Journey

Transitioning to true passwordless authentication involves a structured, phased approach:

1. Add Passkeys

Start by offering passkeys as an option alongside existing authentication methods. This allows users to become familiar with the new process and builds initial adoption.

2. Increase Passkey Adoption

Encourage users to make passkeys their default authentication method. Use intelligent prompts, user education, incentives, and conditional access policies to drive higher adoption rates.

3. Remove Passwords

Once users consistently use passkeys, begin phasing out password-based logins. Ensure users have backup passkeys to prevent lockouts during this transition.

4. Phishing-Resistant Account Recovery

Secure recovery flows by using multi-factor authentication with phishing-resistant factors such as backup passkeys, hardware security keys, or identity verification (including liveness detection). Eliminate reliance on passwords, SMS codes, or email-based recovery to close common attack vectors.

Enterprise Adoption: Industry Examples and Rollout Strategies

Several organizations are at different stages of the passwordless journey. Companies like Okta, Yubico, and Cloudflare have successfully transitioned to fully passwordless authentication for their internal systems. Meanwhile, industry leaders such as Google, Apple, Microsoft, and X are taking a gradual rollout approach, analyzing user behavior and addressing edge cases along the way.

For sectors with high exposure to phishing—like banking, healthcare, insurance, government, and critical infrastructure—a strategic, phased rollout is especially important. Start with early adopters, monitor adoption rates, and refine the process to minimize disruption and avoid user lockouts.

Key Considerations for Secure Passwordless Adoption

Remove passwords from all authentication and recovery stages to prevent exploitation of fallback mechanisms.
Ensure multi-factor authentication uses only phishing-resistant factors.
Monitor user adoption and behavior analytics to guide staged rollouts.
Provide seamless management of password deactivation and secure recovery options.

Platforms like Corbado support enterprises through every stage of this journey, from initial passkey integration to analytics and secure recovery workflows.

The Future of Passwordless Authentication

Achieving full passwordless authentication is not just about implementing passkeys—it requires eliminating every password entry point, including hidden ones in recovery processes. This holistic approach fortifies your organization against phishing and credential-based attacks, providing the highest standard of authentication security.

Find out more about building a truly passwordless authentication system and practical implementation steps on our blog: Read the full article here

WebAuthn ROR for cross-domain passkeys

vdelitz — Fri, 20 Feb 2026 10:33:09 +0000

Unlocking Cross-Domain Passkeys with WebAuthn Related Origin Requests

As brands expand globally, operating across multiple domains is the norm. Traditionally, FIDO/WebAuthn passkeys—built for phishing-resistant, passwordless authentication—are tightly bound to a single domain, creating friction when users attempt to log in on different country-code top-level domains (ccTLDs) or brand variants. The newly standardized WebAuthn Related Origin Requests (ROR) feature solves this, enabling secure multi-domain passkey usage without compromising on security or user experience.

Core Concepts: How Related Origin Requests Work

WebAuthn Related Origin Requests allow multiple trusted domains to share a single passkey, removing the need for users to manage separate credentials across each domain. ROR works by introducing a public, verifiable allowlist hosted at /.well-known/webauthn on the primary relying party domain. This JSON file explicitly lists authorized related origins, and browsers securely fetch and validate the list to determine if cross-domain passkey usage should be permitted.

Key Elements:

Server-side: Configure a well-known JSON file specifying allowed domains.
Client-side: Use a shared relying party ID (rpID) for consistent authentication across domains.
Browser enforcement: Modern browsers (Chrome, Edge, Safari) validate the allowlist to ensure strict origin verification, maintaining phishing resistance.

Security Foundations: Same-Origin Policy and rpID Scoping

Security is the backbone of WebAuthn. The Same-Origin Policy and rpID scoping prevent unauthorized credential access. ROR provides a secure, standardized mechanism to relax these constraints for brands with multi-domain needs, while ensuring that only explicitly authorized origins can participate. This careful design means phishing protections remain robust, even as authentication becomes more flexible.

Implementation Best Practices for Developers

Implementing WebAuthn Related Origin Requests involves:

Creating a /.well-known/webauthn JSON file with a list of trusted domains (up to five origins).
Configuring your authentication server to serve this file at the correct path.
Ensuring all client applications use the same rpID when initiating passkey authentication.
Monitoring browser support and providing graceful fallbacks for browsers lacking ROR capability (notably Firefox, as of 2024).

This approach enables seamless, user-friendly authentication flows across all your brand’s digital properties—without sacrificing security.

Real-World Use Cases: Leading Brands

Major organizations like Microsoft, Shopify, and Amazon leverage ROR to streamline authentication across multiple domains, ensuring consistent branding and secure user journeys. Their adoption highlights the growing maturity of cross-domain passkey strategies, helping set best practices for global multi-domain authentication.

Compatibility and Browser Support

Most modern browsers—including Chrome, Edge, and Safari—support WebAuthn Related Origin Requests, making this solution broadly accessible. However, Firefox does not yet include support, so it’s critical to implement compatibility checks and fallback mechanisms to ensure all users enjoy a smooth experience.

Strategic Considerations and Deployment Limits

When deploying ROR, be mindful of the five-label maximum for related origins and plan your domain strategy accordingly. Consider phased rollouts for existing systems and direct integration for new projects. Automation tools and platforms can further streamline setup and ongoing management.

Streamlining with Corbado

Platforms like Corbado can automate much of the configuration, offer enterprise-grade security, assist with migratory needs, and support integration across complex architectures. Leveraging such solutions can save significant development time and reduce operational risks.

Conclusion: The Future of Passwordless, Multi-Domain Authentication

WebAuthn Related Origin Requests mark a significant milestone, making seamless cross-domain passkey authentication both secure and practical for organizations with diverse web properties. This evolution in WebAuthn standards paves the way for a truly passwordless future, while maintaining industry-leading security standards.

Find out more on our detailed guide and implementation insights