Microsoft Entra ID bergerak menuju passkey sebagai pengalaman sign-in default dan menghentikan Microsoft-provided SMS serta voice authentication. Bagi tim IT, perubahan ini bukan alasan untuk mengaktifkan semua kebijakan sekaligus. Prioritasnya adalah memetakan metode autentikasi yang masih dipakai, memastikan jalur pemulihan akun, lalu menguji migrasi secara bertahap agar akses kerja tidak terganggu.
Dokumentasi Microsoft menempatkan passkey sebagai metode yang lebih tahan terhadap phishing dibandingkan metode berbasis telepon. Namun kondisi setiap tenant tidak sama. Ada pengguna dengan perangkat lama, proses akses darurat, aplikasi tertentu, dan kebiasaan helpdesk yang perlu diuji sebelum perubahan kebijakan diperluas. Artikel ini membantu tim administrasi Microsoft 365 dan security lead menyusun langkah persiapan yang terukur.
Apa yang berubah di Microsoft Entra?
Microsoft menjelaskan bahwa Entra ID akan menjadikan passkey sebagai pengalaman sign-in default. Bersamaan dengan itu, Microsoft-provided SMS dan voice authentication tidak lagi diposisikan sebagai metode aman dan akan berhenti tersedia secara native di Entra ID. Fakta ini perlu dibedakan dari keputusan operasional tiap organisasi: tenant tetap harus meninjau kebijakan, cakupan pengguna, dan urutan migrasi sesuai lingkungan masing-masing.
Passkey dirancang untuk mengurangi ketergantungan pada metode yang dapat dipancing melalui phishing. Nilai utamanya bukan sekadar mengganti layar login, melainkan memperbaiki cara identitas pengguna dibuktikan saat mengakses layanan. Karena itu, perubahan ini perlu diperlakukan sebagai pekerjaan identitas dan tata kelola akses, bukan hanya konfigurasi satu menu.
Siapa yang perlu ditinjau lebih dulu?
Mulailah dari akun dengan dampak operasional terbesar. Administrator dengan hak istimewa, pengguna yang mengelola keuangan atau data sensitif, serta tim yang memakai akses bersama harus memiliki jalur pemulihan dan prosedur eskalasi yang jelas. Jangan lupa pengguna lapangan, perangkat bersama, dan pemilik aplikasi yang mungkin masih mengandalkan pola autentikasi lama.
- Administrator istimewa: pastikan akun darurat dan proses break-glass terdokumentasi serta diuji.
- Pengguna dengan perangkat terbatas: pahami kesiapan browser, perangkat, dan metode pendaftaran yang tersedia.
- Helpdesk: siapkan prosedur verifikasi identitas saat pengguna kehilangan perangkat atau tidak dapat mendaftar passkey.
- Pemilik aplikasi: identifikasi proses login, akses administratif, atau dependensi operasional yang belum terdokumentasi.
Checklist kesiapan tenant sebelum pilot
| Kondisi yang diperiksa | Risiko bila diabaikan | Bukti yang dikumpulkan | Tindakan berikutnya |
|---|---|---|---|
| Metode autentikasi aktif | Pengguna masih bergantung pada SMS/voice tanpa rencana pengganti | Inventaris metode per kelompok pengguna | Tentukan kelompok pilot dan pengecualian sementara |
| Kebijakan passkey | Pendaftaran tidak konsisten atau tidak sesuai perangkat pengguna | Konfigurasi metode autentikasi dan hasil uji | Sesuaikan kebijakan lalu uji dengan kelompok kecil |
| Recovery akun | Pengguna atau admin terkunci saat perangkat tidak tersedia | Runbook recovery dan bukti simulasi | Perbarui prosedur helpdesk serta eskalasi |
| Conditional Access | Kontrol akses tidak selaras dengan kekuatan autentikasi | Daftar kebijakan dan pemiliknya | Review dampak pilot sebelum perluasan |
| Komunikasi pengguna | Adopsi rendah dan lonjakan tiket dukungan | Materi singkat, FAQ, serta jadwal pilot | Jalankan komunikasi bertahap dan kanal bantuan |
Jangan lewati jalur pemulihan dan akses darurat
Perubahan autentikasi paling sering gagal bukan karena teknologi passkey, melainkan karena jalur pemulihan tidak pernah diuji. Tim harus mengetahui apa yang dilakukan ketika perangkat hilang, pengguna berganti perangkat, atau administrator utama tidak dapat mengakses tenant. Bila menggunakan Temporary Access Pass atau mekanisme recovery lain yang tersedia untuk lingkungan Anda, tetapkan siapa yang berwenang menerbitkannya, bagaimana identitas pengguna diverifikasi, serta bagaimana aktivitas tersebut dicatat.
Untuk akun administratif, pisahkan akses harian dari akses darurat. Uji prosesnya dalam skenario terbatas dan dokumentasikan hasilnya. Tujuannya bukan menciptakan pengecualian permanen, tetapi memastikan organisasi tidak kehilangan kemampuan untuk memulihkan akses ketika kebijakan baru sedang berjalan.
Urutan persiapan 30 hari yang realistis
Minggu pertama: inventaris metode autentikasi aktif, pemilik kebijakan, dan kelompok pengguna prioritas. Minggu kedua: jalankan pilot dengan administrator terpilih, tim IT, serta perwakilan helpdesk. Minggu ketiga: uji recovery, skenario perangkat hilang, dan dampak Conditional Access. Minggu keempat: perbaiki materi komunikasi, tetapkan dukungan, dan putuskan apakah perluasan dapat dilakukan per kelompok.
Urutan ini adalah panduan operasional, bukan jadwal wajib dari Microsoft. Kecepatan rollout harus mengikuti hasil pilot, risiko bisnis, dan kemampuan tim mendukung pengguna. Organisasi yang menemukan masalah kompatibilitas sebaiknya memperbaiki bukti dan prosesnya dahulu, bukan memaksakan perluasan karena tenggat internal.
Kesalahan yang perlu dihindari
- Menganggap semua pengguna siap hanya karena kebijakan sudah aktif.
- Mengubah akses admin tanpa menguji prosedur break-glass.
- Menghapus metode lama sebelum jalur recovery dan helpdesk siap.
- Menganggap pengalaman default sama dengan enforcement yang identik pada setiap tenant.
- Mengabaikan komunikasi pengguna dan bukti keberhasilan pilot.
FAQ
Apakah semua pengguna langsung kehilangan SMS?
Tidak sebaiknya membuat asumsi seperti itu. Microsoft menjelaskan arah perubahan menuju passkey default serta penghentian Microsoft-provided SMS dan voice authentication, tetapi tim tenant perlu memeriksa konfigurasi, cakupan, dan rencana migrasinya sendiri.
Apa yang harus diuji sebelum passkey diperluas?
Uji pendaftaran pengguna, perangkat yang dipakai, kebijakan akses, proses recovery, pengalaman helpdesk, dan akses administrator. Simpan bukti hasil pengujian agar keputusan perluasan dapat dipertanggungjawabkan.
Bagaimana peran Conditional Access?
Conditional Access membantu organisasi menyelaraskan kondisi akses dengan tingkat perlindungan yang diperlukan. Review kebijakan sebelum pilot agar perubahan metode autentikasi tidak menimbulkan hambatan akses yang tidak direncanakan.
Mulai dari asesmen identitas yang terarah
Jika tim Anda ingin menilai kesiapan Entra ID, myBATICloud dapat membantu meninjau metode autentikasi, jalur pemulihan akun, kebijakan akses, dan rencana pilot yang sesuai dengan lingkungan Microsoft 365 Anda. Mulai dari asesmen singkat agar perubahan autentikasi tidak mengganggu akses operasional.
Untuk menempatkan perubahan autentikasi ini dalam perencanaan layanan yang lebih luas, lihat juga solusi dan layanan myBATICloud untuk kebutuhan operasional, keamanan, dan pengelolaan IT.
nn
Sumber utama: Microsoft Learn - Passkeys by default and retirement of Microsoft-provided SMS and voice authentication.