Portal Pelanggan Masih Pakai OTP dan Password: Kapan Passkeys Layak Masuk Roadmap Bisnis?

Banyak portal pelanggan masih hidup dengan kombinasi yang sangat familiar: email, password, OTP lewat SMS atau email, lalu tombol “lupa password” ketika pelanggan tidak bisa masuk.

Selama masih berjalan, pola ini sering dianggap cukup.

Masalahnya, “cukup berjalan” belum tentu berarti sehat untuk bisnis. Login adalah pintu pertama ke akun pelanggan. Kalau pintu ini terlalu sering macet, efeknya bukan hanya teknis. Pelanggan gagal cek status order, admin menerima chat reset akun, tim support menangani OTP yang tidak masuk, dan bisnis mulai kehilangan trust dari hal yang tampak kecil: pelanggan tidak bisa masuk ke portalnya sendiri.

Di sisi lain, langsung mengganti semua password dan OTP dengan passkeys juga bukan keputusan ringan. Passkeys memang menawarkan pengalaman login yang lebih modern dan lebih tahan terhadap phishing dibanding password tradisional. Tetapi untuk bisnis, pertanyaan utamanya bukan “apakah passkeys lebih canggih?”

Pertanyaan yang lebih berguna adalah: kapan masalah login sudah cukup penting untuk masuk roadmap bisnis?

Password dan OTP bukan selalu masalah hari ini

Tidak semua bisnis perlu buru-buru membangun passkeys.

Jika portal pelanggan jarang dipakai, risiko akun rendah, proses recovery masih terkendali, dan mayoritas pelanggan tidak mengalami hambatan login, passkeys mungkin belum menjadi prioritas pertama. Masih ada pekerjaan digital lain yang bisa lebih berdampak: memperbaiki form lead, merapikan halaman layanan, mempercepat checkout, atau menyambungkan data operasional.

Tetapi situasinya berbeda ketika portal sudah menjadi bagian penting dari layanan.

Contohnya:

• pelanggan rutin mengecek tagihan, status order, jadwal, membership, tiket, atau dokumen;
• tim support sering menerima keluhan OTP tidak masuk;
• password reset menjadi pekerjaan admin yang berulang;
• pelanggan memakai akun dari banyak perangkat;
• risiko account takeover mulai mengganggu trust;
• login gagal membuat pelanggan pindah ke WhatsApp manual;
• bisnis mulai menyiapkan portal baru, aplikasi pelanggan, atau dashboard B2B.

Pada titik itu, autentikasi bukan lagi detail backend. Autentikasi menjadi bagian dari pengalaman pelanggan dan biaya operasional.

Friction login sering terlihat sebagai masalah support

Masalah login jarang muncul di dashboard sebagai “strategi autentikasi buruk.” Yang terlihat biasanya lebih sederhana.

Admin bilang pelanggan sering tidak bisa masuk. Support bilang OTP terlambat. Sales bilang pelanggan lama tetap minta dibantu lewat chat. Tim operasional bilang portal sudah ada, tetapi pengguna tetap memilih cara manual. Developer melihat log error, tetapi sulit menghubungkannya ke trust pelanggan.

Ini sebabnya bisnis sering salah membaca gejala.

Jika pelanggan tidak bisa masuk, mereka tidak selalu menyebutnya sebagai masalah keamanan atau UX. Mereka hanya merasa layanan tidak rapi. Dalam bisnis B2B, ini bisa membuat portal yang seharusnya mengurangi pekerjaan admin justru menjadi sumber tiket baru. Dalam bisnis consumer, login yang sulit bisa membuat pelanggan batal melanjutkan transaksi, gagal klaim benefit, atau menghindari portal di kunjungan berikutnya.

OTP dan password tetap bisa menjadi bagian dari sistem yang masuk akal. Namun ketika keduanya menjadi sumber friction berulang, bisnis perlu mulai mengukur dampaknya.

