SMS OTP vs aplikasi autentikator: memilih MFA yang tepat

Kenapa pilihan metode MFA berujung pada masalah dukungan

Kebanyakan orang baru memperhatikan MFA saat itu gagal. Kode datang terlambat, ponsel tidak ada sinyal, atau aplikasi terhapus saat upgrade perangkat. Pengguna terjebak di layar login, dan yang seharusnya terasa seperti lapisan keamanan malah menjadi “saya tidak bisa bekerja.”

Itulah mengapa perdebatan SMS OTP vs aplikasi autentikator bukan sekadar soal keamanan. Ini keputusan produk yang mengubah antrean dukungan Anda, risiko churn, dan seberapa sering tim Anda melakukan pemeriksaan identitas manual.

Saat MFA rusak, pengguna biasanya melakukan salah satu dari tiga hal: coba beberapa kali, meninggalkan alur, atau menghubungi dukungan dengan panik karena mengira akunnya dibajak. Bahkan ketika penyebabnya sederhana, nada emosional sering mendesak, yang membuat tiket jadi lebih lambat dan lebih mahal.

Untuk memprediksi beban dukungan sebelum peluncuran, fokus pada empat area: keandalan dunia nyata (pengiriman pesan dan perubahan perangkat), risiko phishing dan takeover, friksi pengguna (penyiapan dan setiap login), dan jenis tiket yang akan sering muncul di praktik.

Kode SMS umum di aplikasi konsumen karena terasa familier dan hampir tak perlu penyiapan. Aplikasi autentikator umum di lingkungan kerja dan alat admin karena menghilangkan ketergantungan operator dan mengurangi beberapa risiko terkait telekomunikasi.

Deliverability SMS OTP: apa yang rusak di dunia nyata

SMS terasa sederhana, tetapi “terkirim” tidak sama dengan “diterima dan bisa dipakai.” Di sinilah tim sering terkejut dengan volume dukungan.

Kadang SMS instan: satu negara, sinyal kuat, dan operator yang tidak membatasi traffic verifikasi. Kadang lain melambat. Operator menunda pesan saat puncak, menerapkan filter spam, atau membatasi pengiriman berulang. Hasilnya adalah kode tiba setelah kadaluarsa, atau beberapa kode tiba sekaligus dan pengguna mencoba kode yang lebih tua.

Penggunaan internasional menambah masalah. Beberapa negara punya cakupan terbatas untuk rute tertentu. Beberapa operator memblokir pesan verifikasi secara default. Roaming bisa merutekan lalu lintas dengan cara yang menambah menit. Jika pengguna Anda bepergian, Anda akan melihat tiket “bekerja di rumah, gagal di luar negeri.”

Nomor telepon berubah lebih sering daripada yang tim perkirakan. Pengguna ganti SIM, kehilangan akses, atau memasukkan salah ketik sekali dan tidak menyadarinya. Nomor yang didaur ulang lebih buruk: nomor yang tidak aktif bisa diberikan ke orang lain, dan SMS login di masa depan bisa sampai ke orang yang salah.

Alur kirim ulang (resend) adalah tempat frustrasi memuncak. Jika pengguna bisa menekan “Kirim ulang” tanpa batas jelas dan umpan balik yang jelas, Anda menciptakan loop pengiriman ulang: banyak kiriman, kedatangan tertunda, dan kebingungan tentang kode mana yang valid.

Yang layak dipantau (dan diekspos di alat admin) itu sederhana: percobaan pengiriman per login, konfirmasi pengiriman saat provider melaporkannya, waktu-ke-kode (waktu dikirim vs waktu dikirimkan oleh pengguna), alasan error provider (diblokir, nomor tidak valid, dibatasi), dan pemicu kirim ulang/lockout.

Contoh: seorang pelanggan di Singapura mencoba masuk saat roaming di Jerman. Mereka menekan “Kirim ulang” dua kali, mendapat tiga pesan sekaligus, dan memasukkan kode pertama. Jika Anda mencatat waktu-ke-kode dan jumlah kirim ulang, tiket menjadi triase cepat alih-alih bolak-balik panjang.

Keandalan aplikasi autentikator: di mana pengguna tersangkut

Aplikasi autentikator biasanya lebih konsisten daripada SMS karena mereka menghasilkan kode berbasis waktu di perangkat, bahkan offline. Tidak ada keterlambatan operator, tidak ada pesan diblokir, tidak ada kejutan roaming.

