Buana Cyber Security Knowledge

Apa itu Passwordless MFA dan kenapa menjadi prioritas?

Passwordless MFA adalah pendekatan autentikasi yang menghilangkan ketergantungan pada kata sandi sebagai faktor utama, dan menggantinya dengan faktor yang lebih kuat dan lebih tahan phishing—misalnya passkeys (FIDO2/WebAuthn), hardware security key, atau biometrik yang terikat perangkat. Dalam konteks enterprise, passwordless hampir selalu dipasangkan dengan MFA (multi-factor authentication) atau dengan mekanisme yang secara kriptografis sudah memenuhi prinsip “multi-factor” (misalnya “something you have” + “something you are/know” di perangkat).

Alasan utama organisasi mengadopsi passwordless adalah karena kata sandi masih menjadi pintu masuk paling umum untuk insiden: reuse password, credential stuffing, phishing, serta reset password yang rentan social engineering. Passwordless yang dirancang dengan benar dapat menurunkan risiko ini secara signifikan, sekaligus mengurangi beban helpdesk akibat reset kata sandi.

Prinsip desain: apa yang “benar” dalam passwordless

Sebelum masuk roadmap, tetapkan prinsip agar implementasi tidak hanya “tanpa password”, tetapi juga aman, tahan phishing, dan dapat dioperasikan:

• Phishing-resistant: prioritaskan metode FIDO2/WebAuthn (passkeys atau security key) dibanding OTP SMS atau OTP email.
• Device-bound + cryptographic: kredensial berbasis kunci publik/privat yang tersimpan aman di perangkat (TPM/secure enclave) atau hardware key.
• Account recovery aman: tanpa desain pemulihan yang kuat, passwordless bisa “balik” menjadi celah baru.
• Progressive rollout: mulai dari kelompok risiko tinggi dan aplikasi utama, lalu meluas.
• Observability: ukur adopsi, kegagalan login, dan anomali untuk perbaikan berkelanjutan.

Passwordless MFA Implementation Roadmap (Tahap demi tahap)

Roadmap berikut dapat dipakai untuk organisasi menengah hingga besar. Durasi tiap tahap tergantung kompleksitas IAM, jumlah aplikasi, dan readiness perangkat pengguna.

1) Assessment & Alignment (2–6 minggu)

Tujuan tahap ini adalah memahami kondisi awal dan menyelaraskan target bisnis, keamanan, dan operasional.

• Pemetaan aplikasi: identifikasi aplikasi yang memakai SSO (SAML/OIDC), aplikasi legacy, VPN, VDI, dan sistem kritikal (ERP, HRIS, finance).
• Inventaris identitas: jenis pengguna (karyawan, kontraktor, admin, vendor), lokasi, dan kebutuhan akses.
• Analisis risiko: kasus phishing, kebocoran kredensial, akun admin, akses jarak jauh, serta pola serangan yang relevan.
• Kesiapan perangkat: OS/versi browser, ketersediaan TPM/secure enclave, kebijakan MDM/endpoint management, dan kebijakan BYOD.
• Regulasi & kepatuhan: kebutuhan audit, retensi log, persyaratan autentikasi kuat, dan standar internal.

Output yang baik dari tahap ini adalah baseline (bagaimana autentikasi berjalan sekarang), daftar prioritas aplikasi, dan definisi “passwordless sukses” yang terukur.

2) Strategy & Architecture (2–8 minggu)

Di tahap ini, Anda memilih pendekatan teknis dan merancang arsitektur target.

• Pilih metode passwordless:
  • Passkeys (FIDO2/WebAuthn) untuk aplikasi web modern dan SSO.
  • Hardware security key untuk admin, akses sensitif, atau lingkungan dengan risiko tinggi.
  • Platform authenticator seperti Windows Hello for Business atau biometrik perangkat untuk karyawan yang device-managed.
• Tentukan model identitas: terpusat via IdP (Identity Provider) dengan SSO, sehingga kontrol autentikasi konsisten.
• Rancang kebijakan akses: berbasis risiko dan konteks (lokasi, device posture, sensitivity aplikasi), termasuk step-up authentication.
• Rancang pemulihan akun: recovery code, verifikasi helpdesk dengan prosedur ketat, atau second device. Hindari recovery yang mudah dipalsukan.
• Segmentasi pengguna: minimal pisahkan admin/privileged users, pengguna standar, dan pengguna eksternal.

Tips defensif: jadikan phishing-resistant MFA sebagai standar untuk akun admin dan akses remote sejak awal, karena dampaknya paling besar.

3) Governance, Policy, dan RACI (paralel)