Apa yang membuat passkeys menarik?

Passkeys adalah metode login modern yang memakai kriptografi kunci publik. Secara sederhana, server tidak perlu menyimpan password pengguna seperti pada model password tradisional. Pengguna masuk dengan mekanisme yang sudah akrab di perangkatnya, seperti PIN perangkat, fingerprint, face unlock, atau security key, tergantung platform dan konfigurasi.

Google for Developers memosisikan passkeys sebagai pendekatan modern untuk meningkatkan pengalaman dan keamanan sign-in, termasuk karena pengguna tidak perlu mengetik password dan server hanya menyimpan public key. FIDO Alliance juga memosisikan passkeys sebagai cara mengganti password sebagai faktor utama autentikasi.

Bagi pengguna, manfaat yang terasa biasanya bukan istilah “kriptografi.” Manfaat yang terasa adalah login lebih sederhana.

Tidak perlu mengingat password. Tidak perlu menunggu SMS. Tidak perlu mengetik kode dari email. Tidak perlu membuat password yang sama di banyak layanan. Jika implementasinya baik, pengguna cukup memilih akun dan mengonfirmasi dengan perangkatnya.

Bagi bisnis, manfaat yang dicari juga praktis:

• mengurangi ketergantungan pada password yang lemah atau dipakai ulang;
• mengurangi friksi login berulang;
• menurunkan beban reset password;
• memperkuat trust pada portal pelanggan;
• membuka jalan ke autentikasi yang lebih tahan phishing;
• membuat pengalaman akun terasa lebih modern tanpa memaksa pengguna belajar konsep baru.

Namun manfaat ini hanya muncul jika alur migrasi, fallback, recovery, dan edukasi pengguna dirancang dengan benar.

OTP bukan selalu cukup aman untuk dijadikan sandaran utama

OTP sering dianggap aman karena ada kode tambahan. Dalam praktiknya, kualitas keamanan OTP sangat bergantung pada kanal, implementasi, dan perilaku pengguna.

NIST SP 800-63B memberi batasan untuk out-of-band authentication, dan sumber implementasi NIST menjelaskan bahwa kanal seperti SMS dan voice melalui PSTN berada dalam status restricted. CISA juga mendorong organisasi bergerak ke MFA yang lebih tahan phishing ketika memungkinkan.

Untuk bisnis, poinnya bukan bahwa semua OTP harus langsung dimatikan. Poinnya adalah OTP tidak boleh diperlakukan sebagai jawaban permanen tanpa audit.

Ada beberapa pertanyaan yang perlu dijawab:

• Apakah OTP dikirim lewat SMS, email, WhatsApp, atau authenticator app?
• Apakah OTP dipakai untuk login utama, recovery, transaksi sensitif, atau semua hal sekaligus?
• Apakah ada rate limit, monitoring, dan deteksi percobaan berulang?
• Apakah pelanggan sering meminta OTP ulang?
• Apakah support bisa mem-bypass proses login?
• Apakah recovery akun lebih lemah daripada login normal?
• Apakah ada audit trail ketika nomor telepon, email, atau perangkat terpercaya diganti?

Jika jawaban pertanyaan ini belum jelas, menambah passkeys tanpa merapikan dasar autentikasi bisa menciptakan kompleksitas baru.

Risiko terbesar sering ada di fallback dan recovery

Banyak diskusi passkeys terlalu fokus ke tombol login. Padahal bagian yang paling menentukan sering justru fallback dan recovery.

Apa yang terjadi jika pelanggan ganti HP? Apa yang terjadi jika passkey belum sinkron? Apa yang terjadi jika pengguna memakai perangkat kantor bersama? Apa yang terjadi jika akun dipakai oleh admin cabang, bukan satu orang pribadi? Apa yang terjadi ketika pengguna kehilangan akses ke email dan nomor telepon lama?

