Yovita NabilaPasswordless authentication sudah melewati fase eksperimen. Microsoft, Apple, dan Google telah mendorong passkeys dan login tanpa password ke pengguna luas, sementara banyak enterprise Indonesia masih hidup dengan Active Directory lama, OTP yang mudah direlay, dan helpdesk reset password yang tidak pernah benar-benar turun. Pertanyaan untuk CIO bukan lagi apakah password lemah, melainkan kapan organisasi punya jalur migrasi yang aman, bisa diaudit, dan tidak membuat operasi harian macet.
Masalahnya, banyak proyek “passwordless” berhenti di layar login yang lebih nyaman. Recovery flow masih memakai password lama, admin masih punya pengecualian manual, dan bukti audit tidak selalu menunjukkan siapa memegang faktor autentikasi saat akses terjadi. Jadi passwordless authentication harus dibaca sebagai program identitas, bukan fitur UI.
Daftar Isi
TL;DR
- Passwordless authentication yang matang menghapus password dari alur utama, tetapi tetap butuh recovery, audit trail, dan exception handling.
- Passkeys, FIDO2, dan WebAuthn membuat autentikasi terikat ke origin, sehingga lebih tahan phishing dibanding OTP.
- SMS, TOTP, push, platform passkey, dan YubiKey punya tingkat risiko berbeda.
- Migrasi terbaik dimulai dari role berisiko tinggi, bukan seluruh karyawan sekaligus.
- Di Indonesia, desain harus membaca UU ITE, PP 71/2019, UU PDP, dan aturan sektor jika berlaku.
Password Tidak Lagi Cocok untuk Risiko Enterprise
Password gagal bukan hanya karena pengguna memilih kata yang lemah. Password bisa disalin, dijual, dipakai ulang, dan direlay lewat phishing proxy. Dalam enterprise, satu password sering membuka banyak jalur: email, SSO, VPN, aplikasi HR, dashboard finance, sampai akses admin.
Masalah makin besar ketika reset password masih manual. Helpdesk bisa menjadi titik social engineering jika prosedurnya terlalu longgar. Penyerang tidak perlu menebak password ketika bisa menekan proses pemulihan akun.
Kewajiban hukumnya juga tidak berhenti di “sudah ada MFA”. UU ITE Pasal 15 meminta penyelenggara sistem elektronik menjalankan sistem secara andal dan aman. PP 71 Tahun 2019 memperkuatnya lewat Pasal 22 tentang rekam jejak audit, Pasal 24 tentang prosedur dan sarana pengamanan, serta Pasal 26 tentang kerahasiaan, keutuhan, keautentikan, keteraksesan, ketersediaan, dan ketertelusuran. Untuk data pribadi, UU PDP Pasal 39 menuntut langkah teknis dan operasional untuk mencegah akses tidak sah.
Insight praktis
Dalam assessment identitas, Docotel sering melihat masalah password bukan di aplikasi utama, tetapi di jalur samping: akun vendor, akun admin lokal, recovery manual, dan user exception yang dibiarkan terlalu lama.
Passwordless Login Bukan Satu Teknologi
Passwordless login berarti pengguna tidak memasukkan password sebagai faktor utama. Tetapi cara mencapainya berbeda. Platform passkey menyimpan kredensial kriptografis di perangkat seperti laptop atau ponsel. FIDO2 adalah standar untuk autentikasi public-key tanpa secret bersama. WebAuthn adalah API web yang dipakai browser dan layanan untuk menjalankan proses tersebut. Hardware key seperti YubiKey bertindak sebagai authenticator fisik.
Pembeda pentingnya adalah phishing resistance. OTP SMS dan TOTP menambah faktor, tetapi kode tetap bisa diketik ulang ke situs palsu. Push notification lebih nyaman, tetapi bisa terkena approval fatigue. FIDO2/WebAuthn berbeda karena autentikasi terikat ke origin layanan; situs palsu tidak bisa meminta respons valid untuk domain asli. Ini sejalan dengan Yubico WebAuthn Developer Guide dan NIST SP 800-63B.
Untuk CIO, pertanyaannya bukan “pakai passwordless atau tidak”, tetapi faktor mana untuk pegawai umum, admin, vendor, dan akun break-glass.
Sinyal Big Tech: Passwordless Authentication Sudah Masuk Arus Utama
Microsoft menulis bahwa hampir seluruh karyawan internalnya sudah memakai opsi passwordless, lalu membuka penggunaan tanpa password untuk Microsoft account melalui pengumuman passwordless future. Apple memperkenalkan Passkeys sebagai bagian dari iOS 16, iPadOS 16, macOS Ventura, dan Safari melalui Apple Passkeys. Google juga memosisikan passkeys sebagai pengganti password melalui pengumuman passkeys.
Sinyal ini penting karena browser, OS, IdP, dan perangkat pengguna bergerak ke arah yang sama. Tetapi adopsi platform besar tidak otomatis membuat perusahaan siap. Banyak organisasi Indonesia masih punya aplikasi internal yang belum mendukung modern authentication, shared workstation di cabang, vendor yang login lewat VPN, dan akun break-glass yang sengaja dibuat mudah saat insiden.
Maturity Matrix: dari SMS sampai YubiKey FIDO2
Passwordless authentication sebaiknya dilihat sebagai tingkat kematangan, bukan pilihan biner. Tabel ini bisa dipakai untuk diskusi awal antara IT security, enterprise architecture, dan operasi.
| Tingkat kontrol | Contoh metode | Ketahanan phishing | Cocok untuk | Catatan implementasi |
|---|---|---|---|---|
| Password + SMS OTP | Kode via SMS | Rendah | Akses risiko rendah sementara | Rentan SIM swap dan relay |
| Password + TOTP | Authenticator app | Sedang | Aplikasi internal umum | Kode masih bisa direlay |
| Push MFA | Mobile approval | Sedang | Workforce mobile | Perlu number matching |
| Platform passkey | Windows Hello, iCloud Keychain, Android passkey | Tinggi | User dengan perangkat terkelola | Perlu kebijakan device lifecycle |
| YubiKey/FIDO2 | Roaming hardware key | Sangat tinggi | Admin, privileged user, vendor kritikal | Perlu enrollment, backup key, recovery |
Untuk sebagian organisasi, tahap awal bukan langsung menghapus semua password. Workforce umum bisa mulai dari platform passkey di perangkat managed, sedangkan admin infrastruktur dan finance approver memakai YubiKey. Pembeda utamanya: private key tidak keluar dari authenticator, dan autentikasi FIDO2/WebAuthn terikat ke origin layanan.
Catatan arsitektur
Passwordless yang hanya mengejar UX sering gagal di audit. Passwordless yang sehat punya bukti enrollment, bukti autentikasi, policy yang bisa dijelaskan, dan prosedur recovery yang tidak membuka pintu belakang baru.
Dari Legacy AD ke Login Tanpa Password
Login tanpa password tidak dimulai dari membeli hardware key. Ia dimulai dari memetakan siapa login ke mana, lewat protokol apa, dan dengan risiko apa.
Langkah pertama adalah discovery: IdP, AD, Entra ID atau SSO lain, VPN, aplikasi legacy, perangkat user, browser minimum, dan daftar akun privileged. Langkah kedua adalah policy design: siapa wajib passkey, siapa wajib YubiKey, siapa masih boleh OTP sementara, dan kapan pengecualian berakhir. Langkah ketiga adalah pilot sempit tetapi tajam, misalnya IT admin, finance approver, atau tim SOC.
Docotel biasanya menyarankan pilot passwordless authentication punya tiga metrik sejak hari pertama: completion rate enrollment, jumlah exception per minggu, dan waktu recovery saat key hilang atau device diganti. Jika organisasi ada di sektor keuangan, mapping juga perlu membaca panduan OJK dan kontrol siber, misalnya SEOJK 29/SEOJK.03/2022.
Tindak lanjut: Jika tim Anda masih menimbang prioritas passkey, FIDO2, dan YubiKey untuk role berbeda, gunakan workshop sebagai sesi pemetaan kontrol dan rollout.
Peran YubiKey dalam Passwordless Authentication Enterprise
YubiKey relevan ketika organisasi butuh authenticator yang dapat dipindahkan antar perangkat, kuat untuk privileged account, dan cocok untuk shared workstation atau akses vendor yang tidak selalu berada di device corporate.
Dalam model FIDO2, YubiKey menyimpan private key di perangkat. Saat pengguna login, layanan mengirim challenge; YubiKey menandatangani challenge jika origin valid dan user presence terpenuhi. Pola ini membuat phishing proxy jauh lebih sulit dibanding OTP yang bisa disalin. Yubico menjelaskan penggunaan YubiKey untuk passwordless authentication dan phishing-resistant MFA pada halaman passwordless authentication.
Prioritas awal biasanya bukan semua pegawai. Mulai dari domain admin, cloud admin, database admin, finance approver, HR payroll, vendor remote access, dan akun break-glass. Link internal yang relevan: YubiKey enterprise, panduan passwordless dan FIDO2 Indonesia, serta artikel phishing-resistant MFA.
Risiko yang Wajib Ditutup Sebelum Rollout
Passwordless authentication tidak boleh aman pada hari normal tetapi lumpuh saat key hilang, ponsel rusak, karyawan resign, atau admin utama cuti.
Risiko pertama adalah lost key. Mitigasinya: backup key untuk role kritikal, re-enrollment dengan approval ganda, verifikasi identitas internal, dan logging ke ITSM/SIEM. Risiko kedua adalah break-glass account. Akun ini tetap perlu ada, tetapi harus memakai vault, dual control, rotasi berkala, dan review setelah dipakai. Risiko ketiga adalah audit gap: auditor perlu tahu siapa melakukan enrollment, siapa menyetujui exception, kapan key diganti, dan apakah akses yang berhasil bisa ditautkan ke orang yang benar.
Jebakan rollout
Recovery yang terlalu mudah merusak passwordless. Recovery yang terlalu sulit membuat bisnis mencari jalan pintas. Desain yang baik mencari titik tengah: cepat untuk user sah, berat untuk penyerang, dan lengkap untuk audit.
Roadmap 12 Bulan Passwordless Authentication
Roadmap tidak harus menunggu semua aplikasi sempurna. Tujuannya adalah menurunkan risiko lama sambil menutup pengecualian secara bertahap.
- Bulan 1-2: assessment untuk IdP, AD, SaaS, VPN, endpoint, aplikasi legacy, dan akun privileged.
- Bulan 3: tetapkan policy untuk workforce umum, high-risk user, admin, vendor, dan break-glass.
- Bulan 4: jalankan pilot platform passkey dan YubiKey untuk role berisiko tinggi.
- Bulan 5-6: validasi recovery, backup key, logging, helpdesk script, dan user education.
- Bulan 7-8: perluas ke email, SSO, VPN, finance approval, HR, dan admin console.
- Bulan 9-10: tutup fallback lama yang tidak lagi diperlukan.
- Bulan 11-12: integrasikan event ke SIEM, review exception, dan tetapkan fase berikutnya.
Dalam proyek seperti ini, Docotel lebih suka memulai dari risk-based cohort daripada struktur organisasi. Admin payroll di kantor pusat bisa lebih dulu daripada seluruh divisi marketing, dan vendor produksi bisa lebih dulu daripada karyawan biasa.
Checklist Keputusan CIO Sebelum Mulai
Sebelum procurement atau POC, jawab pertanyaan berikut:
- Apakah sistem kritikal sudah dipetakan ke IdP, protokol login, dan owner bisnis?
- Role mana yang paling dulu butuh phishing-resistant MFA?
- Apakah organisasi akan memakai platform passkey, YubiKey, atau kombinasi?
- Bagaimana prosedur lost key, backup key, dan break-glass?
- Apakah helpdesk punya script verifikasi yang tahan social engineering?
- Event apa yang harus masuk SIEM: enrollment, login, reset, revoke, exception?
- Kapan fallback password lama benar-benar ditutup?
Jika jawaban awal belum jelas, jangan mulai dari pembelian. Mulai dari desain arsitektur, pilot kecil, dan metrik yang bisa dibaca manajemen.
Frequently Asked Questions
Apa beda passwordless authentication dan MFA biasa?
MFA biasa masih bisa memakai password sebagai faktor pertama, lalu menambah OTP atau push. Passwordless authentication menghilangkan password dari alur utama dan memakai faktor seperti passkey atau FIDO2. Perbedaan paling penting ada pada phishing resistance dan desain recovery.
Apakah passwordless login selalu bebas phishing?
Tidak selalu. Passwordless login berbasis OTP atau link email masih bisa memiliki risiko relay atau kompromi email. FIDO2/WebAuthn lebih tahan phishing karena autentikasi terikat ke origin layanan, bukan kode yang diketik ulang oleh pengguna.
Apakah YubiKey wajib untuk semua karyawan?
Tidak harus. Banyak enterprise memulai dari admin, high-risk user, finance approver, vendor kritikal, dan akun break-glass. Workforce umum bisa memakai platform passkey jika perangkatnya terkelola dan recovery flow sudah aman.
Bagaimana jika pengguna kehilangan YubiKey?
Siapkan backup key, proses re-enrollment, approval berlapis untuk role kritikal, dan log ke ITSM/SIEM. Lost key tidak boleh diselesaikan hanya dengan reset cepat lewat telepon karena itu membuka jalur social engineering.
Apakah passkey bisa dipakai dengan Active Directory lama?
Bisa dalam arsitektur bertahap, tetapi biasanya lewat IdP modern, SSO, conditional access, atau lapisan federasi di depan aplikasi. Aplikasi legacy perlu dipetakan satu per satu agar fallback password tidak menjadi celah permanen.
Regulasi Indonesia apa yang relevan untuk passwordless?
Untuk enterprise umum, UU ITE Pasal 15, PP 71/2019, dan UU PDP Pasal 39 relevan sebagai dasar keamanan sistem elektronik dan pencegahan akses tidak sah. Industri keuangan perlu menambahkan aturan sektor seperti OJK atau BI sesuai lingkup bisnis.
Berapa lama rollout passwordless authentication enterprise?
Untuk organisasi menengah-besar, rencana 12 bulan realistis jika dimulai dari assessment, pilot high-risk role, recovery design, perluasan bertahap, dan audit exception. Durasi aktual tergantung jumlah aplikasi legacy, kesiapan IdP, dan kompleksitas user group.
Mulai dari Workshop yang Memetakan Risiko Nyata
Passwordless authentication tidak akan berhasil jika hanya diperlakukan sebagai penggantian layar login. Ia harus menjawab tiga hal sekaligus: risiko phishing turun, user tetap bisa bekerja, dan auditor bisa membaca bukti yang rapi.
Docotel dapat membantu memetakan use case YubiKey, passkey, FIDO2/WebAuthn, recovery process, dan rollout path untuk enterprise Indonesia. Fokus awalnya sederhana: sistem mana yang harus dilindungi dulu, role mana yang paling berisiko, dan bukti audit apa yang wajib tersedia.
Disusun oleh: Tim Solution Architects Docotel
Dipublikasikan: 2026-07-13
Terakhir diperbarui: 2026-07-17
Dedy Surya
Zatira Chairunnisa
Add comment