DEV Community: vdelitz

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

Mobile Driver’s License (mDL) for secure digital IDV

vdelitz — Thu, 19 Feb 2026 15:04:15 +0000

What Is a Mobile Driver’s License (mDL)?

A Mobile Driver’s License (mDL) is reshaping digital identity verification by replacing traditional physical licenses with a government-issued, cryptographically secure digital credential. Instead of carrying a plastic card or a photo/PDF version, users store an mDL in a trusted digital wallet app such as Apple Wallet or Google Wallet. This approach dramatically reduces the risk of fraud, enhances onboarding experiences, and delivers real-time, verifiable identity data.

Key Features: Selective Disclosure and Privacy

One of the standout features of mDLs is selective disclosure. Rather than revealing the full details on a physical license, users can choose to share only the specific information required for a transaction—for example, just proof of age. This aligns with GDPR and other privacy regulations, protecting user data while reducing compliance risks for businesses handling personal information.

Fraud Reduction and Data Integrity

For organizations verifying IDs, mDLs provide a leap in security. They replace manual, visual inspection with deterministic cryptographic verification, ensuring data is both accurate and current. Since information is transmitted directly from authoritative sources, and real-time validity checks are possible, expired or revoked credentials are immediately flagged—something not feasible with physical cards.

Technical Standards: ISO 18013-5 and 18013-7

The mDL ecosystem is grounded in international standards. ISO/IEC 18013-5 specifies the structure, secure communication, and cryptographic safeguards, while ISO/IEC 18013-7 outlines protocols for remote verification. Together, these standards ensure interoperability and high security across platforms and jurisdictions.

Verification Methods and the Triangle of Trust

mDL verification can be performed through various channels:

NFC for quick, contactless reads
Bluetooth Low Energy for short-range wireless checks
QR codes for flexible online verification

The architecture follows a "Triangle of Trust" model: the government (issuer), the citizen (holder), and the business (verifier). Offline verification is also supported by preloading public keys onto verifier devices.

Global mDL Adoption Trends

Adoption models differ worldwide:

U.S.: State-led, decentralized approach with TSA acceptance accelerating adoption.
EU: Unified under the eIDAS 2.0 framework and the European Digital Identity (EUDI) Wallet initiative.
Australia: Federated but harmonized rollouts.
Singapore: A mature, government-integrated system via Singpass.

Business Value: For Product Managers, CISOs, and CTOs

Product Managers: mDLs streamline digital onboarding, reducing errors and friction, which boosts conversion and lowers acquisition costs.
CISOs: Enjoy robust fraud prevention, cryptographic assurance, and easier KYC/AML compliance.
CTOs: Move from manual document processing to structured, machine-readable identity data, reducing technical debt and enabling more scalable architectures.

Integration: APIs, SDKs, and Beyond

Integrating mDL verification is made simpler by commercial Identity Verification Platforms that offer APIs and SDKs. These platforms support secure, user-consented verification flows, accelerating deployment. When combined with passkey authentication, businesses can achieve an end-to-end, phishing-resistant digital identity lifecycle—strong onboarding with mDLs and seamless subsequent logins with passkeys.

Looking Ahead: mDLs and the Future of Digital Trust

As mDLs gain traction, they are set to transform how we prove and manage identity online. Early adopters will benefit from reduced fraud, higher user satisfaction, and future-proof compliance.

Find out more on our detailed blog post.

Passkey Day 2 Problems: 5 Risks in Production Deployments

vdelitz — Wed, 18 Feb 2026 15:54:26 +0000

Read the full article here

Passkeys (WebAuthn) are widely seen as the next default for consumer authentication: phishing-resistant, fast, and typically easier than passwords. But most teams underestimate where passkey projects actually fail. Getting a basic passkey login working in a test environment is often the easy part.

The hard part starts after launch—when real users, real device combinations, and real organizational constraints hit your deployment. These are the passkey Day 2 problems: operational issues that appear only at scale and can force teams into rollbacks, messy fallbacks, or support overload.

Below are five recurring WebAuthn production deployment risks that commonly surface after “Day 1” shipping.

1) Passkey recovery and fallback strategy: avoid lockouts and phishing regressions

