SMS OTP बनाम ऑथेंटिकेटर ऐप्स: सही MFA चुनना

क्यों MFA के तरीका के चुनाव से सपोर्ट दर्द बन जाता है

अधिकांश लोग MFA केवल तब नोटिस करते हैं जब यह फेल करता है। कोड देर से आता है, फोन सिग्नल नहीं है, या डिवाइस अपग्रेड के दौरान ऐप हट जाता है। उपयोगकर्ता लॉगिन स्क्रीन पर फंस जाता है, और जो अतिरिक्त सुरक्षा लगनी चाहिए थी वह "मैं अपना काम नहीं कर पा रहा" में बदल जाती है।

इसीलिए SMS OTP बनाम ऑथेंटिकेटर ऐप्स सिर्फ सुरक्षा की बहस नहीं है। यह एक प्रोडक्ट निर्णय है जो आपके सपोर्ट क्यू, churn जोखिम, और टीम द्वारा किए जाने वाले मैन्युअल पहचान चेक्स की मात्रा बदल देता है।

जब MFA टूटता है, तो उपयोगकर्ता आमतौर पर तीन में से एक कदम उठाते हैं: कुछ बार पुन: कोशिश करें, फ्लो छोड़ दें, या घबराकर सपोर्ट से संपर्क करें क्योंकि उन्हें लगता है कि उनका अकाउंट हैक हो गया। कारण सरल होने पर भी, भावना अक्सर अत्यावश्यक होती है, जिससे टिकट धीमे और महंगे होते हैं।

शिप करने से पहले सपोर्ट लोड की भविष्यवाणी करने के लिए चार क्षेत्रों पर ध्यान दें: वास्तविक दुनिया में विश्वसनीयता (मैसेजिंग और डिवाइस बदलाव), फिशिंग और टेकओवर जोखिम, उपयोगकर्ता घर्षण (सेटअप और हर लॉगिन), और वास्तविकता में मिलने वाले टिकट प्रकार।

SMS कोड उपभोक्ता ऐप्स में आम हैं क्योंकि वे परिचित लगते हैं और लगभग कोई सेटअप नहीं चाहिए। ऑथेंटिकेटर ऐप्स वर्कप्लेस और एडमिन टूल्स में आम हैं क्योंकि वे कैरियर निर्भरता हटाते हैं और कुछ टेलीकॉम-सम्बंधित जोखिम घटाते हैं।

SMS OTP डिलिवरेबिलिटी: वास्तविक जीवन में क्या टूटता है

SMS सरल लगता है, लेकिन “delivered” का मतलब हमेशा “प्राप्त और उपयोगी” नहीं होता। यही वह जगह है जहाँ टीमें सपोर्ट वॉल्यूम से आश्चर्यचकित होती हैं।

कभी-कभी SMS तुरंत पहुंच जाता है: उसी देश में, मजबूत सिग्नल, और एक ऐसा कैरियर जो वेरिफिकेशन ट्रैफ़िक थ्रॉटल नहीं करता। अन्य समय यह धीमा हो सकता है। पीक समय में कैरियर्स संदेश देरी करते हैं, स्पैम फ़िल्टर लगाते हैं, या बार-बार भेजने पर थ्रॉटल करते हैं। परिणामस्वरूप कोड एक्सपायर होने के बाद आता है, या कई कोड एक साथ आ जाते हैं और उपयोगकर्ता पुराने कोड को आजमाता है।

अंतरराष्ट्रीय उपयोग और भी नुकीला है। कुछ देशों में कुछ रूट्स के लिए कवरेज सीमित होती है। कुछ कैरियर्स वेरिफिकेशन संदेशों को डिफ़ॉल्ट रूप से ब्लॉक कर देते हैं। रोमिंग ट्रैफ़िक को ऐसे रूट कर सकता है कि मिनटों का अंतर आ जाए। अगर आपके उपयोगकर्ता यात्रा करते हैं, तो आप "घर पर काम करता है, विदेश में फेल" टिकट देखेंगे।