OWASP Multifactor Authentication Cheat Sheet mengingatkan bahwa account recovery adalah jalur autentikasi alternatif, sehingga sebaiknya tidak lebih lemah daripada autentikasi normal. Ini penting untuk bisnis yang ingin modernisasi login. Sistem login bisa terlihat kuat di depan, tetapi tetap rapuh jika recovery bisa dilewati dengan proses manual yang tidak diaudit.

Untuk portal pelanggan, recovery bukan sekadar fitur bantuan. Recovery adalah pintu cadangan ke akun.

Jika pintu utama dibuat kuat tetapi pintu cadangan dibiarkan longgar, risiko akun tetap tinggi. Sebaliknya, jika recovery terlalu ketat tanpa UX yang baik, pelanggan sah bisa terkunci dan support load naik.

Itulah sebabnya passkeys perlu masuk roadmap bersama desain recovery, bukan sebagai fitur tunggal.

Kapan passkeys layak masuk roadmap?

Passkeys mulai layak dipertimbangkan ketika minimal salah satu dari kondisi ini sudah terasa nyata.

Pertama, portal pelanggan sudah menjadi jalur layanan utama. Jika pelanggan perlu login untuk transaksi, status order, invoice, membership, appointment, dokumen, atau support, maka login bukan fitur kecil. Login memengaruhi akses ke layanan.

Kedua, keluhan login sudah menjadi beban operasional. Jika tim support sering menangani OTP tidak masuk, reset password, akun terkunci, atau perubahan nomor/email, berarti masalah autentikasi sudah memakan biaya.

Ketiga, bisnis punya risiko akun yang semakin tinggi. Ini bisa terjadi pada portal dengan data sensitif, nilai transaksi tinggi, akses dokumen penting, akun B2B, atau akun yang bisa mengubah informasi pembayaran dan pengiriman.

Keempat, pelanggan memakai portal secara berulang. Passkeys lebih masuk akal ketika ada kebiasaan login berulang. Untuk one-time form yang jarang dipakai, manfaatnya mungkin belum sebanding dengan kompleksitas.

Kelima, bisnis sedang membangun ulang portal. Momen redesign, rebuild, migrasi stack, atau integrasi identity provider adalah waktu yang lebih masuk akal untuk mengevaluasi autentikasi daripada menambal sistem lama secara terburu-buru.

Keenam, tim sudah siap mengelola perubahan. Passkeys bukan hanya urusan developer. Product, support, admin, dan customer communication perlu memahami apa yang berubah, kapan pengguna ditawarkan passkey, dan bagaimana membantu recovery tanpa membuka celah baru.

Kapan sebaiknya belum dipaksakan?

Passkeys juga bisa belum cocok jika kondisi bisnis belum siap.

Misalnya, basis pengguna banyak memakai perangkat bersama tanpa profil pribadi yang jelas. Atau akun pelanggan sebenarnya dipakai oleh banyak staf dalam satu perusahaan. Atau tim support belum punya prosedur verifikasi identitas yang kuat. Atau sistem lama belum punya logging yang cukup untuk melihat percobaan login, reset, dan perubahan credential.

Dalam kasus seperti ini, memaksa passkeys bisa membuat login terlihat modern tetapi operasionalnya membingungkan.

Roadmap yang lebih sehat mungkin dimulai dari pekerjaan dasar:

• rapikan policy password dan reset;
• audit OTP dan kanal pengiriman;
• tambahkan rate limit dan monitoring;
• pisahkan akses personal dan shared account;
• perbaiki session management;
• buat alur recovery yang bisa diaudit;
• ukur titik friksi login;
• edukasi support soal prosedur bantuan akun.

Setelah fondasi ini jelas, passkeys bisa menjadi langkah modernisasi yang lebih terarah.

Cara masuk roadmap tanpa mengganggu pengguna

Migrasi autentikasi tidak harus menjadi proyek besar yang langsung mengganti semua login.