The most dangerous gap in many deployments is a weak passkey recovery and fallback strategy. A typical scenario: a user registers a passkey on an iPhone, then loses the device. If their passkey was synced (e.g., via a cloud credential manager), recovery can be smooth. If it wasn’t—or if they also lose access to that cloud account—users may hit confusing OS prompts (like being asked to use a passkey from another device that doesn’t exist).

Teams often “solve” this with email resets or other lightweight fallbacks. Operationally that reduces support tickets—but security-wise it can undo the core value of passkeys by reintroducing phishable recovery paths.

Mature deployments treat recovery as a layered system (with increasing cost and assurance). Exactly which layers to implement depends on threat model and economics—and maintaining those layers becomes part of ongoing operations.

2) Cross-device passkey authentication via QR code: fragile in real environments

Most users don’t live in one ecosystem. They mix iOS, Android, Windows, macOS, different browsers, and sometimes corporate-managed devices. That’s where cross-device and cross-ecosystem edge cases show up.

A common pattern is cross-device passkey authentication (QR code flows): create a passkey on a phone, sign in on a laptop by scanning a QR code. These flows can work well, but they’re also sensitive to real-world constraints:

Bluetooth and proximity requirements
Corporate proxies, firewalls, and MDM restrictions
UX differences between Chrome, Safari, Edge, Firefox
Confusion about why scanning is needed and what’s happening

In practice, teams often end up maintaining complicated routing logic (device detection, conditional UI decisions, and fallbacks) to keep the experience stable across combinations.

3) Native app passkeys (iOS/Android): QA and release cycles become a Day 2 tax

If you ship native apps, native app passkeys on iOS and Android add a separate layer of complexity beyond the web. Architecture choices (native vs WebView) change how reliable passkeys are and how much platform-specific work you inherit.

Operationally, the burden isn’t just implementation—it’s ongoing QA across:

iOS passkey behavior changes by OS version and authentication surface
Android Credential Manager interactions with multiple credential providers
Platform-specific error states, timeouts, and system prompts

And unlike the web, urgent fixes may be blocked by app store review delays, turning small regressions into prolonged incidents.

4) Passkey adoption analytics and rollout: “supported” isn’t “used”

Many projects stall because teams treat passkeys as a technical checkbox. But passkey adoption is a product outcome: without a rollout plan and measurement, usage often remains low even when the integration is correct.

This is where passkey adoption analytics and rollout matter. Effective programs typically include:

Progressive enrollment prompts at the right moments
Clear, non-technical user communication
Device-aware offering (don’t push creation where support is poor)
Metrics for creation rate, login rate, fallback rate, and abandonment

Without analytics, teams may not notice they’re stuck in weak adoption until the project is labeled a failure.

5) Platform changes breaking passkeys: silent regressions require observability

Passkeys depend heavily on OS, browsers, and credential manager behavior. That makes them uniquely exposed to updates that can change prompts, autofill logic, or capability checks.

A concrete example mentioned in the article: an iOS release where a common capability check can return misleading results on non-Safari browsers—forcing teams to ship platform-aware workarounds.

The broader lesson is that authentication observability for passkeys is not optional in production. Teams need monitoring that can break down authentication success/failure by OS, browser version, and passkey provider, with alerting that catches spikes before support queues do.

Build vs buy for enterprise passkey implementation

A recurring theme: building a WebAuthn server is rarely the main challenge. Operating passkeys reliably—across recovery, device matrices, native apps, adoption, and platform shifts—is what turns a demo into a durable enterprise passkey implementation.

Some organizations staff for that ongoing operational reality; others choose managed infrastructure to reduce the long-term maintenance burden.

When you should not ship passkeys (yet)

Passkeys can improve both security and UX—but shipping too early can backfire. You’re typically not ready if you lack:

A tested recovery and fallback strategy
Coverage for your users’ real device/browser mix
An ongoing plan for native app passkey QA (if applicable)
Adoption metrics and rollout targets
Monitoring and resources for platform-driven regressions

Find out more

Authentication KPIs That Matter: From Login Funnel Health to Passkey Adoption

vdelitz — Wed, 11 Feb 2026 11:00:00 +0000