फोन नंबर टीम्स की अपेक्षा से अधिक बदलते हैं। उपयोगकर्ता सिम बदलते हैं, एक्सेस खो देते हैं, या एक बार गलती से टाइप किया गया नंबर कभी नोटिस नहीं करते। रिसाइकल किए हुए नंबर और भी बदतर होते हैं: एक छोड़ा हुआ नंबर रीअसाइन हो जाता है और भविष्य में भेजा गया SMS किसी दूसरे व्यक्ति पर पहुँच सकता है।

रिसेंड फ्लो पर फ्रस्ट्रेशन सबसे ज्यादा बढ़ता है। यदि उपयोगकर्ता बिना स्पष्ट सीमाओं और फीडबैक के "Resend" टैप कर सकते हैं, तो आप रिसेंड लूप बना देते हैं: कई संदेश, देरी से आगमन, और किस कोड का वैध होना है इस पर भ्रम।

क्या मॉनिटर करना चाहिए (और एडमिन टूल्स में दिखाना चाहिए): प्रत्येक लॉगिन पर भेजने की कोशिशें, आपके प्रदाता द्वारा रिपोर्ट किए गए डिलिवरी कन्फर्मेशन, कोड का समय (भेजे गए समय बनाम सबमिट समय), प्रदाता त्रुटि कारण (blocked, invalid number, throttled), और रिसेंड/लॉकआउट ट्रिगर्स।

उदाहरण: सिंगापुर में एक ग्राहक जर्मनी में रोमिंग करते समय साइन इन करने की कोशिश करता है। वे "Resend" दो बार टैप करते हैं, तीन संदेश एक साथ आते हैं, और वे पहला कोड दर्ज करते हैं। अगर आप time-to-code और resend count लॉग करते हैं, तो टिकट एक त्वरित ट्रायज बन जाता है बजाय लंबी बैक-एंड-फोर्थ के।

ऑथेंटिकेटर ऐप्स की विश्वसनीयता: कहाँ उपयोगकर्ता अटकते हैं

ऑथेंटिकेटर ऐप्स आमतौर पर SMS से अधिक सुसंगत होते हैं क्योंकि वे डिवाइस पर समय-आधारित कोड जनरेट करते हैं, यहां तक कि ऑफलाइन भी। कोई कैरियर देरी नहीं, कोई ब्लॉकेड संदेश नहीं, कोई रोमिंग सरप्राइज़ नहीं।

कागज़ पर सेटअप सरल है: एक बार QR कोड स्कैन करें, फिर लॉगिन पर 6-अंकीय कोड टाइप करें। असल ज़िन्दगी में, लोग पहले मिनट में अटक जाते हैं, खासकर जब वे लैपटॉप और फोन के बीच जा रहे हों और उन्हें नहीं पता कि वे क्या देख रहे हैं।

ज़्यादातर समस्याएँ ऑथेंटिकेटर ऐप के बारे में नहीं होतीं। वे फोन और उपयोगकर्ता की अपेक्षाओं के बारे में होती हैं:

• फोन का समय गलत है, इसलिए कोड मैच नहीं होते (मैन्युअल समय सेटिंग आम कारण है)।
• ऑथेंटिकेटर ऐप सफाई के दौरान डिलीट हो गया, इसलिए अकाउंट "लॉक" जैसा लग रहा है।
• फोन खो गया या वाइप कर दिया गया, और कोई बैकअप तरीका नहीं है।
• उपयोगकर्ता ने फोन अपग्रेड किया और सोचा कि कोड अपने आप शिफ्ट हो जाएंगे।
• उपयोगकर्ता ने कार्य फोन पर नामांकन किया और नौकरी बदलने के बाद उसे एक्सेस नहीं मिल रहा।

उपयोगिता उम्मीद से अधिक मायने रखती है। लॉगिन के बीच ऐप बदलना, कोड कॉपी करना, और काउंटडाउन के लिए दौड़ना तनावपूर्ण हो सकता है। स्पष्ट संकेत मदद करते हैं: बताएं कि कोड कहाँ मिलेगा, फेल होने पर क्या करना है, और प्लेटफ़ॉर्म जहां ऑटोफिल देता है वहां उसे सपोर्ट करें।