Penyiapan di atas kertas sederhana: pindai kode QR sekali, lalu ketik kode 6-digit saat login. Di dunia nyata, orang tersangkut di menit pertama itu, terutama saat berpindah antara laptop dan ponsel dan tidak yakin apa yang mereka lihat.

Sebagian besar masalah bukan pada aplikasi autentikator itu sendiri. Masalahnya ada pada ponsel dan ekspektasi pengguna:

• Waktu ponsel salah, sehingga kode tidak cocok (pengaturan waktu manual sering menjadi penyebab).
• Aplikasi autentikator terhapus saat membersihkan perangkat, sehingga akun terasa “terkunci.”
• Ponsel hilang atau dihapus, dan tidak ada metode cadangan.
• Pengguna upgrade ponsel dan mengira kodenya otomatis berpindah.
• Pengguna mendaftar di ponsel kerja dan kehilangan akses setelah berganti pekerjaan.

Kegunaan (usability) lebih penting daripada yang diperkirakan tim. Berpindah aplikasi saat login, menyalin kode, dan berlomba dengan hitungan mundur bisa menegangkan. Prompt yang jelas membantu: katakan persis di mana menemukan kode, tunjukkan apa yang dilakukan jika gagal, dan dukung autofill bila platform menyediakannya.

Ekspektasi multi-perangkat dan apa yang harus dipantau

Pengguna sering meminta banyak perangkat (ponsel plus tablet, pribadi plus kerja). Jika Anda tidak mengizinkannya, katakan saat pendaftaran, bukan setelah mereka terkunci keluar.

Beberapa sinyal menangkap friksi lebih awal: tingkat penyelesaian pendaftaran (siapa yang mulai tapi tidak pernah selesai), kegagalan kode berulang (sering sinkronisasi waktu), jalur pemulihan yang dipakai (ponsel hilang, perangkat baru, aplikasi terhapus), penurunan setelah prompt MFA, dan tag dukungan menurut penyebab.

Ketahanan terhadap phishing dan risiko takeover akun

Phishing adalah tempat celah sebenarnya terlihat.

Dengan SMS OTP, serangan umum adalah relay waktu-nyata. Pengguna masuk ke halaman login palsu, memasukkan kata sandi, lalu menerima kode SMS. Penyerang menggunakan kode itu di situs nyata saat pengguna masih melihat halaman palsu. Kode sah, jadi login berhasil.

SMS juga membawa risiko telekomunikasi. SIM swap dan port-out nomor memungkinkan seseorang mengambil alih nomor telepon dan menerima pesan OTP tanpa pengguna menyadari sampai terlambat. Untuk akun bernilai tinggi, ini menghancurkan: penyerang bisa mereset kata sandi dan terus mencoba sampai berhasil.

Aplikasi autentikator lebih aman terhadap SIM swap karena tidak ada nomor telepon yang dicuri. Namun kode tetap bisa dipancing menggunakan pola relay waktu-nyata jika login Anda menerima kode mana pun tanpa memeriksa konteks.

Jika Anda ingin perlindungan lebih kuat daripada kode yang diketik, persetujuan berbasis push bisa membantu, terutama dengan number matching atau detail jelas seperti nama aplikasi dan kota. Push masih bisa disalahgunakan lewat kelelahan persetujuan, tapi membuat serangan lebih sulit dibandingkan hanya mengetik kode 6-digit.

Cara praktis mengurangi risiko takeover untuk kedua metode:

• Gunakan aturan step-up untuk tindakan sensitif (mengubah email, detail pembayaran, perangkat baru).
• Periksa ulang MFA saat IP atau perangkat berubah, dan jangan biarkan sesi berisiko tinggi hidup selamanya.
• Pertahankan konsistensi layar login dengan petunjuk produk yang jelas agar pengguna cepat menyadari halaman palsu.
• Batasi laju percobaan mencurigakan dan tantang pola yang tidak biasa (perjalanan mustahil, kegagalan cepat berulang).
• Buat pemulihan sulit disalahgunakan, terutama untuk pengguna bernilai tinggi.

Friksi pengguna: di mana orang meninggalkan alur

Orang jarang berhenti karena “membenci keamanan.” Mereka berhenti karena login terasa lambat, membingungkan, atau tidak terduga.

Perbedaan terbesar dalam friksi adalah waktu. SMS membuat pengguna menunggu. Aplikasi autentikator meminta pengguna menyiapkan sesuatu.

Dengan SMS, alur pertama kali familier: masukkan nomor telepon, terima kode, ketik. Friksi melonjak saat pesan tidak tiba cepat, tiba di nomor lama, atau tiba di perangkat yang tidak dipegang pengguna.