If you ship login, you ship a funnel. Users arrive with intent, choose a method, go through a flow that can fail in many ways, and either end up authenticated or leave. The fastest way to improve outcomes is to stop treating “login” as one black box and measure it like any other high-impact conversion journey.

Below is a practical overview of the core authentication KPIs that help teams diagnose reliability, reduce friction, increase passkey adoption, lower support load, and track real security impact. (I’ll keep this high-level on purpose. The full KPI library goes deeper into benchmarks, instrumentation patterns, and segmentation strategies.)

Different KPIs attach to different points. That matters because “success rate” can look fine while users churn earlier, or while passkeys fail and users fall back to passwords.

See our Authentication KPI Library here

Reliability KPIs: what breaks and where

Authentication Error Rate

Authentication Error Rate is the share of authentication attempts that end in a logged, explicit error (as opposed to silent drop-off). Think: invalid credentials, technical failures, user-cancelled, account locked, unsupported device.

Why it’s useful: explicit errors tell you what broke and are often the quickest path to fixes (bad validation, flaky dependencies, SDK incompatibilities, confusing prompts). It becomes especially powerful when segmented by platform, OS version, browser/WebView, and method.

Read the full article about the Authentication Error Rate here

Login Success Rate (from starting a method)

Login Success Rate measures whether a user who starts a specific method reaches an authenticated session. This is a method-level health metric: “Once someone commits to OTP/passkey/password, does it work end-to-end?”

It’s your early-warning system for regressions. A sudden drop often points to a release issue, backend validation change, third-party outage (SMS, email), or client-side logging bugs. The key is to define “start” as a real commitment action, not just showing the method.

Read the full article about the Login Success Rate here

Passkey Authentication Success Rate

Passkey Authentication Success Rate is the same idea, but specifically for passkeys: once a passkey flow starts, how often does it end with an authenticated session?

Passkeys fail differently than passwords: cancellations at the biometric prompt, cross-device friction, missing platform support, or inconsistent WebView behavior. Measuring passkeys separately prevents “fallback masking,” where overall login looks healthy while passkeys are quietly unreliable.

Read the full article about the Passkey Authentication Success Rate here

Friction & Speed KPIs: where users silently give up

Authentication Drop-Off Rate

Authentication Drop-Off Rate captures the share of attempts that start but never reach completion, even if no explicit error is recorded. This is often where conversion and retention leak: users close the tab, get distracted, hit confusing UX, or get stuck on delivery delays.

This KPI is most actionable when paired with step-level telemetry (method chooser, identifier entry, code entry, passkey prompt, recovery screens). It’s also sensitive to timer windows, so you want a consistent definition of when an attempt “times out.”

Read the full article about the Authentication Drop-Off Rate here

Time to Authenticate

Time to Authenticate measures elapsed time from starting authentication to reaching authenticated content. It includes user input, redirects, network time, and server verification. The median matters, but tails (like p95) are where frustration lives.

This metric is how you quantify “login feels slow.” It often correlates with drop-off, especially when the flow adds waiting (OTP delivery, magic link email, retries, or multiple prompts). Improvements usually come from reducing steps, improving defaults, tightening recovery UX, and addressing mobile performance issues.

Read the full article about Time to Authenticate here

Passkey adoption KPIs: enrollment versus real usage

Login Engagement Rate

Login Engagement Rate asks: when a login entry point is offered, how often do users actually start a login attempt? If it’s low, you might be showing login at the wrong time, confusing visitors, or over-counting “offers” due to re-renders.

This KPI is a good diagnostic for early funnel issues before credentials even enter the picture.

Read the full article about the Login Engagement Rate here

Login Conversion Rate

Login Conversion Rate measures how often users who are shown at least one method actually start any method. It’s highly sensitive to method chooser UX: unclear labels, too many options, poor ordering, and showing unusable methods on a given device or locale.

If you want a quick “is our chooser confusing?” signal, this is it.

Read the full article about the Login Conversion Rate here

Passkey Enrollment Rate

Passkey Enrollment Rate measures how often users who are offered a passkey creation opportunity actually complete enrollment. It’s the gateway metric for passkey adoption.

Enrollment depends heavily on timing and context. In many products, users do not go looking for “security settings,” so measuring enrollment based on a real offer event (not just eligibility) is critical. If enrollment is low, the issue is usually prompt timing, copy clarity, or platform-specific enrollment friction.