मल्टी-डिवाइस अपेक्षाएँ और क्या ट्रैक करना चाहिए

उपयोगकर्ता अक्सर एकाधिक डिवाइस चाहते हैं (फोन और टैबलेट, व्यक्तिगत और वर्क)। अगर आप अनुमति नहीं देते, तो नामांकन के दौरान बताएं, न कि जब वे लॉक आउट हों।

कुछ संकेत त्वरित घर्षण पकड़ते हैं: नामांकन पूरी होने की दर (कौन शुरू करता है पर कभी पूरा नहीं करता), बार-बार कोड फेल्यर्स (अकसर टाइम सिंक), उपयोग किए गए रिकवरी पथ (लॉस्ट फोन, नया डिवाइस, डिलीट हुआ ऐप), MFA प्रॉम्प्ट के बाद ड्रॉप-ऑफ, और कारण के अनुसार सपोर्ट टैग्स।

फिशिंग प्रतिरोध और अकाउंट टेकओवर जोखिम

फिशिंग वह जगह है जहाँ असली अंतर दिखता है।

SMS OTP के साथ एक सामान्य हमला रीयल-टाइम रिले है। उपयोगकर्ता नकली लॉगिन पेज पर आता है, अपना पासवर्ड दर्ज करता है, फिर SMS कोड प्राप्त होता है। हमलावर उसी कोड का उपयोग असली साइट पर करता है जबकि उपयोगकर्ता अभी भी नकली पेज देख रहा होता है। कोड वैध है, इसलिए लॉगिन सफल हो जाता है।

SMS में टेलीकॉम जोखिम भी रहता है। SIM स्वैप और नंबर पोर्ट-आउट हमले किसी को फोन नंबर का नियंत्रण दे सकते हैं और वे OTP संदेश प्राप्त कर लेते हैं बिना उपयोगकर्ता को पता चले। उच्च-मूल्य वाले अकाउंट्स के लिए यह भयंकर हो सकता है: हमलावर पासवर्ड रीसेट कर सकता है और तब तक प्रयास करता रहता है जब तक वह अंदर नहीं आ जाता।

ऑथेंटिकेटर ऐप्स SIM स्वैप के खिलाफ बेहतर हैं क्योंकि चोरी के लिए कोई फोन नंबर नहीं है। लेकिन कोड अभी भी रीयल-टाइम रिले पैटर्न से फिश किए जा सकते हैं अगर आपका लॉगिन किसी भी वैध कोड को संदर्भ जाँचे बिना स्वीकार करता है।

अगर आप टाइप किए गए कोड से ज़्यादा मजबूत सुरक्षा चाहते हैं तो पुश-आधारित अनुमोदन मदद कर सकते हैं, खासकर नंबर मैचिंग या स्पष्ट विवरण जैसे ऐप नाम और शहर दिखाकर। पुश का दुरुपयोग भी हो सकता है (approval fatigue), फिर भी यह 6-अंकीय कोड की तुलना में अवरोध बढ़ा देता है।

दोनों तरीकों के साथ टेकओवर जोखिम कम करने के व्यावहारिक तरीके:

• संवेदनशील कार्रवाइयों (ईमेल बदलना, payout विवरण बदलना, नया डिवाइस जोड़ना) के लिए step-up नियम लागू करें।
• IP या डिवाइस बदलने पर MFA को पुनः जाँचें, और उच्च-जोखिम सत्रों को लंबे समय तक जीवन न दें।
• लॉगिन स्क्रीन को स्पष्ट प्रोडक्ट संकेतों के साथ सुसंगत रखें ताकि उपयोगकर्ता नकली पन्ने तेज़ी से पहचान सकें।
• संदिग्ध retries पर रेट-लिमिट लगाएँ और असामान्य पैटर्न (impossible travel, rapid failures) को चुनौती दें।
• रिकवरी को ऐसा बनाएं कि उसका दुरुपयोग कठिन हो, खासकर उच्च-मूल्य उपयोगकर्ताओं के लिए।

उपयोगकर्ता घर्षण: कहाँ लोग फ्लो छोड़ देते हैं

