---
url: 'https://www.corbado.com/hi/blog/passwordless-b2c-at-scale'
title: 'बड़े पैमाने पर B2C के लिए पासवर्डलेस: 2026 गाइड'
description: 'बड़े पैमाने पर B2C के लिए पासवर्डलेस को समझाया गया है। 500k+ MAU एंटरप्राइज़ परिनियोजन के लिए संदर्भ वास्तुकला (reference architecture), TCO और पासकी (passkey) अपनाने की जानकारी।'
lang: 'hi'
author: 'Vincent Delitz'
date: '2026-05-19T11:50:14.053Z'
lastModified: '2026-05-19T12:28:24.423Z'
keywords: 'बड़े पैमाने पर b2c के लिए पासवर्डलेस, पासवर्डलेस ऑथेंटिकेशन, b2c पासकी एंटरप्राइज़, पासवर्डलेस ciam, 500k mau पासकी, पासकी ऑर्केस्ट्रेशन'
category: 'Passkeys Strategy'
---

# बड़े पैमाने पर B2C के लिए पासवर्डलेस: 2026 गाइड

## Key Facts

- **बड़े पैमाने पर पासवर्डलेस 5-10% passkey लॉगिन दर पर रुक जाता है** जब टीमें केवल CIAM के नेटिव WebAuthn API पर निर्भर होती हैं, चाहे अंतर्निहित प्लेटफ़ॉर्म Auth0, Cognito, Ping Identity या Clerk ही क्यों न हो।
- **पहली कोशिश में वेब passkey एनरोलमेंट** iOS पर 49-83% से लेकर Windows पर 25-39% तक होता है, Corbado Passkey Benchmark 2026 के अनुसार - यह 2x का अंतर है जिसे फ्लैट CIAM UIs अनदेखा कर देते हैं।
- **एडवांस्ड रोलआउट आकार** (ऑटोमैटिक क्रिएशन और आइडेंटिफ़ायर-फर्स्ट रिकवरी के साथ passkey-फर्स्ट रिटर्न फ़्लो) उसी 89% वेब रेडीनेस सीलिंग पर passkey लॉगिन दर को 60% से ऊपर ले जाता है।
- **500k MAU पर**, 60-90% SMS OTP की कमी का मतलब है सालाना USD 50k-100k या उससे अधिक की बचत, जिसमें ऑर्केस्ट्रेशन लेयर आमतौर पर पहली तिमाही के भीतर ही अपनी लागत वसूल कर लेती है।
- CIAM प्लेटफ़ॉर्म में **नेटिव रूप से पासवर्डलेस बनाने** के लिए प्रोडक्ट, डेवलपमेंट और QA में लगभग 25-30 FTE-महीने लगते हैं, साथ ही क्रॉस-प्लेटफ़ॉर्म रखरखाव के लिए हर साल 1.5 FTE की आवश्यकता होती है।
- **2026 के CIAM तुलना में कोई भी वेंडर** डिफ़ॉल्ट रूप से डिवाइस-अवेयर प्रॉम्प्टिंग, आइडेंटिफ़ायर-फर्स्ट रिकवरी और Conditional Create को नेटिव रूप से नहीं देता है - ये क्षमताएं एक अलग ऑर्केस्ट्रेशन लेयर में होती हैं।

## 1. परिचय: बड़े पैमाने पर B2C के लिए पासवर्डलेस