Read the full article about the Passkey Enrollment Rate here

Passkey Usage Rate

Passkey Usage Rate measures, among completed logins, how many are completed with a passkey. This is the “ROI metric” for passkeys because it reflects whether passkeys became the default, low-friction path in real behavior.

A common pattern: enrollment looks great, usage stays low. That usually means passkeys are not presented as the primary path, cross-device flows create friction, or one bad experience teaches users to choose fallback forever. Usage needs to be tracked separately from enrollment.

Read the full article about the Passkey Usage Rate here

Fallback & Recovery KPIs: fallback methods and account recovery flows

Password Reset Volume

Password Reset Volume measures completed password resets per active user over time (often normalized per user per year). It quantifies the ongoing tax of passwords: user frustration, deliverability costs, and support workload.

It also helps you validate whether changes actually reduce password dependence, rather than just shifting problems elsewhere.

Read the full article about the Password Reset Volume here

Business Impact KPIs: what is the business impact of passkeys?

Authentication Support Ticket Rate

Authentication Support Ticket Rate tracks what share of support tickets are driven by login and account access issues. Tickets lag behind UX problems, but they are a real cost signal and often correlate with spikes in errors, lockouts, delivery failures, or confusing recovery paths.

If your success rates look stable but tickets rise, you may have hidden friction or a messaging problem that metrics alone are not capturing.

Read the full article about the Authentication Support Ticket Rate here

Account Takeover Rate

Account Takeover Rate measures confirmed compromised accounts relative to active accounts in a period. This is a “real harm” metric, not an attempts metric.

It’s also easy to distort if definitions drift. You need consistent confirmation criteria and awareness that takeovers are often confirmed later than the login event. Still, it’s the cleanest way to tie authentication quality to fraud loss, support burden, and user trust.

Read the full article about the Account Takeover Rate here

Total Authentication Success Rate

Total Authentication Success Rate aggregates all methods into one number: out of started authentication attempts, how many end in an authenticated state? It answers the executive-level question: “Can users get in?”

But it’s only useful if you pair it with the method-level and funnel-stage KPIs above. Otherwise, method mix shifts and fallback masking can hide real issues.

Read the full article about the Account Takeover Rate here

How to Track Login Success and Failures in GA4

vdelitz — Tue, 10 Feb 2026 11:00:00 +0000

Read the full article here

Why track login events in GA4

Authentication is the point where anonymous traffic becomes an identifiable user. Your IdP or CIAM system can confirm that a login happened, but it usually cannot explain what led to the attempt or where users struggled along the way.

That’s where Google Analytics 4 (GA4) can help. GA4 is event-based and includes a recommended **login** event, which makes it possible to connect pre-login acquisition context (source, campaign, device) with post-login outcomes (retention, conversion metrics like AOV or CLV). For product teams, this can turn “login friction” into something you can actually quantify.

What GA4 does well for authentication analytics

Cross-device journeys with GA4 User-ID

If you set a stable user_id after authentication, GA4 can stitch sessions together and associate pre-login behavior with the logged-in user. This is useful for questions like: do users who browse longer before logging in convert better, or do some channels consistently produce high-intent users who then fail at login?

Funnel exploration and segmentation

GA4’s Exploration reports let you build login funnels and segment after the fact by device category, browser version, traffic source, and more. It’s a practical way to spot patterns such as “logins failing mostly on one browser version” or “paid traffic has lower login success.”

Audiences and retargeting

GA4 can build audiences based on event sequences, like “high-intent users who failed login,” and export them for re-engagement campaigns. This is one of GA4’s biggest advantages over server-side auth logs.

Where GA4 falls short for login tracking

GA4 is not built for operational authentication monitoring, and the limitations are structural:

Latency: GA4 reporting can lag by 24–48 hours, which is too slow for incident response when an OTP provider breaks or a release introduces auth errors.
Cardinality limits: Detailed error codes, user agents, and device fingerprints can exceed GA4’s limits, causing values to collapse into “(other)” and reducing usefulness for root cause analysis.
PII restrictions: You cannot send emails, usernames, or phone numbers to GA4. That makes per-user troubleshooting impossible inside GA4.
Tracking gaps: Consent declines, ad blockers, cross-domain auth redirects, and iframe-based flows can all distort your login numbers if not handled carefully.