लोग बमुश्किल इसलिए छोड़ते हैं कि वे "सुरक्षा से नफरत करते हैं।" वे छोड़ते हैं क्योंकि लॉगिन धीमा, भ्रमित करने वाला, या अप्रत्याशित लगता है।

घर्षण में सबसे बड़ा अंतर समय का है। SMS उपयोगकर्ताओं को प्रतीक्षा कराता है। ऑथेंटिकेटर ऐप्स उपयोगकर्ताओं से कुछ सेटअप करने के लिए कहते हैं।

SMS के साथ, पहली बार फ्लो परिचित है: फोन नंबर डालें, कोड प्राप्त करें, उसे टाइप करें। घर्षण तब बढ़ता है जब संदेश जल्दी नहीं आता, पुराने नंबर पर आता है, या उस डिवाइस पर आता है जो उपयोगकर्ता थामे नहीं है।

ऑथेंटिकेटर ऐप के साथ, पहली बार फ्लो में अधिक कदम होते हैं: एक ऐप इंस्टॉल करें, QR स्कैन करें, बैकअप ऑप्शन सुरक्षित रखें, फिर कोड दर्ज करें। साइनअप या चेकआउट के दौरान यह बहुत लग सकती है।

सबसे सामान्य ड्रॉप-ऑफ क्षण अनुमानित हैं: 30 से 90 सेकंड SMS के लिए इंतजार करना और फिर कई कोड आना; ऐपों के बीच टाइपिंग गलतियाँ; डिवाइस बदलना (नया फोन, वाइप किया हुआ फोन, वर्क फोन जिस पर ऐप इंस्टॉल नहीं होता); यात्रा समस्याएं (रोमिंग, नया सिम, विदेश में संदेश न मिलना); और जहाँ उपयोगकर्ता दूसरे फैक्टर डिवाइस को नियमित रूप से नियंत्रित नहीं करते।

"इस डिवाइस को याद रखें" घर्षण कम करता है, पर इसे ओवर-इस्तेमाल करना आसान है। अगर आप कभी री-प्रॉम्प्ट नहीं करते, तो किसी के लैपटॉप चोरी होने पर टेकओवर जोखिम बढ़ता है। अगर आप बार-बार री-प्रॉम्प्ट करते हैं, तो उपयोगकर्ता फ्लो छोड़ देते हैं या कमजोर रिकवरी विकल्प चुनते हैं। एक व्यावहारिक संतुलन नया डिवाइस, संवेदनशील कार्रवाई, या एक उचित समय-सीमा के बाद री-प्रॉम्प्ट करना है।

अपने फ़नल पर ध्यान दें। अगर स्टेप 1 (फोन डालना) ठीक है पर स्टेप 2 (कोड डालना) तेज़ी से गिरता है, तो SMS देरी या कोड भ्रम की आशंका करें। अगर ड्रॉप-ऑफ QR स्क्रीन के ठीक बाद होता है, तो सेटअप उस पल के लिए बहुत भारी है।

अपेक्षित सपोर्ट टिकट और उन्हें कैसे ट्रायज करें

अधिकांश MFA सपोर्ट काम "सुरक्षा" के बारे में नहीं होता। यह उनWorst-मोमेंट पर फंसे लोगों के बारे में होता है: शिफ्ट चेंज के दौरान लॉगिन, डेमो से पहले पासवर्ड रिसेट, या किसी एडमिन का नया हायर ऑनबोर्ड करना।

अगर आप SMS OTP बनाम ऑथेंटिकेटर ऐप्स की तुलना कर रहे हैं, तो अपनी सपोर्ट क्यू को फेलियर मोड के चारों ओर प्लान करें, न कि हैप्पी पाथ के।

सामान्य टिकट थीम

आप बार-बार वही पैटर्न देखेंगे।

SMS के लिए: "कोड कभी नहीं आया", "देर से आया", "दो बार आया", गलत नंबर, नंबर बदल गया, कैरियर ब्लॉक, रोमिंग समस्याएँ, और शॉर्ट कोड फ़िल्टर।