Dengan aplikasi autentikator, alur pertama kali punya lebih banyak langkah: pasang aplikasi, pindai QR, simpan opsi cadangan, lalu masukkan kode. Saat pendaftaran atau checkout, itu bisa terasa terlalu berat.

Momen drop-off paling umum dapat diprediksi: menunggu 30–90 detik untuk SMS lalu menerima beberapa kode; salah ketik saat berganti aplikasi; berganti perangkat (ponsel baru, ponsel yang dihapus, ponsel kerja yang tidak bisa memasang aplikasi); isu perjalanan (roaming, SIM baru, nomor yang tidak bisa terima pesan di luar negeri); dan kasus di mana pengguna tidak mengendalikan perangkat faktor kedua secara andal.

“Opsi ingat perangkat ini” mengurangi friksi, tapi mudah disalahgunakan. Jika Anda tidak pernah meminta ulang, risiko takeover naik saat laptop dicuri. Jika Anda meminta ulang terlalu sering, pengguna meninggalkan alur atau memilih opsi pemulihan yang lebih lemah. Jalan tengah yang masuk akal adalah meminta ulang pada perangkat baru, setelah aksi sensitif, atau setelah jangka waktu yang wajar.

Pantau funnel Anda. Jika langkah 1 (masukkan nomor) terlihat baik tetapi langkah 2 (masukkan kode) turun tajam, curigai keterlambatan SMS atau kebingungan kode. Jika drop-off terjadi tepat setelah layar QR, penyiapan terlalu berat untuk saat itu.

Tiket dukungan yang diharapkan (dan cara men-triage)

Sebagian besar pekerjaan dukungan MFA bukan soal “keamanan.” Ini soal orang yang terblokir di momen terburuk: login saat pergantian shift, reset kata sandi sebelum demo, atau admin yang mencoba meng-onboard karyawan baru.

Jika Anda membandingkan SMS OTP vs aplikasi autentikator, rencanakan antrean dukungan berdasarkan mode kegagalan, bukan jalan bahagia.

Tema tiket umum

Anda akan melihat pola yang sama berulang.

Untuk SMS: “kode tidak pernah sampai,” “tiba terlambat,” “tiba dua kali,” nomor salah, nomor berubah, operator memblokir, masalah roaming, dan kode pendek yang terfilter.

Untuk aplikasi autentikator: ponsel hilang, perangkat baru, aplikasi diinstall ulang, “kode tidak cocok,” kebingungan tentang aplikasi/akun/profil mana yang memegang kode.

Admin juga akan membuka tiket kebijakan dan audit: “Pengguna terkunci, reset MFA,” dan “Siapa yang mereset MFA untuk akun ini?” Itu butuh proses jelas dan jejak audit.

Apa yang dikumpulkan sebelum men-triage

Form triase yang baik menghemat waktu setiap tiket. Minta pengenal akun dan metode MFA, cap waktu dan zona waktu dari percobaan terakhir (dan apakah ada kode diterima), waktu login terakhir yang berhasil dan metodenya, detail perangkat (model dan versi OS), dan apakah perangkat baru-baru ini berubah. Untuk SMS, tangkap negara nomor dan operator jika diketahui.

Dengan itu, dukungan bisa memilih langkah selanjutnya cepat: kirim ulang (dengan pembatasan), verifikasi nomor telepon, menunggu batas laju, atau memulai reset MFA yang aman.

Balasan dukungan yang mengurangi bolak-balik

Jaga balasan tetap sederhana dan tidak menyalahkan. Makro singkat menutup sebagian besar kasus:

“Mohon konfirmasi waktu percobaan (dengan zona waktu Anda) dan apakah Anda menerima SMS sama sekali. Jika Anda baru saja mengganti ponsel atau menginstal ulang aplikasi autentikator, beri tahu kapan. Jika Anda terkunci, kami bisa mereset MFA setelah memverifikasi identitas Anda.”

Langkah demi langkah: memilih dan meluncurkan MFA yang tepat

Mulai dengan satu pertanyaan jujur: apa yang Anda lindungi, dan dari siapa? Newsletter konsumen punya profil risiko berbeda dengan payroll, data kesehatan, atau panel admin.

Catat juga batasan pengguna sejak awal: negara yang Anda layani, seberapa sering pengguna bepergian, apakah mereka membawa perangkat kedua, dan apakah mereka diperbolehkan memasang aplikasi.

Rencana peluncuran yang menghindari kebakaran dukungan:

