---
url: 'https://www.corbado.com/zh/blog/passwordless-b2c-at-scale'
title: '大规模 B2C 无密码认证：2026 指南'
description: '详解大规模 B2C 无密码认证。本文涵盖 50 万以上 MAU 企业部署的参考架构、总拥有成本 (TCO) 以及通行密钥的采用阶梯。'
lang: 'zh'
author: 'Vincent Delitz'
date: '2026-05-19T11:50:32.330Z'
lastModified: '2026-05-19T12:27:52.919Z'
keywords: '大规模 B2C 无密码认证, 大规模无密码认证, 企业级 B2C 通行密钥, 无密码 CIAM, 50万 MAU 通行密钥, 通行密钥编排'
category: 'Passkeys Strategy'
---

# 大规模 B2C 无密码认证：2026 指南

## Key Facts

- 当团队仅依赖 CIAM 原生的 WebAuthn API 时，**大规模无密码认证的通行密钥登录率会停滞在 5-10%**，无论底层平台是 Auth0、Cognito、Ping Identity 还是 Clerk。
- 根据 Corbado Passkey Benchmark 2026 的数据，**首次尝试的 Web 通行密钥注册率**在 iOS 上为 49-83%，而在 Windows 上降至 25-39%——这种两倍的差距，普通的 CIAM 界面往往无法兼顾。
- **高级部署模式（Advanced）**（通行密钥优先的返回流程，结合自动创建和标识符优先的恢复机制）能在 89% 的 Web 就绪上限下，将通行密钥登录率提升至 60% 以上。
- **对于 50 万 MAU** 的应用，短信 OTP 减少 60-90% 意味着每年可节省 5 万到 10 万美元甚至更多的成本，而编排层通常在第一季度内即可回本。
- 在 CIAM 平台中**原生构建无密码功能**，通常需要在产品、开发和 QA 团队投入 25-30 个人月（FTE-months），加上每年约 1.5 个人力用于跨平台的持续维护。
- **在 2026 年的 CIAM 竞品中，没有哪家供应商**将设备感知提示、标识符优先恢复和 Conditional Create 作为原生标配——这些功能存在于独立的编排层中。

## 1. 简介：大规模 B2C 无密码认证