बड़े पैमाने पर B2C के लिए पासवर्डलेस अब कोई रणनीतिक विकल्प नहीं है - यह CIAM टीमों के लिए एक महत्वपूर्ण आवश्यकता है। 2M कुल बेस पर 500k मासिक सक्रिय उपयोगकर्ताओं (MAU) पर, [passkey अपनाने](https://www.corbado.com/blog/passkey-adoption-business-case) का हर प्रतिशत बिंदु मापने योग्य [SMS 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 डिप्लॉयमेंट जिन्होंने "passkeys सक्षम" किए हैं, अभी भी देखते हैं कि 90% दैनिक लॉगिन पासवर्ड या SMS OTP के माध्यम से होते हैं।

यह गाइड बताती है कि जेनेरिक CIAM पासवर्डलेस रोलआउट बड़े पैमाने पर क्यों रुक जाते हैं, चार-परतों वाला संदर्भ आर्किटेक्चर (reference architecture) जो लगातार [passkey लॉगिन दर](https://www.corbado.com/kpi/passkey-usage-rate) को 60% से ऊपर ले जाता है, और एक Fortune 500 खरीदार को 500k MAU पर कुल स्वामित्व लागत (TCO) के लिए क्या योजना बनानी चाहिए।

## 2. जेनेरिक CIAM पासवर्डलेस बड़े पैमाने पर क्यों रुक जाता है

पासवर्डलेस के इर्द-गिर्द खरीद की कहानी अब एक जैसी हो गई है: 2026 में हर CIAM एक [WebAuthn](https://www.corbado.com/glossary/webauthn) API प्रदान करता है, हर वेंडर अपने टियर मैट्रिक्स में "पासवर्डलेस" बेचता है, और हर एनालिस्ट रिपोर्ट बेसलाइन आवश्यकता के रूप में passkeys को शामिल करती है। 500k MAU पर मापा गया परिणाम सुसंगत है। [Passkey लॉगिन दर](https://www.corbado.com/kpi/passkey-usage-rate) लगभग 5% के आसपास मंडराती है, SMS OTP वॉल्यूम मुश्किल से हिलता है, और अनुमानित बचत नहीं मिलती है। इसका कारण अक्सर संरचनात्मक होता है।

### 2.1 Passkey अपनाने की भ्रांति

Corbado [Passkey Benchmark 2026](https://www.corbado.com/blog/world-passkey-day-passkey-benchmark-2026) एक ही 89% वेब रेडीनेस सीलिंग पर चार रोलआउट व्यवस्थाओं को मापता है। सेटिंग्स-ओनली उपलब्धता 1% से कम की passkey लॉगिन दर उत्पन्न करती है। एक साधारण पोस्ट-लॉगिन नज (nudge) इसे लगभग 4-5% तक ले जाता है। डिवाइस-अवेयर प्रॉम्प्टिंग के साथ एक अनुकूलित (optimized) एनरोलमेंट 23% तक चढ़ जाता है। ऑटोमैटिक क्रिएशन और आइडेंटिफ़ायर-फर्स्ट रिकवरी के साथ एक passkey-फर्स्ट रिटर्न फ़्लो 60% से अधिक हो जाता है। नीचे का CIAM इन नंबरों को नहीं बदलता है। इसके ऊपर बैठा प्रॉम्प्ट लॉजिक, डिवाइस क्लासिफिकेशन और लॉगिन-एंट्री डिज़ाइन यह काम करता है।

एक ही [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) या [Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito) किरायेदार (tenant) को चलाने वाला एक ही उद्यम इस सीढ़ी के दोनों छोर पर उतर सकता है, जो इस बात पर निर्भर करता है कि उसकी टीम कस्टम फ्रंटएंड में बेंचमार्क द्वारा प्रलेखित ऑर्केस्ट्रेशन पैटर्न को शिप करती है या नहीं। यही अपनाने की भ्रांति (adoption fallacy) है: "प्लेटफ़ॉर्म passkeys का समर्थन करता है" का अर्थ "प्लेटफ़ॉर्म बड़े पैमाने पर [passkey अपनाने](https://www.corbado.com/blog/passkey-adoption-business-case) को प्राप्त करता है" के बराबर नहीं है।

### 2.2 डिवाइस-स्टैक विखंडन

एक पारंपरिक B2C उपभोक्ता आधार पर 500k MAU पर, डिवाइस की आबादी बिल्कुल भी सपाट नहीं है। [Corbado Passkey Benchmark 2026](https://www.corbado.com/passkey-benchmark-2026/passkey-enrollment-rate) पहली कोशिश में वेब एनरोलमेंट को [iOS](https://www.corbado.com/blog/webauthn-errors) पर 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 में passkey सेविंग 2025 के अंत में ही आई है। एक यथार्थवादी गणना को इन पहलुओं को शामिल करना होगा, जिसमें स्मार्ट प्रॉम्प्टिंग और मोबाइल और डेस्कटॉप के बीच क्रॉस-डिवाइस उपयोग शामिल है।

### 2.3 प्री-आइडेंटिफ़ायर अंधापन

उपभोक्ता प्रमाणीकरण में, उपयोगकर्ता तब तक गुमनाम रहता है जब तक वे ईमेल या यूज़रनेम टाइप नहीं करते। यदि कोई पासवर्डलेस प्रॉम्प्ट उन्हें भ्रमित करता है या उस बिंदु तक पहुँचने से पहले कोई [password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) ओवरले ऑटोफ़िल को ब्लॉक कर देता है, तो बैकएंड कुछ भी रिकॉर्ड नहीं करता है। मानक CIAM लॉग [क्लाइंट-साइड टेलीमेट्री](https://www.corbado.com/observe) के लिए नहीं बनाए गए थे, इसलिए जो विफलताएं बड़े पैमाने पर अपनाने में बाधा डालती हैं, वे बैकएंड लॉगिंग सहित IDP के रिपोर्टिंग फ्रेम के बाहर बैठती हैं।

## 3. 500k MAU पर Passkey एडॉप्शन लैडर

2M उपयोगकर्ता आधार पर 500k MAU वाले B2C परिनियोजन के लिए, परिचालन लक्ष्य CIAM को री-प्लेटफ़ॉर्म करने के बजाय एडॉप्शन लैडर (अपनाने की सीढ़ी) पर चढ़ना है। प्रत्येक स्तर एक विशिष्ट रोलआउट आकार से मेल खाता है, न कि किसी अलग वेंडर से।

**Passkey एडॉप्शन लैडर (Corbado Passkey Benchmark 2026)**

| **रोलआउट आकार** | **एनरोलमेंट** | **उपयोग** | **Passkey लॉगिन दर** |
| ---------------------------------------- | -------------- | --------- | ---------------------- |
| **सेटिंग्स-ओनली उपलब्धता** (Passive) | \~4% | \~5% | &lt;1% |
| **सिंपल पोस्ट-लॉगिन नज** (Baseline) | \~25% | \~20% | \~4-5% |
| **अनुकूलित एनरोलमेंट** (Managed) | \~65% | \~40% | \~23% |
| **Passkey-फर्स्ट रिटर्न फ़्लो** (Advanced) | \~80% | \~95% | &gt;60% |

गैर-रैखिक छलांग तब स्पष्ट हो जाती है जब समान रेडीनेस सीलिंग को चार रोलआउट आकारों के खिलाफ प्लॉट किया जाता है:

अधिकांश CIAM-नेटिव रोलआउट बेसलाइन (Baseline) स्तरों पर समाप्त होते हैं क्योंकि आउट-ऑफ़-द-बॉक्स पासवर्डलेस UIs यही प्रदान करते हैं: एक सिंगल पोस्ट-लॉगिन टॉगल, कोई डिवाइस-अवेयर प्रॉम्प्टिंग नहीं, नए उपकरणों के लिए कोई आइडेंटिफ़ायर-फर्स्ट रिकवरी नहीं और सेव्ड-पासवर्ड साइन-इन के बाद कोई ऑटोमैटिक क्रिएशन नहीं। Managed और Advanced स्तरों तक चढ़ने के लिए खंडित (segmented) एनरोलमेंट नज, [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 रिकॉर्ड का सिस्टम बना रहता है। एक passkey ऑर्केस्ट्रेशन ओवरले बुद्धिमान प्रॉम्प्टिंग को संभालता है। एक ऑब्जर्वेबिलिटी परत क्लाइंट-साइड सेरेमनी को कैप्चर करती है। एक फ़ॉलबैक परत उन वातावरणों को अवशोषित करती है जो आज passkey फ़्लो को पूरा नहीं कर सकते हैं। नीचे दिए गए अनुभाग प्रत्येक परत का विवरण देते हैं।

### 4.1 आइडेंटिटी लेयर: रिकॉर्ड के सिस्टम के रूप में CIAM

CIAM उपयोगकर्ता रिकॉर्ड, सत्र (session), OAuth/OIDC टोकन, [सोशल लॉगिन](https://www.corbado.com/glossary/social-login), MFA नीति और सहमति (consent) रखता है। 500k 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 बने हुए हैं। यहाँ का चुनाव लाइसेंसिंग और इकोसिस्टम एकीकरण के लिए परिणामी है, लेकिन स्वयं [passkey अपनाने](https://www.corbado.com/blog/passkey-adoption-business-case) के लिए नहीं। मूल्य निर्धारण टियर, AI एजेंट आइडेंटिटी समर्थन और 500k MAU पर TCO के लिए पूर्ण [2026 CIAM वेंडर मूल्यांकन](https://www.corbado.com/blog/best-ciam-solutions) देखें।

### 4.2 Passkey ऑर्केस्ट्रेशन लेयर

ऑर्केस्ट्रेशन लेयर वह जगह है जहां बड़े पैमाने पर पासवर्डलेस की जीत या हार होती है। यह WebAuthn प्रॉम्प्ट के फायर होने से पहले प्रमाणीकरण घटना को इंटरसेप्ट करता है, डिवाइस के हार्डवेयर, OS, ब्राउज़र और क्रेडेंशियल-प्रोवाइडर स्टैक को वर्गीकृत करता है और उपयोगकर्ता को उस वातावरण के अनुकूल यात्रा में निर्देशित करता है।

व्यवहार में, 500k MAU पर ऑर्केस्ट्रेशन लेयर लगभग हमेशा एक **कस्टम फ्रंटएंड इम्प्लीमेंटेशन** होता है जो CIAM के सामने बैठता है और एक कस्टम लॉगिन UI रेंडर करता है। अंतर्निहित CIAM क्रेडेंशियल स्टोरेज, सत्र और OAuth/OIDC को संभालना जारी रखता है, लेकिन टीम लॉगिन एंट्री पॉइंट, डिवाइस-अवेयर प्रॉम्प्ट लॉजिक और रिकवरी फ़्लो की मालिक होती है। इसका कारण संरचनात्मक है: एंटरप्राइज़ B2C टीमों को ब्रांडिंग, रूपांतरण-महत्वपूर्ण कॉपी, A/B परीक्षण और डिवाइस-सेगमेंटेशन नियमों पर पूर्ण नियंत्रण की आवश्यकता होती है जो यह निर्धारित करते हैं कि कौन सा उपयोगकर्ता कौन सा प्रॉम्प्ट देखता है। एक वेंडर-रेंडर किया गया लॉगिन पेज शायद ही कभी बड़े पैमाने पर अनुकूलन के उस स्तर को सहन करता है।

ठोस पैटर्न जिन्हें कस्टम ऑर्केस्ट्रेशन लेयर को लागू करना चाहिए:

- **डिवाइस और क्षमता वर्गीकरण**: WebAuthn प्रॉम्प्ट जारी करने से पहले डिवाइस हार्डवेयर, OS, ब्राउज़र और क्रेडेंशियल प्रोवाइडर की जांच करना, ताकि जिन वातावरणों को बेंचमार्क कहता है कि विफल हो जाएंगे, उनके उपयोगकर्ताओं को डेड-एंड सेरेमनी से दूर किया जा सके।
- **Conditional create**: समर्थित स्टैक पर एक सफल पासवर्ड-मैनेजर-असिस्टेड साइन-इन के बाद स्वचालित रूप से passkey रजिस्टर करना, iOS और व्यवहार्य macOS कॉन्फ़िगरेशन पर स्पष्ट एनरोलमेंट प्रॉम्प्ट को पूरी तरह से हटाना।
- **वन-टैप रिटर्न फ़्लो**: प्राइवेसी-रिस्पेक्टिंग डिवाइस ट्रस्ट सिग्नल्स के माध्यम से लौटने वाले उपकरणों को पहचानना और अगली यात्रा पर सिंगल-टैप passkey प्रमाणीकरण की पेशकश करना।
- **आइडेंटिफ़ायर-फर्स्ट रिकवरी**: Windows उपयोगकर्ताओं को, जहां बेंचमार्क मापता है कि [40-65% आइडेंटिफ़ायर-फर्स्ट passkey सफलताएं](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% ब्रिज करते हैं।
- **क्रमिक रोलआउट (Gradual rollout)**: OS संस्करण, भूगोल या उपयोगकर्ता खंड के अनुसार लक्षित करना और ऐप रिलीज़ के बिना स्मार्ट फ़ॉलबैक शिप करना।

इस लेयर को इन-हाउस बनाना 500k MAU पर प्रमुख पैटर्न है क्योंकि अधिकांश बड़े B2C डिप्लॉयमेंट पहले से ही एक परिष्कृत (sophisticated) फ्रंटएंड स्टैक और एक इन-हाउस डिज़ाइन सिस्टम संचालित करते हैं जिसे लॉगिन फ़्लो को इनहेरिट करना चाहिए। इसका ट्रेड-ऑफ़ (व्यापार-बंद) ब्राउज़र, OS और क्रेडेंशियल-प्रोवाइडर अपडेट के साथ तालमेल बनाए रखने की चल रही इंजीनियरिंग लागत है। उन टीमों के लिए जो इस परत को बनाने के बजाय खरीदना पसंद करते हैं, [Corbado Connect](https://www.corbado.com/connect) उपयोगकर्ता-डेटाबेस माइग्रेशन के बिना किसी भी CIAM के शीर्ष पर एक ओवरले के रूप में समान ऑर्केस्ट्रेशन पैटर्न को प्रोडक्टाइज़ करता है। दोनों में से कोई भी रास्ता [passkey एनरोलमेंट](https://www.corbado.com/blog/passkey-creation-best-practices) को Advanced-परिदृश्य की 80%+ सीलिंग की ओर ले जाता है और 60-90% [SMS OTP लागत](https://www.corbado.com/blog/sms-cost-reduction-passkeys) कटौती को अनलॉक करता है जो बड़े पैमाने पर जुड़ती है।

### 4.3 ऑथेंटिकेशन ऑब्जर्वेबिलिटी लेयर

500k MAU पर, पासवर्डलेस चलाने वाले हर [CISO](https://www.corbado.com/glossary/ciso), CTO और प्रोडक्ट ओनर से जो प्रश्न पूछा जाता है, वह सीधा होता है: "हमारा एंड-टू-एंड साइन-इन सफलता दर क्या है? उपयोगकर्ता एनरोलमेंट में क्यों ड्रॉप कर रहे हैं? क्या हमें 10% से 50% तक स्केल करना चाहिए? क्या आप लीडरशिप को प्रभाव दिखा सकते हैं?" आज के अधिकांश बड़े B2C डिप्लॉयमेंट में ईमानदार उत्तर यह है कि "हमें नहीं पता" - इसलिए नहीं कि डेटा मौजूद नहीं है, बल्कि इसलिए कि यह पाँच अलग-अलग प्रणालियों में रहता है जिन्हें कभी भी passkey सेरेमनी के आसपास जोड़ने के लिए डिज़ाइन नहीं किया गया था।

सामान्य [एंटरप्राइज़ स्टैक](https://www.corbado.com/blog/integrate-passkeys-enterprise-stack) प्रत्येक टुकड़े को व्यक्तिगत रूप से कवर करता है:

- **फ्रंटएंड कंटेंट और एक्सपीरियंस प्लेटफ़ॉर्म** मार्केटिंग लेयर पर पेजव्यू, कंटेंट वेरिएंट और फ़नल इवेंट देखता है, लेकिन WebAuthn सेरेमनी को नहीं।
- **FIDO या WebAuthn सर्वर** क्रेडेंशियल रजिस्ट्रेशन और [assertion](https://www.corbado.com/glossary/assertion) परिणाम देखता है, लेकिन यह नहीं कि उपयोगकर्ता के डिवाइस पर पहले या बाद में क्या हुआ।
- **बैकएंड APM** API लेटेंसी और ट्रेस देखता है, लेकिन यूज़र एबॉर्ट को बायोमेट्रिक टाइमआउट से अलग नहीं बता सकता।
- **आइडेंटिटी प्रोवाइडर के ऑर्केस्ट्रेशन लॉग** यह देखते हैं कि कौन सी नीति फायर हुई और उपयोगकर्ता किस फ़्लो स्टेप तक पहुंचा, लेकिन यह नहीं कि ब्राउज़र ओवरले कभी क्यों नहीं दिखाई दिया।
- **SIEM** बैकएंड सुरक्षा घटनाओं को देखता है, लेकिन वे विफलताएं जो passkey अपनाने को नष्ट कर देती हैं, वे किसी भी बैकएंड अनुरोध जारी होने से पहले क्लाइंट पर होती हैं।

नीचे दिया गया आरेख अनुत्तरित प्रश्नों और उस सतह के खिलाफ साइलो (silos) का नक्शा बनाता है जहां वास्तव में passkey साइन-इन होता है:

इनमें से प्रत्येक टूल अपनी श्रेणी में सर्वश्रेष्ठ है, फिर भी कोई भी अकेले उपरोक्त प्रश्नों का उत्तर नहीं देता है। प्रश्न उनके बीच के गैप में बैठते हैं। [तीन Conditional UI माप बिंदु](https://www.corbado.com/passkey-benchmark-2026/conditional-ui-usage) उस गैप के पैमाने को दर्शाते हैं: सर्वर-साइड passkey सफलता 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 माइग्रेशन के:

- **फ़नल और जर्नी एनालिटिक्स**: एनरोलमेंट, साइन-इन, फ़ॉलबैक और अपेंड फ़्लो में निर्णय-बिंदु दृश्यता, जिसमें डिवाइस, OS और ब्राउज़र कोहोर्ट (cohort) द्वारा ड्रॉप-ऑफ़ विभाजित है - "उपयोगकर्ता एनरोलमेंट में क्यों ड्रॉप कर रहे हैं" का उत्तर।
- **प्रति-उपयोगकर्ता डिबग टाइमलाइन**: एक उपयोगकर्ता को खोजें, सेरेमनी को फिर से चलाएँ, एक विफलता के पीछे सटीक ब्रांच ट्रांज़िशन देखें - डिबगिंग का समय \~14 दिन से घटकर \~5 मिनट हो जाता है।
- **रेडीनेस इनसाइट्स**: ब्राउज़र, OS, OEM और [authenticator](https://www.corbado.com/glossary/authenticator) रेडीनेस कोहोर्ट और रोलआउट चरण द्वारा विभाजित, ताकि सप्रेशन (suppression) और रैंप (ramp) निर्णय प्रतिक्रियाशील होने के बजाय डेटा-समर्थित हों।
- **बुद्धिमान त्रुटि वर्गीकरण**: यूज़र एबॉर्ट को बायोमेट्रिक टाइमआउट, [password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) हस्तक्षेप, बार-बार रद्द करने वालों और वास्तविक डिवाइस असंगतियों से अलग करता है, जिसमें 100+ WebAuthn त्रुटि प्रकारों का स्वचालित वर्गीकरण होता है।
- **हितधारक रिपोर्टिंग**: CFO को [SMS लागत](https://www.corbado.com/blog/sms-cost-reduction-passkeys) बचत और रूपांतरण सुधार साबित करने वाले डैशबोर्ड, रोलआउट पैटर्न और अगले फ़िक्सेस के AI-सहायता प्राप्त विश्लेषण के साथ - "क्या आप लीडरशिप को प्रभाव दिखा सकते हैं" का उत्तर।

Corbado Observe एक UUID-ओनली, शून्य-PII आर्किटेक्चर (GDPR कंप्लायंट) के साथ शिप होता है और यह वह परत है जो उपरोक्त चार बोर्डरूम प्रश्नों को मापने योग्य KPIs में बदल देती है।

### 4.4 फ़ॉलबैक और रिकवरी लेयर

Advanced स्तर पर भी, लगभग 11% प्रयास पहली कोशिश में passkey फ़्लो को पूरा नहीं करेंगे। फ़ॉलबैक लेयर को डिफ़ॉल्ट रूप से पासवर्ड पर वापस गिरे बिना उस वास्तविकता को स्वीकार करना चाहिए। 500k MAU पर काम करने वाले पैटर्न:

- **QR के माध्यम से क्रॉस-डिवाइस ऑथेंटिकेशन**: Windows गैप को कवर करता है और डेस्कटॉप से उस फ़ोन से जुड़ता है जिसमें पहले से ही एक passkey होता है।
- **मैजिक लिंक या ईमेल OTP**: एक जानबूझकर घर्षण (friction) बजट के साथ द्वितीयक कारक के रूप में रखा गया, ताकि उपयोग मासिक लॉगिन के 5% से कम रहे।
- **सनसेट पाथ के रूप में SMS OTP**: प्राथमिक पासवर्डलेस प्रतिस्थापन के रूप में नहीं, बल्कि केवल फ़्लैग की गई जोखिम घटनाओं पर लागू किया जाता है, ताकि बड़े पैमाने पर 60-90% लागत में कमी को कैप्चर किया जा सके।
- **सत्यापित द्वितीयक ईमेल या [आइडेंटिटी प्रूफ़िंग](https://www.corbado.com/blog/digital-identity-guide) के माध्यम से अकाउंट रिकवरी**: उन [security key](https://www.corbado.com/glossary/security-key) रीसेट लूप से बचाती है जो सपोर्ट उत्पादकता को नष्ट कर देते हैं।

## 5. बड़े पैमाने पर पासवर्डलेस का TCO (कुल स्वामित्व लागत)

लाइसेंस शुल्क पर केंद्रित खरीद मूल्यांकन बड़े पैमाने पर पासवर्डलेस की वास्तविक लागत को लगभग दस गुना कम आंकते हैं। 500k MAU पर तीन ड्राइवर प्लेटफ़ॉर्म फ़ीस, कार्यान्वयन (implementation) प्रयास और चल रहे रखरखाव (maintenance) हैं।

प्लेटफ़ॉर्म फ़ीस व्यापक रूप से भिन्न होती है। उद्योग-रिपोर्ट किए गए एंटरप्राइज़ कॉन्ट्रैक्ट्स पर 500k MAU पर [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) USD 15k-30k/महीने पर बैठता है। [Cognito का](https://www.corbado.com/blog/passkeys-amazon-cognito) passkey-सक्षम Essentials टियर लगभग USD 7.3k/महीने में आता है, लेकिन इंजीनियरिंग ओवरहेड को छुपाता है। Stytch का B2C Essentials और Clerk क्रमशः लगभग USD 4.9k और USD 9k पर आते हैं।

कार्यान्वयन प्रयास वह लागत है जिसे अनदेखा कर दिया जाता है। 500k MAU पर CIAM प्लेटफ़ॉर्म पर नेटिव रूप से passkeys बनाने में लगभग 25-30 FTE-महीने लगते हैं: उत्पाद में लगभग 5.5 FTE-महीने, विकास में 14 FTE-महीने और QA में 8 FTE-महीने। प्री-बिल्ट passkey UI वाले प्लेटफ़ॉर्म इसे 5-10 FTE-महीनों तक संकुचित करते हैं, लेकिन फिर भी एडॉप्शन ऑप्टिमाइज़ेशन कार्य की मांग करते हैं। Ory जैसे API-फ़र्स्ट प्लेटफ़ॉर्म के लिए सभी UX को स्क्रैच से बनाने की आवश्यकता होती है।

चल रहा रखरखाव छिपा हुआ TCO मल्टीप्लायर है। Passkey सेरेमनी को लगातार नए OS रिलीज़, ब्राउज़र अपडेट और OEM-विशिष्ट बग्स के खिलाफ फिर से परीक्षण करने की आवश्यकता होती है। लॉन्च के बाद के संचालन के लिए प्रति वर्ष लगभग 1.5 FTE का बजट रखें: रोलआउट प्रबंधन, क्रॉस-प्लेटफ़ॉर्म रीटेस्टिंग, [मेटाडेटा](https://www.corbado.com/glossary/aaguid) अपडेट और सपोर्ट ट्रेनिंग। कस्टम UI की आवश्यकता वाले प्लेटफ़ॉर्म पर, अकेले फ्रंटएंड रखरखाव के लिए 1-2 अतिरिक्त FTE जोड़ें।

## 6. बड़े पैमाने पर पासवर्डलेस के लिए: खरीदें (Buy) बनाम बनाएं (Build)

500k MAU और उससे अधिक के संगठनों के लिए, विकल्प शायद ही कभी "एक नया CIAM खरीदें" होता है। मौजूदा CIAM पहले से ही बिलिंग, धोखाधड़ी, मार्केटिंग और एनालिटिक्स के साथ एकीकृत है। वास्तविक विकल्प एक परत ऊपर बैठता है: आंतरिक रूप से ऑर्केस्ट्रेशन और ऑब्जर्वेबिलिटी का निर्माण करें या एक विशेष ओवरले अपनाएं।

500k MAU पर ऑर्केस्ट्रेशन लेयर के लिए [खरीद-बनाम-निर्माण अर्थशास्त्र](https://www.corbado.com/blog/passkeys-buy-vs-build-guide) (buy-vs-build economics) लगातार अपनाने का पक्ष लेते हैं। आंतरिक निर्माण पथ 25-30 FTE-महीनों को अवशोषित करता है, फिर संचालन में प्रति वर्ष 1.5-3 FTEs, जिसमें passkey लॉगिन दर आमतौर पर Baseline या Managed स्तर के आसपास सीमित होती है क्योंकि टीम [ब्राउज़र](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill) और OS रिलीज़ ताल के साथ तालमेल नहीं रख सकती है। ओवरले पथ हफ्तों में मापी गई एक एकीकरण परियोजना को अवशोषित करता है, फिर इकोसिस्टम विकसित होने के साथ प्लेटफ़ॉर्म सुधारों को लगातार इनहेरिट करता है।

उन संगठनों के लिए खरीद-बनाम-निर्माण का गणित फिर से बदल जाता है, जिन्होंने पहले ही नेटिव रूप से passkeys को शिप कर दिया है और Baseline स्तर पर अटके हुए हैं। वहां, उच्च-लीवरेज चाल केवल ऑब्जर्वेबिलिटी लेयर को जोड़ना, ड्रॉप-ऑफ़ बिंदुओं को सतह पर लाना और यह तय करना है कि शेष गैप को इन-हाउस बंद किया जाए या ऑर्केस्ट्रेशन ओवरले के साथ।

## 7. बड़े पैमाने पर पासवर्डलेस B2C के लिए रोलआउट प्लेबुक

डिप्लॉयमेंट पैटर्न जो 500k MAU पर Advanced स्तर पर लगातार उतरता है, वह चार-चरणों वाले आकार का अनुसरण करता है:

1. **पहले इंस्ट्रूमेंट करें**: प्रॉम्प्ट को बदलने से पहले [ऑथेंटिकेशन ऑब्जर्वेबिलिटी](https://www.corbado.com/blog/authentication-observability) तैनात करें। OS, ब्राउज़र और क्रेडेंशियल प्रोवाइडर द्वारा खंडित वर्तमान Baseline स्तर को कैप्चर करें, ताकि हर बाद के बदलाव को कार्यकारी अनुमान के बजाय वास्तविक वक्र (curve) के खिलाफ मापा जा सके।
2. **डिवाइस आबादी को सेगमेंट करें**: [क्लाइंट क्षमताओं](https://www.corbado.com/blog/webauthn-client-capabilities) की जांच का उपयोग करके कोहोर्ट (cohort) को वर्गीकृत करें। Windows, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) और [iOS](https://www.corbado.com/blog/webauthn-errors) उप-आबादी और उनके विशिष्ट विफलता मोड को पहचानें।
3. **बुद्धिमान प्रॉम्प्टिंग और Conditional Create शिप करें**: प्रत्येक कोहोर्ट को उसके उच्चतम-उपज (highest-yield) वाले एनरोलमेंट पथ पर निर्देशित करें। उन वातावरणों पर प्रॉम्प्ट को दबाएँ जहाँ बेंचमार्क और आपकी अपनी टेलीमेट्री कहती है कि वे विफल हो जाएँगे। पासवर्ड-मैनेजर-असिस्टेड साइन-इन को स्वचालित passkey निर्माण में बदलें जहाँ स्टैक इसका समर्थन करता है।
4. **Passkey-फ़र्स्ट रिटर्न की ओर बढ़ें**: एक बार जब एनरोलमेंट 65%+ पर हो और उपयोग बढ़ रहा हो, तो लौटने वाले उपयोगकर्ताओं के लिए डिफ़ॉल्ट को नए उपकरणों के लिए आइडेंटिफ़ायर-फर्स्ट रिकवरी के साथ [वन-टैप](https://docs.corbado.com/corbado-connect/features/one-tap-login) passkey प्रमाणीकरण में पलट दें। यह वह स्तर है जहाँ [SMS OTP लागत](https://www.corbado.com/blog/sms-cost-reduction-passkeys) वक्र झुकता है।

## 8. निष्कर्ष

बड़े पैमाने पर B2C के लिए पासवर्डलेस एक ऑर्केस्ट्रेशन समस्या है, CIAM-चयन समस्या नहीं है। 2026 वेंडर लैंडस्केप ने WebAuthn समर्थन के लिए गैप को बंद कर दिया है, लेकिन 5% और 60%+ [passkey लॉगिन दर](https://www.corbado.com/kpi/passkey-usage-rate) के बीच का अंतर ऑर्केस्ट्रेशन और ऑब्जर्वेबिलिटी परतों में बैठता है जो IDP के शीर्ष पर शिप होते हैं। 500k MAU पर, यह एक रुके हुए पायलट और एक पासवर्डलेस परिवर्तन के बीच का अंतर है जो वार्षिक SMS बचत में USD 50k-100k या उससे अधिक बुक करता है, चेकआउट रूपांतरण बढ़ाता है और सबसे बड़े शेष [अकाउंट टेकओवर](https://www.corbado.com/glossary/account-takeover) वेक्टर को हटा देता है।

फॉर्च्यून 500 खरीदारों के लिए जो पहले से ही CIAM चला रहे हैं, उच्चतम-ROI चाल इंस्ट्रूमेंट, सेगमेंट और ऑर्केस्ट्रेट करना है - माइग्रेट करना नहीं। [Corbado Observe](https://www.corbado.com/observe) वर्तमान स्तर को दृश्यमान बनाता है। [Corbado Connect](https://www.corbado.com/connect) मौजूदा CIAM के शीर्ष पर Advanced स्तर तक के अंतर को बंद करता है। साथ मिलकर वे बड़े पैमाने पर पासवर्डलेस को खरीद के वादे से डिप्लॉय किए गए KPI में बदल देते हैं।

## अक्सर पूछे जाने वाले प्रश्न (FAQ)

### बड़े पैमाने पर B2C के लिए पासवर्डलेस को वास्तव में क्या चाहिए?

बड़े पैमाने पर B2C के लिए पासवर्डलेस को चार स्टैक्ड परतों की आवश्यकता होती है: रिकॉर्ड के सिस्टम के रूप में एक CIAM, एक passkey ऑर्केस्ट्रेशन परत जो WebAuthn को प्रॉम्प्ट करने से पहले डिवाइस, OS, ब्राउज़र और क्रेडेंशियल प्रदाता को वर्गीकृत करती है, एक ऑब्जर्वेबिलिटी परत जो क्लाइंट-साइड सेरेमनी को कैप्चर करती है और उन उपयोगकर्ताओं के लिए एक फ़ॉलबैक परत जो उन वातावरणों में हैं जो passkey फ़्लो को पूरा नहीं कर सकते हैं। अधिकांश CIAM प्लेटफ़ॉर्म केवल पहली परत को शिप करते हैं, यही कारण है कि नेटिव रोलआउट 5 से 10 प्रतिशत अपनाने पर रुक जाते हैं।

### 500k MAU पर पासवर्डलेस B2C रोलआउट कम अपनाने पर क्यों रुक जाते हैं?

जेनेरिक CIAM पासवर्डलेस UIs सभी उपयोगकर्ताओं को समान रूप से प्रॉम्प्ट करते हैं, लेकिन Corbado Passkey Benchmark 2026 के अनुसार, पहली कोशिश में वेब passkey एनरोलमेंट iOS पर 49-83% से लेकर Windows पर 25-39% तक होता है। डिवाइस-स्टैक सेगमेंटेशन, बुद्धिमान प्रॉम्प्टिंग और आइडेंटिफ़ायर-फर्स्ट रिकवरी के बिना, डिप्लॉयमेंट का औसत लगभग 5 से 10 प्रतिशत passkey लॉगिन दर होता है, यहाँ तक कि जब प्लेटफ़ॉर्म तकनीकी रूप से WebAuthn का समर्थन करता है।

### 500k MAU पर स्क्रैच से पासवर्डलेस B2C बनाने का TCO क्या है?

500k MAU पर CIAM प्लेटफ़ॉर्म पर नेटिव रूप से passkeys बनाने के लिए आमतौर पर उत्पाद, विकास और QA में 25-30 FTE-महीनों की आवश्यकता होती है, साथ ही चल रहे रखरखाव के लिए प्रति वर्ष 1.5 FTE। इस पैमाने पर प्लेटफ़ॉर्म फ़ीस Stytch B2C Essentials के लिए लगभग USD 4.9k प्रति माह से लेकर Auth0 एंटरप्राइज़ अनुबंधों के लिए USD 15k-30k प्रति माह तक होती है, जिसमें Cognito का passkey-सक्षम Essentials लगभग USD 7.3k और Clerk लगभग USD 9k है। छिपी हुई लागत iOS, Android, Windows और macOS द्वारा अपडेट जारी करने पर क्रॉस-प्लेटफ़ॉर्म रीटेस्टिंग है।

### 1M+ उपयोगकर्ताओं पर पासवर्डलेस के लिए कौन सा आर्किटेक्चर पैटर्न सबसे अच्छा काम करता है?

1M+ उपयोगकर्ताओं पर प्रमुख पैटर्न एक CIAM प्लस passkey ऑर्केस्ट्रेशन ओवरले है, जिसमें CIAM रिकॉर्ड का सिस्टम बना रहता है और ऑर्केस्ट्रेशन परत डिवाइस वर्गीकरण, Conditional Create, आइडेंटिफ़ायर-फर्स्ट रिकवरी और एडॉप्शन एनालिटिक्स को संभालती है। यह उपयोगकर्ता-डेटाबेस माइग्रेशन से बचाता है, मौजूदा SIEM और APM निवेश को सुरक्षित रखता है और 60-90 प्रतिशत SMS लागत में कमी को अनलॉक करता है जो बड़े पैमाने पर जुड़ती है।