1. Definisikan model ancaman dan batasan Anda. Jika phishing dan takeover adalah kekhawatiran utama, pilih metode yang lebih sulit untuk ditipu. Jika banyak pengguna tidak punya smartphone atau tidak bisa memasang aplikasi, rencanakan alternatif.

2. Pilih satu metode default plus cadangan. Default harus bekerja untuk sebagian besar orang pada hari pertama. Cadangan menyelamatkan dukungan saat ponsel hilang, nomor berubah, atau pengguna bepergian.

3. Rancang pendaftaran dan pemulihan sebelum diluncurkan. Pemulihan tidak boleh bergantung pada hal yang sama yang bisa gagal (mis. hanya SMS). Putuskan bagaimana menangani perangkat hilang, nomor telepon baru, dan “saya tidak menerima kode.”

4. Luncurkan bertahap dan jelaskan alasan dengan kata-kata sederhana. Mulai dari peran berisiko tinggi (admin, keuangan) atau persentase pengguna kecil.

5. Latih dukungan dan pantau kegagalan. Beri agen pohon keputusan sederhana dan aturan jelas untuk cek identitas. Pantau kegagalan pengiriman, lockout, waktu-ke-pendaftaran, dan permintaan pemulihan.

Kesalahan umum dan jebakan yang harus dihindari

Kebanyakan rollout MFA gagal karena alasan sederhana: kebijakan terlalu kaku, pemulihan lemah, atau UI membuat pengguna menebak.

Jebakan umum adalah menjadikan SMS sebagai satu-satunya jalan kembali ke akun. Nomor telepon berubah, SIM dicuri, dan beberapa pengguna tidak bisa menerima SMS saat bepergian. Jika SMS adalah faktor kedua sekaligus metode pemulihan, Anda pada akhirnya menciptakan akun yang “terkunci selamanya.”

Kesalahan umum lain adalah membiarkan pengguna mengganti nomor telepon hanya dengan password dan kode SMS yang dikirim ke nomor baru. Itu mengubah kata sandi yang dicuri menjadi takeover bersih. Untuk perubahan sensitif (telepon, email, pengaturan MFA), tambahkan langkah lebih kuat: verifikasi faktor yang ada, minta sesi baru-baru ini, atau gunakan alur peninjauan manual untuk kasus berisiko tinggi.

Jebakan yang paling sering menghasilkan sakit dukungan yang bisa dihindari biasanya:

• Aturan kirim ulang dan pembatasan laju yang menghukum pengguna nyata (terlalu ketat) atau membantu penyerang (terlalu longgar). Targetkan cooldown singkat, teks hitung mundur yang jelas, dan batas keras dengan fallback aman.
• Tidak ada opsi pemulihan selain faktor utama. Kode cadangan, perangkat autentikator kedua, atau reset yang dibantu dukungan mencegah jalan buntu.
• Tidak ada alat admin untuk reset, dan tidak ada jejak audit. Dukungan perlu melihat kapan MFA diaktifkan, apa yang berubah, dan siapa yang melakukannya.
• Pesan error yang menyalahkan pengguna. "Kode tidak valid" tanpa konteks menyebabkan retry tanpa henti. Katakan apa yang harus dicoba selanjutnya.
• Menganggap kegagalan berulang sebagai “kelalaian pengguna” alih-alih masalah produk. Jika operator, negara, atau model perangkat tertentu berkorelasi dengan kegagalan, itu pola yang bisa diperbaiki.

Daftar periksa cepat sebelum Anda berkomitmen

Uji alur login seperti pengguna sungguhan akan menggunakannya: lelah, bepergian, berganti ponsel, atau terkunci lima menit sebelum rapat. Metode terbaik adalah yang bisa diselesaikan pengguna Anda secara andal dan yang tim Anda bisa dukung tanpa jalan pintas berisiko.

Tanyakan hal-hal ini:

• Bisakah pengguna menyelesaikan MFA tanpa sinyal seluler atau saat bepergian (mode pesawat, roaming diblokir, SIM ditukar, nomor berubah)?
• Apakah Anda punya jalur pemulihan yang aman dan sederhana (kode cadangan, perangkat tepercaya, pemulihan terbatas waktu, atau reset dukungan terverifikasi)?
• Bisakah dukungan memverifikasi identitas cepat tanpa meminta data sensitif (tidak meminta password penuh, tidak meminta nomor kartu penuh), dan apakah ada playbook reset yang terdokumentasi?
• Apakah Anda mencatat percobaan MFA yang gagal dan memberi peringatan pada pola penyalahgunaan (banyak retry, banyak akun dari satu IP, kegagalan berulang setelah reset kata sandi)?
• Apakah teks di layar jelas tentang dari mana kode berasal dan apa langkah berikutnya?