如今，大规模 B2C 无密码认证已不再只是可选项——它是 CIAM 团队的一项重要需求。对于总量 200 万、每月活跃用户（MAU）达到 50 万的用户群，每提高一个百分点的[通行密钥采用率](https://www.corbado.com/blog/passkey-adoption-business-case)，就能带来可见的[短信 OTP 成本](https://www.corbado.com/blog/sms-cost-reduction-passkeys)下降，减少账户接管风险，并提高[结账转化率](https://www.corbado.com/blog/logins-impact-checkout-conversion)。然而，在大多数“启用了通行密钥”的[大规模](https://www.corbado.com/blog/introducing-passkeys-large-scale-overview) B2C 部署中，仍有 90% 的日常登录依赖密码或短信 OTP。

本指南将解释为什么通用的 CIAM 无密码方案在扩大规模时会遇到瓶颈，介绍能够稳定将[通行密钥登录率](https://www.corbado.com/kpi/passkey-usage-rate)提升至 60% 以上的四层参考架构，以及针对 50 万 MAU，财富 500 强企业应规划的总拥有成本 (TCO)。

## 2. 为什么通用 CIAM 无密码方案在扩展时会停滞

关于无密码采购的市场说法已经很明确：2026 年的每个 CIAM 平台都提供了 [WebAuthn](https://www.corbado.com/glossary/webauthn) API，每个供应商都在其定价矩阵中推销“无密码”方案，且每份分析师报告都将通行密钥作为基线要求。但在 50 万 MAU 的规模下，结果却出奇一致。[通行密钥登录率](https://www.corbado.com/kpi/passkey-usage-rate)徘徊在 5% 左右，短信 OTP 的数量几乎没有下降，预期的成本节省也未成真。究其原因，这往往是架构层面造成的。

### 2.1 采用率错觉

Corbado 的 [Passkey Benchmark 2026](https://www.corbado.com/blog/world-passkey-day-passkey-benchmark-2026) 在相同的 89% Web 就绪上限下，测量了四种部署模式。仅在设置中提供选项的模式产生的登录率不到 1%；简单的登录后提示可将其提升至约 4-5%；带有设备感知提示的优化注册流程则能攀升至 23%；而具备自动创建和标识符优先恢复功能的通行密钥优先返回流程，其采用率超过了 60%。底层的 CIAM 本身并不会改变这些数字；真正起作用的，是架设其上的提示逻辑、设备分类以及登录入口的设计。

即便是运行相同的 [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) 或 [Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito) 租户的同一家企业，也可能落在阶梯的两端，这取决于团队是否在自定义前端实现了基准测试中提到的编排模式。这便是一种采用率错觉：“平台支持通行密钥”并不等同于“平台在规模化时能实现[通行密钥的有效采用](https://www.corbado.com/blog/passkey-adoption-business-case)”。

### 2.2 设备栈碎片化

在拥有 50 万 MAU 的传统 B2C 消费者群体中，设备情况绝非整齐划一。
[Corbado Passkey Benchmark 2026](https://www.corbado.com/passkey-benchmark-2026/passkey-enrollment-rate) 衡量出在 [iOS](https://www.corbado.com/blog/webauthn-errors) 上的首次 Web 注册成功率为 49-83%，[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 为 41-67%，macOS 为 41-65%，而 Windows 上仅为 25-39%。

这其中的差距不仅源于用户偏好，还与生态系统技术栈密切相关。[iOS](https://www.corbado.com/blog/webauthn-errors) 将浏览器、[认证器 (authenticator)](https://www.corbado.com/glossary/authenticator) 和凭据提供商紧密集成；[Windows Hello](https://www.corbado.com/glossary/windows-hello) 尚不支持 [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys) 路径，而 Edge 浏览器的通行密钥保存功能直到 2025 年底才上线。要做出切合实际的考量，就必须将这些因素涵盖在内，包括智能提示以及在移动端和桌面端之间的跨设备使用习惯。

### 2.3 标识符前置的盲区

在消费者身份验证中，用户在输入电子邮件或用户名之前是匿名的。如果一个无密码提示让他们感到困惑，或者[密码管理器](https://www.corbado.com/blog/passkeys-vs-password-managers)覆盖层在他们输入前就拦截了自动填充，后端根本不会留下任何记录。标准的 CIAM 日志并不是为[客户端遥测](https://www.corbado.com/observe)而设计的，因此那些阻碍规模化采用的失败案例（包括后端日志），完全处于身份提供商（IdP）的监控框架之外。

## 3. 50 万 MAU 下的通行密钥采用阶梯

对于在 200 万用户群基础上拥有 50 万 MAU 的 B2C 部署来说，运营目标应是在采用阶梯上攀登，而不是更换 CIAM 平台。每一个层级对应着特定的部署形态，而非不同的供应商。

**通行密钥采用阶梯 (Corbado Passkey Benchmark 2026)**

| **部署模式** | **注册率** | **使用率** | **通行密钥登录率** |
| --- | --- | --- | --- |
| **仅设置选项** (被动型 Passive) | ~4% | ~5% | <1% |
| **简单登录后提示** (基准型 Baseline) | ~25% | ~20% | ~4-5% |
| **优化注册** (托管型 Managed) | ~65% | ~40% | ~23% |
| **通行密钥优先返回流程** (高级型 Advanced) | ~80% | ~95% | >60% |

当我们将相同的就绪上限与这四种部署模式绘制在一起时，这种非线性的跃升便一目了然：

大多数 CIAM 原生部署止步于基准型（Baseline）阶段，因为这正是开箱即用的无密码 UI 能提供的极限：单一的登录后切换开关，没有设备感知的提示，也没有为新设备提供标识符优先的恢复流程，更不支持在使用保存的密码登录后自动创建。要达到托管型和高级型的水准，我们需要细分注册提醒，在生态系统支持的地方使用 [Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)（目前在 iOS 上表现最强，在 macOS 上可行，但在 [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 上碎片化严重，在 Windows 上受限），并通过[一键操作 (one-tap)](https://docs.corbado.com/corbado-connect/features/one-tap-login) 识别回归设备，从而促进辅助登录的转化。

## 4. 大规模 B2C 无密码的参考架构

大规模的无密码认证是一个以 CIAM 为基石的四层架构体系。每一层都在架构上依赖于它的下一层——下方的图表展示了这个金字塔，以及每个组件的职能：

每一层都发挥着独特的作用。CIAM 仍然是系统的核心记录。通行密钥编排覆盖层处理智能提示逻辑；可观察层负责捕获客户端的操作交互；而后备（降级）层负责吸收目前无法完成通行密钥流程的用户环境。下面的章节将逐一拆解这些层次。

### 4.1 身份验证层：作为记录系统的 CIAM

CIAM 保存着用户记录、会话、OAuth/OIDC 令牌、[社交登录](https://www.corbado.com/glossary/social-login)、MFA 策略以及同意声明。对于 50 万 MAU 的 B2C 部署，市场的主流选择依然是 [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis)、[Amazon Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito)、Ping Identity、Ory、FusionAuth，或者在 [Keycloak](https://www.corbado.com/blog/keycloak-passkeys) 之上自建 IdP。此处的选择对授权费用和生态集成意义重大，但对[通行密钥的采用率](https://www.corbado.com/blog/passkey-adoption-business-case)本身影响较小。有关定价分级、AI 代理身份支持以及 50 万 MAU 下的 TCO 分析，请参考完整的 [2026 年 CIAM 供应商评估](https://www.corbado.com/blog/best-ciam-solutions)。

### 4.2 通行密钥编排层 (Passkey Orchestration Layer)

编排层是决定大规模无密码项目成败的关键所在。它在触发 WebAuthn 提示之前拦截身份验证事件，对设备的硬件、操作系统、浏览器和凭据提供商技术栈进行分类，然后将用户引导到专门为其环境设计的操作路径中。

在实践中，针对 50 万 MAU 规模的编排层几乎总是**自定义前端实现**，它位于 CIAM 前方，渲染专门定制的登录 UI。底层的 CIAM 继续处理凭据存储、会话和 OAuth/OIDC，但企业团队将掌控登录入口、设备感知的提示逻辑以及恢复流程。原因归根结底在于结构性要求：B2C 企业团队需要完全掌控品牌形象、转化关键文案、A/B 测试，以及决定哪个用户看到哪个提示的设备分段规则。供应商提供的现成登录页很少能满足这种规模化时的定制需求。

自定义编排层必须实现的具体模式包括：

- **设备与能力分类**：在触发 WebAuthn 提示之前，探测设备硬件、操作系统、浏览器和凭据提供商。对于基准测试中已知会失败的环境，应尽早将用户从死胡同引导至其他流程。
- **Conditional Create**：在支持的技术栈上，如果在密码管理器辅助下成功使用密码登录，系统会自动注册一个通行密钥。这在 iOS 和特定的 macOS 配置中完全免除了显式的注册提示。
- **一键返回流程**：通过尊重隐私的设备信任信号识别回归设备，并在其下次访问时提供单击通行密钥身份验证。
- **标识符优先恢复**：对于 Windows 用户（基准测试表明该群体中 [40-65% 的标识符优先通行密钥成功案例](https://www.corbado.com/passkey-benchmark-2026/passkey-authentication-success-rate) 仍依赖跨设备验证连接到手机），我们将他们引导入与 [iOS](https://www.corbado.com/blog/webauthn-errors) 或 [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 不同的恢复路径中，后者的跨设备桥接率仅有 0-10%。
- **灰度发布**：按操作系统版本、地理位置或用户细分进行定向投放，并无需发布应用更新即可上线智能降级方案。

在 50 万 MAU 规模下，自主构建此层成为主导模式，因为多数大型 B2C 部署已经运行着复杂的前端技术栈，登录流程必须继承内部的设计系统。这带来的代价是为了跟进浏览器、操作系统和凭据提供商的更新，需要付出持续的工程成本。对于那些倾向于购买而非自行构建该层的团队，[Corbado Connect](https://www.corbado.com/connect) 已将相同的编排模式产品化，作为覆盖在任何 CIAM 上的独立层运作，并且无需进行用户数据库迁移。无论选择哪条路径，都能使[通行密钥的注册率](https://www.corbado.com/blog/passkey-creation-best-practices)向 80% 以上的“高级型”上限逼近，从而释放可观的 [SMS OTP 成本](https://www.corbado.com/blog/sms-cost-reduction-passkeys)随规模化带来的 60-90% 的降本收益。

### 4.3 认证可观察层 (Authentication Observability Layer)

在 50 万 MAU 下，所有负责无密码认证的 [CISO](https://www.corbado.com/glossary/ciso)、CTO 和产品负责人都面临着同样的问题：“我们的端到端登录成功率是多少？为什么用户在注册阶段流失？我们是否应该将目标从 10% 扩大至 50%？能否向管理层直观展示其实际效果？”在如今的大多数 B2C 企业部署中，诚实的答案往往是“我们不知道”——这并不是因为缺乏数据，而是因为数据分散在五个独立的系统中，而这些系统在设计之初并没有围绕着通行密钥认证流程来打通。

典型的[企业级技术栈](https://www.corbado.com/blog/integrate-passkeys-enterprise-stack)独立涵盖了以下各个部分：

- **前端内容和体验平台**：能在营销层面上看到浏览量、内容变体和漏斗事件，但看不到 WebAuthn 流程本身。
- **FIDO 或 WebAuthn 服务器**：能记录凭据注册和[断言 (assertion)](https://www.corbado.com/glossary/assertion) 结果，但无法知晓设备在此前或此后发生了什么。
- **后端 APM**：关注 API 延迟与追踪，但无法分辨失败是由于用户主动中止还是生物识别超时导致。
- **身份提供商的编排日志**：能记录触发了什么策略或用户进入了哪一步，但不清楚弹窗并未出现的原因。
- **SIEM**：负责捕获后端安全事件，然而破坏通行密钥采用的失败往往发生在客户端向后端发出请求之前。

下图展示了这些独立孤岛与那些未获解答的问题，以及通行密钥登录真正发生的客户端盲区之间的关系：

上述每一款工具在其领域内均为佼佼者，但没有一款能独立回答上述问题。这些疑问正处于各工具间的盲区中。[三种 Conditional UI 测量点](https://www.corbado.com/passkey-benchmark-2026/conditional-ui-usage)说明了盲区之大：服务器端测得的通行密钥成功率近乎完美，达到 97-99%；向用户展示的登录完成率为 90-95%；但用户首次在自动建议交互中出现退出的比例高达 55-90%。对于第一点和最后一点间 35 个百分点的落差，标准的后端工具是无法洞察的。

[Corbado Observe](https://www.corbado.com/observe) 是目前唯一能够将上述分类可见信息整合为一的产品。它获取前端平台所拥有的设备上下文和完整的客户端认证流程，将其与 FIDO 服务器记录的凭据结果相结合，进而对 APM 堆栈无法解释的故障模式进行分类，最终通过单一漏斗和单用户时间线呈现。这一监控层通过轻量级 SDK 提供，能够部署在任何 [WebAuthn 服务器](https://www.corbado.com/blog/webauthn-server-implementation)之上，无论底层 CIAM 如何，均无需进行 IdP 迁移：

- **漏斗与旅程分析**：跨越注册、登录、降级和追加等流程的决策点可视度，并按设备、操作系统、浏览器群组提供流失率剖析——这解答了“为什么用户会在注册时流失”。
- **单用户调试时间线**：搜索用户，重播流程，查看导致单次故障的确切分支切换——将调试时间从约 14 天缩短至 5 分钟。
- **准备就绪洞察**：按队列和部署阶段分类的浏览器、操作系统、OEM 和[认证器](https://www.corbado.com/glossary/authenticator)的准备就绪状态，使得拦截与放行决策均有数据支撑，而不是陷入被动应对。
- **智能错误分类**：能精准区分用户中止、生物识别超时、[密码管理器](https://www.corbado.com/blog/passkeys-vs-password-managers)干扰、反复取消行为以及真实的设备不兼容问题。自动归类 100 多种 WebAuthn 错误类型。
- **利益相关者报告**：通过向 CFO 展示[短信成本](https://www.corbado.com/blog/sms-cost-reduction-passkeys)的削减和转化率的提高，辅以对部署模式及下一步修复方案的 AI 辅助分析仪表板——解答了“你能向管理层展示其影响力吗？”的难题。

Corbado Observe 采用纯 UUID 的零 PII 架构（符合 GDPR 标准），通过这一层，前面的四大董事会问题转化为可测量的关键绩效指标 (KPI)。

### 4.4 降级与恢复层

即便是处于高级别 (Advanced)，大约仍有 11% 的尝试在初次登录时无法完成通行密钥验证流程。后备降级层必须接受这一现实，但无需默认退回到密码验证。在 50 万 MAU 规模下奏效的模式有：

- **通过二维码的跨设备验证**：填补 Windows 的空白，将桌面端桥接至已存有通行密钥的手机。
- **魔术链接或电子邮件 OTP**：作为辅助因素保留，并进行刻意的体验控制，确保其使用率控制在月登录总量的 5% 以内。
- **以淘汰为目的的 SMS OTP**：仅针对标记的高风险事件强制执行，而不是作为无密码的首要替代方案，从而保障规模化后 60-90% 的短信费用降低。
- **通过已验证辅助邮箱或[身份证明](https://www.corbado.com/blog/digital-identity-guide)进行账户恢复**：避免陷入摧毁客服团队生产力的[安全密钥](https://www.corbado.com/glossary/security-key)重置死循环。

## 5. 大规模无密码的 TCO

只关注许可费用的采购评估，通常会将大规模部署无密码验证的真实成本低估一个数量级。对于 50 万 MAU，推动总拥有成本 (TCO) 的三大因素是平台许可费、实施工作量和持续维护成本。

平台费用差异极大。据行业公布的企业合同情况，在 50 万 MAU 下，[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) 每月收取 1.5 万至 3 万美元。支持通行密钥的 [Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito) Essentials 等级约为每月 7300 美元，但隐藏了部分工程开销。Stytch B2C Essentials 和 Clerk 的价格分别在每月 4900 美元和 9000 美元左右。

真正被忽视的成本是实施工作量。在 50 万 MAU 规模下原生在 CIAM 上构建通行密钥系统，大约需要 25-30 个个人月：其中产品端约 5.5 个人月，开发端约 14 个人月，QA 端约 8 个人月。配备预设通行密钥 UI 的平台可将此时间压缩到 5-10 个人月，但仍需要团队投入精力优化采用率。像 Ory 这种以 API 优先的平台则需要从头构建所有的 UX。

持续维护则是 TCO 中隐藏的乘数。通行密钥流程需要不断应对新版操作系统、浏览器更新和 OEM 专属 Bug 并进行回归测试。在发布后的运营阶段，每年需预留约 1.5 名全职人力，以处理发布管理、跨平台测试、[元数据 (AAGUID)](https://www.corbado.com/glossary/aaguid) 更新以及客服培训等事务。如果平台要求完全定制化 UI，仅前端维护部分就需要额外增加 1-2 名工程师。

## 6. 大规模无密码：自建还是购买？

对于拥有 50 万 MAU 或更多用户的组织而言，极少会面临“购买全新 CIAM”的抉择。因为当前的 CIAM 已经深度整合在计费、风控、营销以及分析系统中了。真正的抉择在于高出一层的地方：是在内部构建编排与可观察性层，还是采用专业的覆盖层产品。

在 50 万 MAU 的规模下，编排层的[自建与购买的经济学](https://www.corbado.com/blog/passkeys-buy-vs-build-guide)始终倾向于通过采用专业产品来推进普及。自主开发路径将耗费 25-30 个个人月，此后每年还需 1.5-3 个人力投入运营，且往往由于团队无法跟上[浏览器](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill)和操作系统的发版节奏，通行密钥登录率通常会停滞在基准或托管的水平。相反，使用覆盖层可以使集成周期缩短至数周，同时系统可持续继承生态系统进化所带来的优化红利。

对于那些已经原生搭载通行密钥、却停滞于基准水平的组织来说，“自建与购买”的计算方式也有所不同。更具杠杆效应的做法是先引入可观察层，定位流失点，再据此决定余下的差距是由内部弥合，还是通过购买编排覆盖层解决。

## 7. 大规模 B2C 无密码的发布手册

要想在 50 万 MAU 下稳定步入高级型阶梯，行之有效的部署方式通常遵循以下四个阶段：

1. **监控先行**：在更改任何提示界面前，先部署[认证可观察性工具](https://www.corbado.com/blog/authentication-observability)。捕获当前的基准阶段状态，细分为操作系统、浏览器和凭据提供商群体；这样，后续的每次改进都有真实的数据曲线作为参照，而不是仅靠高层的预估。
2. **细分设备群体**：使用[客户端能力](https://www.corbado.com/blog/webauthn-client-capabilities)探测对用户进行细分。识别出 Windows、[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) 和 [iOS](https://www.corbado.com/blog/webauthn-errors) 等子人群及其特定的故障模式。
3. **推出智能提示与 Conditional Create**：将每个群体路由至回报率最高的注册路径中。对于基准测试以及自身监控显示注定会失败的环境，抑制提示弹出。在底层支持的情况下，将依赖密码管理器的成功登录自动转化为通行密钥的静默注册。
4. **转向通行密钥优先的返回流程**：当注册率达到 65% 以上且使用率稳步攀升时，将回归用户的默认操作切换为[一键式的 (one-tap)](https://docs.corbado.com/corbado-connect/features/one-tap-login) 通行密钥身份验证，同时为新设备配备标识符优先的恢复流程。这就是那条足以撼动[短信 OTP 成本](https://www.corbado.com/blog/sms-cost-reduction-passkeys)曲线的关键阶梯。

## 8. 结论

大规模 B2C 无密码化是一个编排层面的挑战，而不是一个换用哪家 CIAM 的问题。2026 年的供应商市场已经填平了 WebAuthn 支持方面的鸿沟，但能否将[通行密钥登录率](https://www.corbado.com/kpi/passkey-usage-rate)从 5% 提高到 60% 以上，关键在于搭载在 IdP 之上的编排和可观察层。在 50 万 MAU 时，这就是处于停滞的试点项目与每年能节省 5 到 10 万美元短信费用、提升结账转化率，并消除最大的[账户接管](https://www.corbado.com/glossary/account-takeover)隐患的成功变革之间的鸿沟。

对于已运行 CIAM 的财富 500 强企业买家而言，最具投资回报率的策略是实施监控、细分群体和层级编排——而不是重构搬家。[Corbado Observe](https://www.corbado.com/observe) 让您当前的阶段进度一目了然；[Corbado Connect](https://www.corbado.com/connect) 则能在现有 CIAM 基础上补齐通向“高级型”表现的短板。二者合力，将大规模无密码从采购PPT上的蓝图变成了已部署落实的 KPI。

## 常见问题

### 大规模 B2C 无密码认证到底需要什么？

大规模 B2C 无密码认证需要四个堆叠层：作为记录系统的 CIAM，一个在提示 WebAuthn 之前对设备、操作系统、浏览器和凭据提供商进行分类的 passkey 编排层，一个捕获客户端操作的监控层，以及一个为无法完成 passkey 流程的环境提供降级方案的后备层。大多数 CIAM 平台只提供第一层，这就是为什么原生部署的采用率往往停滞在 5% 到 10% 左右。

### 为什么在 50 万 MAU 的情况下，B2C 无密码部署的采用率会停滞不前？

通用的 CIAM 无密码 UI 对所有用户的提示都是一样的，但根据 Corbado Passkey Benchmark 2026 的数据，Web passkey 的首次注册率在 iOS 上为 49-83%，而在 Windows 上则降至 25-39%。如果没有设备栈分层、智能提示和标识符优先的恢复机制，即使平台在技术上支持 WebAuthn，平均通行密钥登录率也只能维持在 5% 到 10% 左右。

### 在 50 万 MAU 的情况下，从零开始构建 B2C 无密码认证的总拥有成本 (TCO) 是多少？

在拥有 50 万 MAU 的 CIAM 平台上原生构建通行密钥（passkeys），通常需要在产品、开发和 QA 团队投入 25-30 个人月，加上每年 1.5 个人力（FTE）用于持续维护。在此规模下，平台费用从 Stytch B2C Essentials 的每月约 4900 美元，到 Auth0 企业合同的每月 1.5 万至 3 万美元不等。支持 passkey 的 Cognito Essentials 每月约 7300 美元，Clerk 约 9000 美元。隐藏的成本在于，随着 iOS、Android、Windows 和 macOS 发布更新，需要进行跨平台的反复测试。

### 哪种架构模式最适合 100 万以上用户的无密码认证？

在拥有 100 万以上用户的情况下，主流模式是 CIAM 加上 passkey 编排覆盖层。CIAM 继续作为记录系统，而编排层处理设备分类、Conditional Create、标识符优先恢复和采用情况分析。这避免了用户数据库的迁移，保留了现有的 SIEM 和 APM 投资，并实现了随规模复利的 60% 到 90% 的 SMS 成本降低。