Stack MFA sering terlihat aman di atas kertas, tetapi kacau saat dipakai. Passkey aktif, TOTP tetap wajib, SMS masih dibiarkan untuk semua user, recovery pakai email, lalu compliance minta bukti kontrol. Hasilnya, user bingung, helpdesk sibuk, dan tim security justru memelihara terlalu banyak jalur bypass.
Kalau kamu sedang menyusun phishing-resistant MFA policy, pertanyaan terbesarnya bukan sekadar, “apakah passkey lebih aman?” Pertanyaannya adalah, kapan passkey harus menggantikan faktor lama, dan kapan passkey justru harus melengkapinya. Jawaban yang tepat akan memangkas risiko phishing sekaligus menjaga recovery, auditability, dan kebutuhan regulasi tetap rapi.
Jawaban Singkat, Key Takeaways
Untuk mayoritas login harian, passkey layak menggantikan TOTP dan terutama SMS, karena passkey jauh lebih tahan phishing dan lebih mulus dipakai. Namun, untuk recovery, break-glass, shared device tertentu, atau lingkungan yang sangat diatur, passkey sering lebih tepat sebagai faktor utama yang dilengkapi kontrol cadangan yang dibatasi ketat, bukan satu-satunya mekanisme.
Mengapa banyak kebijakan MFA gagal meski faktornya banyak?
Masalah utamanya biasanya bukan kekurangan faktor. Masalahnya adalah faktor ditumpuk tanpa hirarki risiko. Tim menambah TOTP, SMS OTP, email OTP, backup code, dan passkey sekaligus. Niatnya baik. Efeknya malah buruk.
- Semakin banyak fallback, semakin banyak jalur yang bisa di-phish.
- Semakin banyak pilihan, semakin tinggi error pengguna.
- Semakin longgar recovery, semakin rendah nilai proteksi passkey.
Ini poin yang sering terlewat. MFA stack dinilai dari jalur terlemahnya, bukan faktor terkuatnya. Kalau passkey dipasang, tetapi reset akun masih bisa jatuh ke SMS, attacker akan mengejar SMS itu, bukan mencoba menembus WebAuthn.
Kapan passkey sebaiknya menggantikan TOTP dan SMS?
Untuk login harian user workforce atau admin SaaS, passkey biasanya layak menjadi metode utama, bahkan pengganti. Apalagi bila perangkat terkelola, MDM jalan, dan user memakai platform modern yang mendukung sinkronisasi kredensial dengan baik.
Passkey cocok menggantikan faktor lama jika kondisi ini terpenuhi
- Ancaman utamanya phishing real-time, misalnya reverse proxy phishing kit.
- User memakai device yang relatif terpercaya, baik managed maupun BYOD dengan baseline kontrol jelas.
- Helpdesk siap menangani lifecycle device, seperti ganti HP, hilang laptop, atau rotasi karyawan.
- Aplikasi dan IdP mendukung WebAuthn dengan baik, termasuk enrollment dan recovery.
- Tujuannya mengurangi friksi login, bukan sekadar menambah checklist compliance.
Dalam situasi ini, SMS OTP sebaiknya dipensiunkan lebih dulu. SMS lemah terhadap SIM swap, interception terbatas, dan social engineering. NIST juga sudah lama memberi sinyal bahwa SMS bukan opsi ideal untuk autentikasi berisiko tinggi. Lihat panduan NIST SP 800-63B.
Setelah itu, TOTP bisa ikut dipersempit. Bukan karena TOTP jelek, tetapi karena kode 6 digit tetap bisa dipancing ke situs palsu. Jadi, kalau targetmu benar-benar phishing-resistant MFA, passkey memberi lompatan proteksi yang TOTP tidak bisa capai sendirian.
Kapan passkey lebih tepat melengkapi, bukan menggantikan?
Di sinilah desain kebijakan jadi menarik. Banyak tim terlalu cepat berkata, “kalau sudah ada passkey, matikan semua yang lain.” Bagus secara teori. Belum tentu bagus secara operasi.
Pertahankan faktor pelengkap secara terbatas jika kamu menghadapi kasus ini
- Recovery account harus tetap tersedia saat device utama hilang.
- Lingkungan regulasi meminta separation of duties, audit trail, atau step-up auth tertentu.
- Admin kritikal butuh break-glass access yang bisa diaudit.
- Shared workstation atau kiosk masih dipakai di sebagian proses bisnis.
- Vendor legacy belum penuh mendukung passkey atau resident credential flow.
Namun, pelengkap bukan berarti semua fallback dibuka lebar. Desain yang sehat biasanya seperti ini:
- Passkey untuk login utama.
- TOTP atau hardware key untuk recovery atau step-up pada peran tertentu.
- SMS hanya sebagai opsi terakhir, idealnya dinonaktifkan untuk admin dan user berisiko tinggi.
Pakai matriks ini saat menyusun phishing-resistant MFA policy
Biar nggak jatuh ke tumpukan faktor yang membingungkan, pakai kerangka 4 lapis ini.
1. Primary auth
Tentukan metode login default. Untuk mayoritas organisasi modern, jawabannya adalah passkey.
2. Step-up auth
Tentukan kapan user perlu verifikasi tambahan, misalnya saat akses data sensitif, ubah billing, ekspor data besar, atau reset policy. Di sini, hardware key atau passkey kedua sering lebih kuat daripada TOTP.
3. Recovery
Pisahkan recovery dari login biasa. Ini kesalahan yang sering terjadi. Kalau recovery terlalu mudah, attacker akan menghindari login dan langsung menyerang helpdesk atau flow reset akun.
4. Exception governance
Dokumentasikan siapa yang boleh memakai fallback, berapa lama, di kondisi apa, dan siapa yang menyetujui. Tanpa lapisan ini, pengecualian kecil akan berubah jadi bypass permanen.
Kalau topik ini relevan buat timmu, baca juga passkeys enterprise dan device trust serta cara recovery passkey tanpa menghidupkan lagi password.
Satu ide yang sering bikin kebijakan jauh lebih kuat
Jangan samakan kebijakan MFA berdasarkan jenis user. Samakan berdasarkan recoverability. Ini lebih berguna daripada sekadar membagi user menjadi admin dan non-admin.
Contohnya, dua user bisa sama-sama bukan admin. Tetapi kalau satu user bisa menyetujui transfer, mengakses data pelanggan, atau mengubah SSO policy, maka recovery akunnya harus jauh lebih ketat. Jadi, klasifikasi yang baik bukan hanya privilege level, tetapi juga dampak bila akun diambil alih lewat jalur recovery.
Pendekatan ini nyambung dengan prinsip dari FIDO Alliance dan panduan Microsoft soal autentikasi tahan phishing. Fokusnya bukan menambah tantangan login, tetapi menghilangkan peluang kredensial dicuri sejak awal. Lihat juga referensi authentication strengths di Microsoft Entra.
Kesalahan desain yang paling sering muncul
- Passkey aktif, SMS tetap default. Ini membuat upgrade keamanan hampir tidak terasa.
- TOTP diwajibkan di atas passkey untuk semua login. Keamanan naik sedikit, friksi naik banyak.
- Recovery lewat email tanpa kontrol tambahan. Email inbox lalu menjadi single point of failure.
- Break-glass account tidak diuji. Saat insiden datang, akun darurat justru macet.
- Kebijakan sama untuk semua peran. Padahal risiko operasional dan compliance tiap role berbeda.
Rekomendasi praktis untuk security architect, compliance, dan admin SaaS
- Pensiunkan SMS lebih dulu, terutama untuk admin, finance, dan role sensitif.
- Naikkan passkey sebagai default login untuk user yang device-ready.
- Pertahankan TOTP secara terbatas hanya untuk recovery terkontrol atau vendor legacy.
- Buat policy exception tertulis, lengkap dengan expiry date dan approval owner.
- Uji recovery dan break-glass tiap kuartal, bukan hanya saat audit.
- Bedakan user policy berdasarkan dampak recovery, bukan cuma job title.
FAQ
Apakah passkey selalu lebih aman daripada TOTP?
Untuk phishing resistance, ya, umumnya lebih aman. TOTP masih bisa dicuri lewat situs phishing real-time, sedangkan passkey berbasis origin binding sehingga jauh lebih sulit dipakai attacker di domain palsu.
Apakah SMS OTP harus langsung dimatikan untuk semua user?
Tidak selalu harus sekaligus. Namun, untuk admin, role sensitif, dan tenant berisiko tinggi, SMS sebaiknya diprioritaskan untuk dipensiunkan lebih dulu. Untuk user lain, kamu bisa pakai fase transisi yang jelas.
Kalau sudah pakai passkey, apakah TOTP masih perlu?
Masih bisa perlu, tetapi perannya berubah. TOTP lebih cocok jadi recovery terbatas atau jembatan untuk sistem legacy, bukan lapisan wajib untuk semua login harian.
Bagaimana cara menjelaskan ini ke tim compliance?
Bahas dengan bahasa kontrol, bukan hype teknologi. Tunjukkan bahwa passkey menurunkan risiko phishing, sementara recovery, exception governance, dan audit trail tetap dipertahankan secara formal dan terukur.
Kesimpulannya sederhana. Passkey bukan aksesori MFA. Dalam kebijakan yang matang, passkey biasanya menjadi faktor utama. Setelah itu, TOTP dipersempit perannya, SMS dipensiunkan sejauh mungkin, dan recovery diperlakukan sebagai kontrol risiko tersendiri. Kalau kamu masih menumpuk semua faktor sekaligus, kemungkinan besar kebijakanmu terlihat lengkap, tetapi belum tentu tahan phishing.
Kalau kamu sedang merancang ulang kebijakan autentikasi di organisasi, coba audit dulu satu hal ini, jalur fallback mana yang paling mudah dieksploitasi hari ini. Dari situ, kamu akan tahu faktor mana yang harus diganti, mana yang cukup dilengkapi, dan mana yang seharusnya sudah pensiun.