ऑथेंटिकेटर ऐप्स के लिए: खोया हुआ फोन, नया डिवाइस, ऐप रीइंस्टॉल किया, "कोड मिलते नहीं", किस ऐप/अकाउंट/प्रोफ़ाइल में कोड है इस बारे में भ्रम।

एडमिन भी नीति और ऑडिट टिकट खोलेंगे: "यूज़र लॉक आउट है, MFA रीसेट करें," और "इस अकाउंट के लिए किसने MFA रीसेट किया?"—इनके लिए क्लीन प्रोसेस और पेपर ट्रेल चाहिए।

ट्राइएज से पहले क्या इकट्ठा करें

एक अच्छा ट्रायज फॉर्म हर टिकट पर समय बचाता है। पूछें: अकाउंट आइडेंटिफायर और MFA मेथड, आखिरी प्रयास का टाइमस्टैम्प और टाइमज़ोन (और क्या कोई कोड मिला), आखिरी सफल लॉगिन का समय और तरीका, डिवाइस विवरण (मॉडल और OS वर्ज़न), और क्या डिवाइस हाल ही में बदला गया था। SMS के लिए, फोन का देश और कैरियर भी पकड़ें अगर पता हो।

इन जानकारियों से सपोर्ट त्वरित निर्णय ले सकता है: रिसेंड (गार्डरेयल्स के साथ), फोन नंबर वेरिफाइ करना, रेट लिमिट का इंतज़ार, या सुरक्षित MFA रीसेट शुरू करना।

बैक-एंड कम-बैक और कम बात-चीत वाले रिप्लाइज़

जवाब सरल और बिना आरोप के रखें। एक साधारण मैक्रो अधिकांश मामलों के लिए काम करता है:

"कृपया पुष्टि करें कि आपने कब कोशिश की (अपना टाइमज़ोन बताकर) और क्या आपको कोई SMS मिला। अगर आपने हाल ही में फोन बदला है या ऑथेंटिकेटर ऐप रीइंस्टॉल किया है, तो बताएं कब। अगर आप लॉक आउट हैं, तो हम आपकी पहचान सत्यापित करने के बाद MFA रीसेट कर सकते हैं।"

चरण-दर-चरण: सही MFA चुनना और रोलआउट करना

एक ईमानदार सवाल से शुरू करें: आप क्या सुरक्षित कर रहे हैं, और किससे? एक कंज्यूमर न्यूज़लेटर की जोखिम प्रोफ़ाइल पेरोल, हेल्थकेयर डेटा, या एडमिन पैनल से अलग होती है।

उपयोगकर्ता सीमाओं को जल्दी लिख लें: आप किन देशों में सर्विस देते हैं, उपयोगकर्ता कितनी बार यात्रा करते हैं, क्या वे दूसरी डिवाइस साथ रखते हैं, और क्या उन्हें ऐप इंस्टॉल करने की अनुमति है।

एक रोलआउट योजना जो सपोर्ट फायर से बचाए:

1. अपने थ्रेट मॉडल और सीमाएँ परिभाषित करें। अगर फिशिंग और टेकओवर प्रमुख चिंता हैं, तो ऐसे तरीकों को चुनें जिन्हें ट्रिक करना मुश्किल हो। अगर कई उपयोगकर्ताओं के पास स्मार्टफोन नहीं है या वे ऐप इंस्टॉल नहीं कर सकते, तो वैकल्पिक योजना बनाएं।

2. एक डिफ़ॉल्ट मेथड और एक बैकअप चुनें। डिफ़ॉल्ट्स अधिकतर लोगों के लिए पहले दिन काम करने चाहिए। बैकअप वही बचाव है जो फोन खो जाने, नंबर बदलने, या यात्रा के मामलों में सपोर्ट बचाता है।

3. लॉन्च से पहले नामांकन और रिकवरी डिजाइन करें। रिकवरी उसी चीज़ पर निर्भर नहीं होनी चाहिए जो फेल हो सकती है (उदाहरण के लिए केवल SMS)। तय करें कि खोए हुए डिवाइस, नया फोन नंबर, और "मुझे कोड कभी नहीं मिला" मामलों को कैसे संभालेंगे।