Passwordless menyentuh keamanan, IT ops, dan pengalaman pengguna. Tetapkan governance agar tidak tersendat saat rollout.

• RACI: siapa pemilik IdP, siapa pemilik kebijakan akses, siapa pemilik perangkat (endpoint/MDM), dan siapa pemilik support.
• Policy: standar autentikasi, requirement untuk perangkat yang didukung, aturan pendaftaran (enrollment) passkey, dan masa transisi.
• Standar logging: event autentikasi, perubahan faktor, reset/recovery, serta integrasi ke SIEM.
• Prosedur break-glass: akun darurat dengan kontrol ketat (misalnya disimpan di vault), dipakai hanya saat IdP bermasalah.

4) Pilot Terkontrol (4–10 minggu)

Pilot adalah tempat Anda menemukan masalah nyata: perangkat, browser, jaringan, kebiasaan pengguna, dan edge cases.

• Pilih grup pilot: gabungan pengguna IT, security, dan perwakilan unit bisnis; termasuk beberapa pengguna yang sering mobile.
• Definisikan kriteria sukses: tingkat adopsi passkey, penurunan reset password, waktu login, dan tingkat kegagalan autentikasi.
• Siapkan materi enablement: panduan singkat pendaftaran passkey, cara login lintas perangkat, dan langkah pemulihan yang resmi.
• Uji skenario kritikal: perangkat hilang, pengguna ganti ponsel, perangkat baru, pengguna remote, serta akses aplikasi inti.
• Monitoring: pantau error rate autentikasi, mismatch kebijakan, dan event anomali (misalnya percobaan login berulang).

Praktik terbaik: sediakan fallback yang aman selama pilot (misalnya MFA lain yang lebih kuat daripada SMS), namun target akhirnya tetap passwordless.

5) Integrasi Aplikasi & Modernisasi (berjalan bersamaan)

Hambatan terbesar passwordless sering bukan di faktor autentikasi, tetapi di aplikasi legacy.

• Prioritaskan aplikasi: mulai dari aplikasi paling sering dipakai dan paling berisiko (email, collaboration, VPN, HR/finance).
• Gunakan SSO: dorong aplikasi ke OIDC/SAML melalui IdP; ini mengurangi variasi login yang membingungkan pengguna.
• Legacy workaround: untuk aplikasi yang belum mendukung SSO, rencanakan upgrade, proxy/bridge resmi, atau segmentasi akses yang lebih ketat.
• Privileged access: pastikan admin memakai metode phishing-resistant dan pertimbangkan integrasi dengan PAM (Privileged Access Management).

6) Rollout Bertahap (8–24 minggu)

Setelah pilot stabil, lakukan rollout bertahap dengan kontrol perubahan yang rapi.

• Wave-based rollout: per departemen/lokasi, bukan “big bang”.
• Komunikasi: jelaskan alasan, manfaat, dan tanggal efektif. Sertakan FAQ internal dan kanal support.
• Enrollment campaign: jadwalkan periode pendaftaran passkey yang dipantau; berikan notifikasi bertahap.
• Policy enforcement bertingkat:
  • Tahap 1: password + MFA (transisi) dengan dorongan penggunaan passkey.
  • Tahap 2: default passwordless untuk aplikasi tertentu.
  • Tahap 3: nonaktifkan password untuk segmen yang sudah siap (jika sistem mendukung).
• Helpdesk readiness: siapkan runbook untuk kasus umum (perangkat hilang, user lockout, recovery) dan verifikasi identitas yang ketat.

Kunci sukses adalah membuat perubahan terasa “lebih mudah” bagi pengguna, bukan sekadar “lebih aman”. Jika login jadi lebih rumit, pengguna akan mencari jalan pintas dan risiko meningkat.

7) Operasional Berkelanjutan: Monitoring, Response, dan Improvement

Passwordless bukan proyek sekali jalan. Setelah rollout, fokus pada operasi:

• Monitoring keamanan: deteksi percobaan registrasi faktor mencurigakan, perubahan faktor tanpa alasan, anomali lokasi/IP, dan brute force pada fallback.
• Audit & compliance: pastikan log autentikasi dan perubahan faktor tersimpan sesuai kebutuhan audit.
• Lifecycle device: proses onboarding/offboarding perangkat, rotasi perangkat, dan kebijakan perangkat hilang.
• Review kebijakan: evaluasi kembali fallback, pengecualian, dan akses aplikasi baru.
• Tabletop exercise: uji prosedur pemulihan saat IdP down atau saat ada insiden identitas.

Checklist kontrol keamanan yang sering terlewat