A practical GA4 event schema for login funnels

To get useful login success rate metrics, most teams need more than the default login event. A simple schema that works well:

**login_started**: user enters the auth flow (modal opened, sign-in clicked, or passkey autofill initiates)
**login** (success): only fire when the backend issues a valid session token
**login_failed**: backend error or client-side validation failure

Then add a small set of parameters that stay low-cardinality:

method (password, passkey, google, apple, sso)
error_category (credential_mismatch, timeout, user_cancelled, network)
login_location (header, checkout, settings)
is_checkout (true/false)
user_type (new/returning)
c_device_support (passkey_ready/legacy)

Implementation approach: GTM + dataLayer

A common pattern is to push semantic auth events into the dataLayer and let Google Tag Manager (GTM) map them to GA4 events and parameters. This keeps analytics logic out of your app code and makes iteration easier. (Most teams also avoid sending raw error strings directly and instead map them to categories to prevent cardinality issues.)

What to monitor in GA4

A lightweight “Login Health” view typically includes:

Login Success Rate: successful logins ÷ logins started
Failure distribution: login failures by method and error category
Checkout vs non-checkout login performance: separate conversion-critical flows
Segmented views: device, browser, channel, and returning vs new users

For deeper timing metrics like time-to-auth, you often need a BigQuery export or a separate measurement layer.

Read the full article here

How Passkeys Improve Retention: Why Keychains Keep Users Coming Back

vdelitz — Mon, 09 Feb 2026 11:00:00 +0000

Read the full article here

Passkeys turn authentication into a retention lever

Passkeys are quickly becoming the default way consumers sign in, especially on mobile. The reason is simple: once a passkey exists, returning users do not “remember” anything. Re-login collapses to a single biometric step.

For growth and product teams, this changes the retention equation. Historically, re-engagement relied heavily on cookies, saved sessions, and “stay signed in” behaviors that are fragile across devices, browser settings, and privacy controls. Passkeys shift reactivation from browser state to credential managers, where credentials persist across time and (often) across device upgrades.

Where passkeys live: credential managers, not browsers

In practice, most consumer passkeys are stored in platform credential managers:

Apple (iOS/macOS): iCloud Keychain + Passwords app Passkeys sync by default across Apple devices signed into the same Apple ID. Users rarely manage them manually, which means passkeys tend to remain available for long periods.
Android/Chrome: Google Password Manager On Android and in Chrome, passkeys typically sync via Google Password Manager. This also improves cross-platform reach for users who rely on Chrome on desktop. Some Android ecosystems (for example, certain Samsung setups) may use a different default credential manager, which can influence user experience and support expectations.

A key implication: passkeys are not tied to a specific browser cookie jar. They are tied to the user’s credential manager. That is why they can survive scenarios where traditional “remember me” fails, like browser cleanup, app reinstalls, or switching to a new phone.

Why cookie-era re-engagement is getting weaker

Cookies still matter for checkout speed and personalization, but their reliability as a re-engagement foundation has been reduced over the last years:

Consent requirements make persistent tracking and personalization harder to guarantee for every user.
Tracking prevention (especially on Safari/WebKit) reduces cross-site and third-party tracking capabilities.
Chrome’s direction has added ongoing uncertainty for teams that built growth loops around third-party cookie assumptions, while privacy controls keep tightening elsewhere.

The practical outcome is not “cookies are dead.” It is that cookie-based reactivation is less dependable as a default plan. This makes the login experience itself more important: if returning users can sign in instantly, you do not need to “hold” them with fragile session state.

The passkey retention loop: why re-login becomes effortless

When passkeys sync through a credential manager, they enable a simple retention loop:

A user creates a passkey once
The passkey is stored and synced in their keychain/password manager
The user returns weeks or months later
They sign in instantly with biometrics

This loop reduces several common churn drivers:

No password resets: users do not enter “forgot password” flows that derail intent.
Native autofill-style UX: passkey prompts feel like part of the OS, not a form.
Device continuity: when users upgrade devices (and keep the same credential manager), access persists.
Reinstall resilience: uninstalling an app does not necessarily remove the passkey from the credential manager, so return logins can stay smooth.