4. धीरे-धीरे रोल आउट करें और सामान्य भाषा में कारण बताएं। एडमिन, फाइनेंस जैसे उच्च-जोखिम रोल्स से या उपयोगकर्ताओं के छोटे प्रतिशत से शुरू करें।

5. सपोर्ट को ट्रेन करें और विफलताओं को ट्रैक करें। एजेंट्स को सरल निर्णय-ट्री और पहचान जाँच के स्पष्ट नियम दें। डिलिवरी फेल्यर्स, लॉकआउट्स, नामांकन समय, और रीकवरी अनुरोधों पर नजर रखें।

आम गलतियाँ और जाल जिनसे बचना चाहिए

अधिकांश MFA रोलआउट सरल कारणों से फेल होते हैं: नीति बहुत कठोर है, रिकवरी कमजोर है, या UI उपयोगकर्ताओं को उलझा देता है।

एक सामान्य जाल यह है कि SMS ही एकमात्र रास्ता बना दिया जाए। फोन नंबर बदलते हैं, SIM स्वैप होते हैं, और कुछ उपयोगकर्ता यात्रा करते समय टेक्स्ट प्राप्त नहीं कर पाते। अगर SMS दोनों—दूसरे फैक्टर और रिकवरी—के रूप में उपयोग किया जाए, तो अंततः "कभी नहीं वापस खुलने वाले" अकाउंट बन जाते हैं।

एक और सामान्य गलती यह है कि उपयोगकर्ता को केवल पासवर्ड और नए नंबर पर भेजे गए SMS कोड से नंबर बदलने की अनुमति दे दी जाए। इससे चोरी हुए पासवर्ड को लेकर पूरा टेकओवर संभव हो जाता है। संवेदनशील बदलावों (फोन, ईमेल, MFA सेटिंग्स) के लिए एक मजबूत स्टेप जोड़ें: मौजूदा फैक्टर की जाँच करें, हालिया सत्र री-चेक की मांग करें, या हाई-रिस्क मामलों के लिए मैनुअल रिव्यू फ्लो रखें।

सबसे अधिक टोहनीय सपोर्ट दर्द पैदा करने वाले जाल अक्सर होते हैं:

• रिसेंड और रेट-लिमिट नियम जो असली उपयोगकर्ताओं को दंडित करते हैं (बहुत कड़े) या हमलावरों की मदद करते हैं (बहुत ढीले)। छोटे कूलडाउन, स्पष्ट काउंटडाउन टेक्स्ट, और हार्ड कैप्स रखें साथ में सुरक्षित फॉलबैक।
• प्राथमिक फैक्टर के अलावा कोई रिकवरी विकल्प न होना। बैकअप कोड, दूसरा ऑथेंटिकेटर डिवाइस, या सपोर्ट-एसिस्टेड रीसेट डेड-एंड रोकते हैं।
• रीसेट के लिए कोई एडमिन टूलिंग नहीं और कोई ऑडिट ट्रेल नहीं। सपोर्ट को दिखना चाहिए कब MFA सक्षम किया गया, क्या बदला और किसने किया।
• उपयोगकर्ता को दोषी ठहराने वाले एरर मैसेज। "Invalid code" बिना संदर्भ के अनंत retries बनाता है। बताएं अगला क्या प्रयास करें।
• बार-बार विफलताओं को "उपयोगकर्ता त्रुटि" मान लेना बजाय उत्पाद मुद्दे के। अगर किसी विशिष्ट कैरियर, देश, या डिवाइस मॉडल से विफलताएँ जुड़ी हैं, तो यह ठीक करने योग्य पैटर्न है।

शिप करने से पहले तेज़ चेकलिस्ट

लॉगिन फ्लो पर दबाव-टेस्ट करें जैसे असली उपयोगकर्ता करेंगे: थके हुए, यात्रा करते हुए, फोन बदलते हुए, या मीटिंग से पाँच मिनट पहले लॉक आउट होकर। सबसे अच्छा तरीका वही है जिसे आपके उपयोगकर्ता भरोसे के साथ पूरा कर सकें और आपकी टीम बिना जोखिम भरे शॉर्टकट्स के सपोर्ट कर सके।