• Enforce phishing-resistant untuk admin dan akses berisiko tinggi (misalnya akses jarak jauh).
• Batasi metode fallback: hindari SMS sebagai default; jika terpaksa, gunakan hanya sementara dan dengan kompensasi kontrol.
• Strong identity proofing untuk recovery: verifikasi berlapis dan terdokumentasi, terutama untuk permintaan via telepon.
• Protect enrollment: pendaftaran faktor harus memerlukan autentikasi kuat dan pemeriksaan konteks.
• Least privilege: passwordless tidak menggantikan kebutuhan segmentasi hak akses.
• Secure logging: event autentikasi dan perubahan faktor harus masuk SIEM untuk korelasi.

Metrik untuk mengukur keberhasilan roadmap

Agar roadmap tidak berhenti di “sudah implement”, tetapkan metrik yang bisa dipantau per minggu/bulan:

• Adopsi passkey: persentase pengguna yang sudah mendaftarkan passkey/hardware key.
• Password usage rate: seberapa sering password masih dipakai (target menurun konsisten).
• Helpdesk tickets: volume reset password, lockout, dan recovery (idealnya turun setelah stabil).
• Login success rate: tingkat keberhasilan login dan waktu rata-rata login.
• Security outcomes: penurunan insiden phishing sukses, pengambilalihan akun, dan temuan audit terkait autentikasi.

Kesalahan umum saat menerapkan passwordless MFA

• Menganggap semua MFA sama: OTP mudah dipancing phishing; passwordless seharusnya fokus pada phishing-resistant.
• Recovery terlalu longgar: pemulihan akun yang lemah dapat menjadi jalur pengambilalihan akun.
• Rollout tanpa dukungan operasional: helpdesk tidak punya runbook, sehingga banyak pengecualian dan “sementara” yang jadi permanen.
• Terlalu banyak pengecualian: exception policy yang luas merusak konsistensi dan memperbesar permukaan serangan.
• Tidak mengintegrasikan aplikasi: jika aplikasi tetap punya login lokal, pengguna akan kembali ke password.

FAQ tentang Passwordless MFA Implementation Roadmap

1) Apakah passwordless berarti tidak butuh MFA lagi?

Tidak selalu. Banyak implementasi passwordless memang sudah kuat karena berbasis kriptografi dan perangkat (misalnya passkeys), namun di enterprise biasanya tetap diterapkan kebijakan MFA/step-up untuk skenario berisiko (akses dari perangkat tidak dikelola, lokasi baru, atau akses ke sistem sensitif). Fokusnya adalah memastikan faktor yang dipakai tahan phishing dan kebijakan aksesnya adaptif.

2) Metode mana yang paling direkomendasikan untuk tahan phishing?

Secara umum, FIDO2/WebAuthn (passkeys atau hardware security key) dianggap paling tahan phishing karena proses autentikasi terikat pada domain dan menggunakan kriptografi kunci publik. Ini mengurangi risiko pengguna “mengetik kode” di situs palsu.

3) Bagaimana menangani pengguna yang kehilangan perangkat?

Rancang account recovery sejak awal: misalnya pendaftaran lebih dari satu faktor (second device atau hardware key cadangan), recovery code yang dikelola aman, serta proses helpdesk dengan verifikasi identitas ketat dan jejak audit. Hindari recovery berbasis data yang mudah ditebak atau mudah dipalsukan.

4) Apakah passwordless cocok untuk aplikasi legacy?

Bisa, tetapi biasanya perlu strategi tambahan: mendorong aplikasi ke SSO, melakukan modernisasi, atau membatasi akses melalui kontrol jaringan dan kebijakan akses yang lebih ketat. Roadmap yang realistis biasanya memprioritaskan aplikasi modern terlebih dahulu sambil menyiapkan rencana migrasi untuk legacy.

5) Kapan waktu yang tepat untuk menonaktifkan password sepenuhnya?

Ketika adopsi passkey tinggi, proses recovery terbukti aman, aplikasi utama sudah terintegrasi SSO, dan metrik operasional stabil (misalnya login success rate baik serta ticket helpdesk menurun). Banyak organisasi melakukan ini bertahap per segmen pengguna, dimulai dari pengguna dengan perangkat terkelola.

Penutup

Roadmap implementasi passwordless MFA yang matang berangkat dari assessment, desain arsitektur dan governance, lalu pilot yang terukur sebelum rollout bertahap. Jika Anda memprioritaskan metode phishing-resistant, menyiapkan recovery yang kuat, dan mengelola perubahan dengan baik, passwordless bukan hanya tren—melainkan peningkatan fundamental terhadap keamanan identitas sekaligus pengalaman pengguna.