Growth playbook: get a passkey into the keychain

The strategic goal is straightforward: maximize the share of users who end up with a synced passkey.

A few high-performing patterns:

Prompt after a successful login: trust is established and the value is clear (“make next sign-in faster”).
Prompt after checkout: the user has already completed the hard part and is more open to reducing future friction.
Keep reliable fallbacks: not every device is passkey-ready, and not every user opts in immediately. A broken fallback path can wipe out retention gains.

Read the full article here

How Passkeys Improve Conversion Rate: Checkout Levers and Adoption Metrics

vdelitz — Sun, 08 Feb 2026 11:00:00 +0000

Read the full article here

Why passkeys are a conversion and revenue lever

Passkeys are often introduced as a security upgrade, but their biggest impact in B2C flows is usually conversion rate. They remove the most common sources of login friction: forgotten passwords, typo-heavy mobile input, and slow fallback flows. For product teams working on CIAM, this matters because retention and repeat purchases drive lifetime value. With rising CAC, improving the authentication experience for returning users can be just as important as optimizing first-time sign-up.

In practice, passkeys turn authentication into a faster, higher-success step that keeps users in the purchase funnel instead of pushing them into password resets or OTP loops.

Case study: how KAYAK used passkeys for conversion optimization

KAYAK is one of the early large-scale passkey adopters in consumer authentication. Public case studies report two outcomes that are especially relevant for conversion work:

Strong adoption during sign-up, with a large share of new users choosing passkeys when offered.
Faster sign-up and sign-in, with reported reductions in end-to-end time.

KAYAK also used a pragmatic fallback approach for users who could not create a passkey, keeping the experience passwordless where possible instead of forcing users back to a password wall. The key lesson is not that every user will switch instantly, but that a passkey-first default can shift behavior quickly without breaking existing flows.

Benchmarks: passkeys outperform passwords on success rate and speed

Across multiple deployments, industry benchmarks show a consistent pattern: passkeys tend to deliver a much higher authentication success rate than passwords, and they complete faster. That matters for checkout because login is often the steepest drop-off point for returning customers.

Two numbers that often show up in passkey adoption reporting:

Higher login success rate with passkeys compared to passwords, driven by the removal of memory and typing errors.
Shorter time-to-authenticate, which reduces abandonment on mobile and in time-sensitive purchase moments.

Even if your product already has strong checkout analytics, you often need authentication-specific measurement to see where those gains come from, and whether they hold across devices and operating systems.

Four checkout growth levers passkeys unlock

**Increase login success rate at the checkout gate **Checkout login is where users have already decided to buy. If authentication fails, they rarely “try later.” Passkeys improve this step by removing the “wrong password” loop and enabling biometric sign-in that users cannot forget. When implemented with UX patterns like passkey autofill (Conditional UI) or one-tap entry points, passkeys can also reduce drop-off caused by users forgetting which email they used.
**Reduce time-to-purchase with faster authentication **Speed matters most on mobile, where typing is error-prone and context is distracting. Passkeys replace multi-field input with a short biometric step, which can materially reduce time spent in the login portion of checkout. This becomes even more relevant in flash sales or limited inventory scenarios where slow login can erase the benefit of strong merchandising or scarcity tactics.
**Eliminate password reset abandonment **Password resets are a conversion killer because they force users into a long recovery journey at the worst moment. Many consumers abandon purchases when they cannot remember credentials, and the reset flow adds more drop-off points (email delays, spam folders, password rules). Passkeys remove the reset loop for users who have created one, keeping high-intent customers moving toward payment.
**Convert guest checkout buyers into logged-in customers **Guest checkout exists largely because account creation is too much work. Passkeys change that trade-off: creating an account no longer requires inventing and remembering a new password. A common approach is to prompt users after purchase with a simple value proposition like “Save your details for faster checkout next time,” then let them create a passkey in seconds. This can increase the share of logged-in customers over time, improving retention and LTV without adding friction to the first purchase.

What to measure to prove ROI