इन सवालों का जवाब दें:

• क्या उपयोगकर्ता बिना सेल सेवा के या यात्रा करते हुए MFA पूरा कर सकते हैं (एयरप्लेन मोड, रोमिंग ब्लॉक, SIM स्वैप, नंबर बदलना)?
• क्या आपके पास एक सुरक्षित और सरल रिकवरी पथ है (रीकवरी कोड, भरोसेमंद डिवाइस, टाइम-लिमिटेड रिकवरी, या सत्यापित सपोर्ट रीसेट)?
• क्या सपोर्ट पहचान जल्दी व बिना संवेदनशील डेटा माँगे सत्यापित कर सकता है (कोई पूरा पासवर्ड नहीं, कोई पूरा कार्ड नंबर नहीं), और क्या एक दस्तावेजीकृत रीसेट प्लेबुक है?\n- क्या आप असफल MFA प्रयास लॉग करते हैं और दुरुपयोग पैटर्न पर अलर्ट करते हैं (कई retries, एक IP से कई अकाउंट्स, पासवर्ड रिसेट के बाद लगातार विफलताएँ)?
• क्या स्क्रीन पर टेक्स्ट स्पष्ट है कि कोड कहाँ से आता है और अगला कदम क्या है?

अगर आपका जवाब रिकवरी पर "शायद" है, तो रुके। अधिकांश अकाउंट टेकओवर रिकवरियों के दौरान होते हैं, और अधिकांश गुस्साये उपयोगकर्ता तब आते हैं जब रिकवरी उलझन भरी होती है।

एक व्यावहारिक परीक्षण: अपनी टीम से बाहर किसी को कहें कि वे MFA सेटअप करें, फिर अपना फोन खो दें और केवल आपके दस्तावेजीकृत कदमों का उपयोग करके वापस आने की कोशिश करें। अगर वह इंजीनियरिंग के साथ चैट बन जाता है, तो आप वही पैटर्न असली टिकटों में भी देखेंगे।

उदाहरण परिदृश्य: वैश्विक उपयोगकर्ताओं वाला कस्टमर पोर्टल

एक 6-व्यक्ति टीम एक कस्टमर पोर्टल चलाती है जिसका उपयोग 1,200 सक्रिय उपयोगकर्ता US, India, UK, और Brazil में करते हैं। वे 40 ठेकेदारों को भी एक्सेस देते हैं जो आते-जाते रहते हैं। पासवर्ड रिसेट पहले से ही शोर पैदा करते हैं, इसलिए वे MFA जोड़ते हैं और उम्मीद करते हैं कि यह अकाउंट टेकओवर घटाए बिना सपोर्ट को बाढ़ में नहीं बदलेगा।

उन्होंने शुरुआत में डिफ़ॉल्ट के रूप में SMS OTP चुना। पहले सप्ताह में सब कुछ ठीक दिखा जब तक कि एक क्षेत्र में पीक घंटों के दौरान कैरियर देरी नहीं आई। उपयोगकर्ता कोड का अनुरोध करते हैं, इंतजार करते हैं, फिर फिर से अनुरोध करते हैं और अंततः तीन कोड एक साथ प्राप्त होते हैं। कुछ लोग सबसे पुराने कोड को आजमाते हैं, फेल होते हैं, और खुद को लॉक कर लेते हैं। सपोर्ट को टिकटों की एक लहर मिली: "कोड नहीं मिला", "मेरा कोड हमेशा गलत है", "मैं यात्रा पर हूँ और मेरा नंबर बदल गया है।" VoIP नंबर, रोमिंग यूज़र्स, और सख्त स्पैम फ़िल्टरिंग के कारण डिलिवरेबिलिटी समस्याएँ बिना किसी आउटेज के भी दिखती हैं।