Pendekatan yang lebih realistis adalah bertahap.

Mulai dari audit. Petakan seluruh jalur masuk akun: login normal, OTP, forgot password, ganti nomor, ganti email, device baru, admin override, support reset, dan tindakan sensitif seperti mengubah alamat atau data pembayaran.

Lalu ukur friction. Berapa banyak OTP diminta ulang? Berapa banyak login gagal? Berapa banyak password reset? Berapa banyak tiket support terkait akun? Pada perangkat apa masalah paling sering terjadi?

Setelah itu, pilih pilot yang sempit. Misalnya passkeys ditawarkan setelah pengguna berhasil login, bukan dipaksa saat pertama kali masuk. Google for Developers juga merekomendasikan prompt passkey pada momen seperti sign-in, security settings, setelah account recovery, atau setelah reauthorization dalam panduan passkeys user journeys.

Kemudian siapkan fallback yang jelas. Pengguna harus tahu apa yang terjadi jika perangkat hilang, akun dipakai di perangkat baru, atau passkey belum tersedia. Support harus punya SOP yang tidak membuka celah social engineering.

Terakhir, pantau adopsi dan dampaknya. Jangan hanya mengukur jumlah passkey yang dibuat. Ukur login success, reset password, tiket recovery, drop-off login, keluhan support, dan penggunaan portal setelah login.

Dengan cara ini, passkeys tidak menjadi eksperimen teknis yang dipaksakan ke pelanggan. Passkeys menjadi bagian dari perbaikan pengalaman akun.

Checklist audit sebelum memutuskan passkeys

Sebelum memasukkan passkeys ke backlog, bisnis bisa memakai checklist sederhana ini.

1. Apakah portal pelanggan dipakai berulang atau hanya sesekali?
2. Apakah login gagal berdampak langsung ke transaksi, layanan, atau trust?
3. Apakah support punya data tentang tiket OTP, password reset, dan akun terkunci?
4. Apakah recovery akun saat ini bisa diaudit?
5. Apakah admin bisa membantu akun pelanggan tanpa bypass yang berisiko?
6. Apakah pengguna memakai akun personal atau shared account?
7. Apakah ada tindakan sensitif yang butuh reauthentication?
8. Apakah sistem sudah punya rate limit, logging, dan monitoring login?
9. Apakah tim siap membuat komunikasi perubahan untuk pelanggan?
10. Apakah ada momen rebuild, redesign, atau integrasi identity yang membuat perubahan lebih efisien?

Jika sebagian besar jawabannya belum jelas, prioritas pertama adalah audit autentikasi. Jika jawabannya sudah jelas dan masalah login memang terasa, passkeys layak masuk roadmap sebagai opsi yang diuji bertahap.

Kesimpulan

Passkeys bukan tombol ajaib yang otomatis menyelesaikan semua masalah login. Tetapi untuk portal pelanggan yang sudah aktif, passkeys bisa menjadi bagian penting dari modernisasi autentikasi.

Keputusan terbaik bukan dimulai dari tren teknologi. Keputusan terbaik dimulai dari gejala bisnis: pelanggan sulit masuk, support sibuk mengurus recovery, OTP sering menjadi hambatan, trust akun makin penting, dan portal mulai menjadi jalur layanan utama.

Jika gejala itu sudah muncul, jangan hanya menambah metode login baru. Audit dulu seluruh pengalaman akun: password, OTP, recovery, fallback, session, logging, support process, dan tindakan sensitif.

Dari sana, bisnis bisa menentukan apakah passkeys perlu masuk roadmap sekarang, nanti, atau setelah fondasi autentikasi diperbaiki.

Dapatkan Audit Teknis Gratis untuk meninjau friction login, risiko recovery, dan kesiapan autentikasi portal pelanggan Anda sebelum modernisasi dilakukan terlalu cepat atau terlalu lambat.