To make passkeys a conversion initiative (not just a security project), track metrics such as login success rate, time-to-auth, auth funnel drop-off, and fallback rate across passkeys vs passwords and OTP. Segment by device and OS so you can spot where performance differs and where UX improvements will have the biggest impact.

Read the full article here

How to Measure Passkey Adoption: Funnels, Activation, and Device Insights

vdelitz — Sat, 07 Feb 2026 11:00:00 +0000

Read the full article here

What passkey analytics is and why teams need it

Passkey analytics helps product, identity, and security teams understand what’s really happening in passkey authentication: where users drop off, which platforms struggle, how adoption evolves over time, and what drives successful passkey login. Standard product analytics often shows only coarse events (page views, “login clicked”), while identity logs focus on backend outcomes. Passkeys introduce new failure modes and UX paths (biometric prompts, credential managers, cross-device flows) that require more specialized visibility.

A practical passkey analytics setup focuses on three outcomes: activation (users create passkeys), usage (users actually log in with passkeys), and reliability (errors, cancellations, platform issues).

Authentication funnel analysis for passkeys

The foundation is an authentication funnel that visualizes real user paths through signup, login, and passkey creation flows. Think of it like process mining for authentication: you can see which screens users hit, which route they take (passkey vs fallback), and where they abandon.

A useful funnel view typically includes KPIs such as rollout progress (who is eligible), creation success (append rate), passkey login success, and fallback frequency. The biggest value is not the chart itself, but how quickly you can answer questions like: “Are users reaching the passkey prompt?”, “Do they complete creation?”, and “Where do they detour into passwords or OTP?”

Common funnel use cases include:

Implementation validation: confirm the “happy path” works before scaling rollout.
Passkeys vs legacy comparison: quantify differences in success rate and drop-off between passkey users and fallback users.
Cross-device flow analysis: identify whether QR and Bluetooth-based cross-device authentication is confusing, error-prone, or being skipped.

You also want segmentation (web vs native, iOS vs Android vs Windows) and trend views so you can spot sudden changes after OS updates or product releases.

Device analytics: who adopts passkeys (and where issues hide)

Device analytics answers “who is using passkeys” with context. A common pattern is to segment users by login frequency (occasional users vs power users) and then compare passkey behavior across those groups. This helps teams avoid misleading averages: strong passkey adoption in power users can coexist with weak adoption in first-time or low-frequency users.

Device analytics should also break down platform and environment:

OS and OS version distribution
Browser distribution (for web)
Passkey readiness (device capability)
Device authentication configuration (biometrics vs PIN/passcode)

This is often the fastest way to pinpoint platform-specific friction and to ground stakeholder discussions in real data.

Activation analytics: improving passkey creation rates

Activation analytics focuses on passkey creation, usually measured as append rate (how many users create a passkey when shown the creation screen). A key insight is that users don’t always create a passkey on the first prompt. Tracking creation performance across multiple exposures helps teams optimize timing and placement without guessing.

Activation analytics becomes especially valuable when you break results down by OS and version, because passkey creation behavior can vary significantly across environments.

Login analytics: passkey usage rate and speed

Once passkeys exist, you want to measure passkey usage rate (how often users choose passkeys for login) and compare performance against fallback methods. A good analytics view also shows how logins are initiated: passkey autofill (Conditional UI), one-tap entry points, native credential selectors, or traditional “type identifier then authenticate.” If users keep defaulting to text-field login even after creating passkeys, that’s usually a UX discoverability problem, not a passkey problem.

Passkey insights: credential managers, sync, and cross-device capability

Passkeys live in different credential managers (iCloud Keychain, Google Password Manager, Windows Hello, third-party password managers). Passkey insights should show:

authenticator distribution (what users rely on)
sync status (whether passkeys carry over to new devices)
transport capability (local vs cross-device “hybrid” flows)
time-series changes (to catch shifts after OS updates)

This is where many teams discover hidden constraints, like segments that end up device-bound and therefore struggle during device changes.

Why generic analytics tools fall short

Tools like GA4 or Mixpanel can track basic events, but they typically lack passkey-specific visibility (credential manager mix, sync state, cross-device flows) and often introduce delays or limits that make troubleshooting harder. Many teams end up combining generic product analytics (journey context) with dedicated passkey observability (auth detail).