Jika jawaban Anda “mungkin” pada pemulihan, berhenti sejenak. Sebagian besar takeover akun terjadi saat reset, dan sebagian besar pengguna marah datang saat pemulihan membingungkan.

Tes praktis: minta seseorang di luar tim Anda untuk menyiapkan MFA, lalu kehilangan ponselnya dan mencoba kembali masuk hanya menggunakan langkah-langkah terdokumentasi Anda. Jika itu berubah menjadi chat dengan engineering, Anda akan melihat hal serupa di tiket nyata.

Skenario contoh: portal pelanggan dengan pengguna global

Tim 6 orang menjalankan portal pelanggan yang dipakai oleh 1.200 pengguna aktif di AS, India, Inggris, dan Brazil. Mereka juga memberi akses pada 40 kontraktor yang bolak-balik. Reset kata sandi sudah menimbulkan kebisingan, jadi mereka menambahkan MFA dengan harapan mengurangi takeover akun tanpa membludakkan dukungan.

Mereka mulai dengan SMS OTP sebagai default. Minggu pertama, semuanya tampak baik sampai satu operator menunda pesan di satu wilayah saat jam sibuk. Pengguna minta kode, menunggu, minta lagi, lalu mendapatkan tiga kode sekaligus. Beberapa mencoba kode yang paling lama, gagal, lalu mengunci diri. Dukungan mendapat gelombang tiket: "Kode tidak diterima," "Kodenya selalu salah," "Saya sedang bepergian dan nomor saya berubah." Bahkan tanpa outage, masalah deliverability muncul untuk nomor VoIP, pengguna roaming, dan filter spam ketat.

Mereka menambahkan aplikasi autentikator sebagai opsi dan melihat pola berbeda. Sebagian besar login lancar, tapi kegagalan lebih sporadis: pengguna upgrade ponsel dan aplikasinya tidak memindahkan kode, seseorang menghapus autentikator, atau kontraktor melewatkan langkah "pindai QR" dan terjebak. Tiket itu berbunyi: "Ponsel baru, tidak bisa masuk," "Kode tidak cocok," dan "Saya kehilangan perangkat."

Susunan yang mengurangi kejutan sering terlihat seperti ini:

• Default ke aplikasi autentikator untuk pengguna baru, dengan SMS sebagai cadangan (bukan satu-satunya metode).
• Tawarkan kode pemulihan dan alur perangkat hilang yang jelas yang memicu pemeriksaan manual.
• Minta step-up untuk aksi berisiko seperti mengubah detail pembayaran atau menambah admin baru.
• Untuk kontraktor, gunakan waktu sesi lebih pendek dan periksa ulang di perangkat baru.

Langkah selanjutnya: terapkan MFA tanpa memperlambat produk

Pilih metode MFA default yang cocok untuk sebagian besar pengguna Anda, lalu tambahkan cadangan.

Untuk audiens konsumen, SMS sering menjadi default termudah, dengan aplikasi autentikator tersedia bagi yang bepergian, menggunakan nomor VoIP, atau menginginkan keamanan lebih ketat. Untuk produk tenaga kerja atau yang banyak admin, aplikasi autentikator seringkali default lebih baik, dengan SMS disediakan untuk pemulihan.

Sebelum peluncuran, tulis playbook dukungan sederhana dan putuskan apa yang akan Anda catat. Anda tidak perlu gunung data. Anda perlu cukup untuk menjawab: apakah kami mengirimkannya, apakah pengguna menerimanya, dan apa yang terjadi saat verifikasi.

Log yang biasanya berguna: metode MFA dan cap waktu, respons provider pengiriman (diterima, antre, gagal), jumlah percobaan verifikasi dengan alasan error terakhir, dan metode MFA terakhir yang berhasil serta tanggalnya.

Percepat dukungan dengan satu layar kecil: status MFA pengguna, kegagalan terbaru, dan alur reset terkontrol dengan jejak audit.

Jika Anda membangun portal tanpa banyak koding, AppMaster (appmaster.io) dapat membantu Anda merangkai backend, web app, dan mobile app di sekitar alur ini, termasuk tampilan admin dan pencatatan event yang mengurangi tebak-tebakan saat tiket datang.

Luncurkan dalam pilot dulu, pantau metrik kegagalan selama seminggu, lalu perluas. Pantau tingkat penyelesaian, laju kirim ulang, waktu untuk menyelesaikan MFA, dan volume tiket per 1.000 login. Perbaiki alur, perbarui playbook, lalu skala.