उन्होंने विकल्प के रूप में ऑथेंटिकेटर ऐप जोड़ा और एक अलग पैटर्न देखा। अधिकांश लॉगिन स्मूद रहे, लेकिन विफलताएँ ज्यादा तीव्र थीं: किसी ने फोन अपग्रेड किया और ऐप कोड ट्रांसफर नहीं हुआ, किसी ने ऑथेंटिकेटर डिलीट कर दिया, या किसी ठेकेदार ने "QR स्कैन" स्टेप मिस कर दिया और फंस गया। ऐसे टिकट कुछ इस तरह सुनाई देते हैं: "नया फोन, लॉगिन नहीं कर पा रहा हूँ", "कोड मैच नहीं हो रहे", और "मैंने अपना डिवाइस खो दिया।"

एक सेटअप जो आश्चर्य कम करता है अक्सर इस तरह दिखता है:

• नए उपयोगकर्ताओं के लिए डिफ़ॉल्ट रूप से ऑथेंटिकेटर ऐप रखें, और SMS बैकअप के रूप में दें (एकमात्र तरीका न हो)।
• रीकवरी कोड और स्पष्ट खोए हुए डिवाइस फ्लो दें जो मैन्युअल जाँच ट्रिगर करे।
• payout विवरण बदलने या नया एडमिन जोड़ने जैसी जोखिम वाली क्रियाओं के लिए step-up ज़रूरी रखें।
• ठेकेदारों के लिए छोटे सत्र जीवन और नए डिवाइस पर फिर से जाँच लागू करें।

अगले कदम: बिना प्रोडक्ट धीमा किए MFA लागू करें

एक डिफ़ॉल्ट MFA मेथड चुनें जो आपके अधिकांश उपयोगकर्ताओं के लिए फिट हो, फिर एक बैकअप जोड़ें।

उपभोक्ता दर्शकों के लिए, SMS अक्सर आसान डिफ़ॉल्ट होता है, साथ में ऑथेंटिकेटर ऐप विकल्प के रूप में उन लोगों के लिए जो यात्रा करते हैं, VoIP नंबर उपयोग करते हैं, या कड़ा सुरक्षा चाहते हैं। वर्कफ़ोर्स या एडमिन-भारी प्रोडक्ट के लिए, ऑथेंटिकेटर ऐप बेहतर डिफ़ॉल्ट होता है और SMS रीकवरी के लिए रखा जाता है।

रोलआउट से पहले, एक सरल सपोर्ट प्लेबुक लिखें और तय करें आप क्या लॉग करेंगे। आपको बड़ी मात्रा में डेटा की जरूरत नहीं है। आपको बस इतना चाहिए कि उत्तर दिया जा सके: क्या हमने भेजा, क्या उपयोगकर्ता ने प्राप्त किया, और सत्यापन के दौरान क्या हुआ।

वे लॉग जो आम तौर पर लाभ देते हैं: MFA मेथड और टाइमस्टैम्प, डिलिवरी प्रदाता प्रतिक्रिया (accepted, queued, failed), वेरिफिकेशन प्रयासों की गिनती के साथ आखिरी त्रुटि कारण, और आखिरी सफल MFA मेथड और तारीख।

एक छोटी स्क्रीन से सपोर्ट तेज़ बनाएं: उपयोगकर्ता MFA स्टेटस, हाल की विफलताएँ, और एक नियंत्रित रीसेट फ्लो ऑडिट ट्रेल के साथ।

अगर आप भारी कोडिंग के बिना एक पोर्टल बना रहे हैं, तो AppMaster (appmaster.io) आपकी मदद कर सकता है ताकि आप बैकएंड, वेब ऐप और मोबाइल ऐप इन फ्लोज़ के इर्द-गिर्द जल्दी से जोड़ सकें, जिसमें एडमिन व्यूज़ और इवेंट लॉगिंग भी शामिल हैं जो टिकट आने पर अटकलों को कम करते हैं।

पहले पायलट में रोलआउट करें, एक सप्ताह के लिए विफलता मीट्रिक्स देखें, फिर विस्तार करें। पूरा होने की दर, रिसेंड दर, MFA पूरा करने का समय, और प्रति 1,000 लॉगिन पर टिकट वॉल्यूम ट्रैक करें। फ्लो को सख्त करें, प्लेबुक अपडेट करें, और फिर स्केल करें।