Passkey memang memangkas phishing dan reset password, tetapi masalah operasional belum hilang. Shared accounts, break-glass access, dan service desk workflow harus didesain ulang supaya cepat dipakai saat darurat, tetap bisa diaudit, dan tidak membuka jalur bypass permanen.
Kalau timmu masih menyelesaikan edge case dengan akun bersama, OTP verbal, atau reset manual tanpa verifikasi kuat, rollout passkey justru bisa memindahkan risiko, bukan menghapusnya.
Passkey sering dijual sebagai obat untuk masalah login. Memang benar, phishing turun, password reuse hilang, dan friction login berkurang. Namun di lapangan, tim security ops, helpdesk, dan compliance biasanya mentok di tiga area yang jarang dibahas, shared accounts, break-glass access, dan reset akses saat user lagi panik.
Masalahnya sederhana. Login personal makin kuat, tetapi workflow operasional lama sering tetap hidup diam-diam. Akibatnya, organisasi punya autentikasi modern di depan, tetapi masih menyimpan bypass rapuh di belakang.
Kenapa dunia passkey tetap punya masalah operasional
Passkey didesain untuk identitas individual. Satu user, satu perangkat tepercaya, satu gesture biometrik atau PIN lokal. Itu bagus untuk keamanan, tetapi justru berbenturan dengan kebiasaan lama seperti akun admin bersama, akun vendor bersama, atau akun darurat yang dipakai bergantian.
Di sinilah banyak implementasi gagal. Tim menghapus password, tetapi belum mengganti proses bisnisnya. Hasilnya, helpdesk jadi jalur darurat utama, lalu service desk berubah menjadi mesin override autentikasi.
- Shared accounts sulit diaudit karena identitas pemakai kabur.
- Break-glass access sering terlalu sakti, lalu dipakai di luar kondisi darurat.
- Helpdesk reset sering kembali ke verifikasi lemah, misalnya data HR statis atau OTP verbal.
Kesalahan paling umum, menganggap passkey bisa menggantikan semua use case
Banyak tim mencoba memaksa semua skenario ke login personal berbasis passkey. Kedengarannya bersih. Praktiknya, ini sering memicu workaround liar.
Yang lebih aman justru bukan memaksa semua akun jadi personal. Yang lebih aman adalah memisahkan akun manusia, akun fungsional, dan akses darurat ke tiga jalur kontrol berbeda. Ini lebih ribet di desain awal, tetapi jauh lebih sehat saat audit dan insiden.
Framework praktis, pisahkan 3 lapisan akses
1. Human identity layer
Semua user biasa, admin, dan engineer login dengan identitas personal plus passkey. Tidak ada akun bersama untuk aktivitas harian. Semua approval, ticket action, dan privileged escalation harus menempel ke identitas ini.
2. Functional access layer
Kalau sistem memang butuh identitas non-personal, misalnya akun kiosk, NOC dashboard, atau akun service desk station, perlakukan itu sebagai functional account, bukan shared account liar. Batasi scope, batasi jaringan, batasi jam pakai, dan wajibkan session recording atau proxied access.
3. Emergency access layer
Break-glass account tidak boleh jadi akun admin cadangan yang dipakai saat malas. Akses ini hanya aktif untuk kondisi darurat, misalnya IdP down, device attestation bermasalah, atau admin utama terkunci saat insiden besar.
Kalau tiga layer ini dicampur, kontrolmu kabur. Kalau dipisah, audit trail jadi jelas.
Shared accounts, kalau belum bisa dihapus, ubah cara kontrolnya
Idealnya, shared account dihapus. Namun realita enterprise kadang beda. Beberapa perangkat, konsol, atau workflow warisan memang belum mendukung model identitas personal sepenuhnya.
Kalau kamu belum bisa menghapus shared accounts, jangan fokus ke nama akunnya dulu. Fokus ke lapisan di depannya.
- Wajibkan login awal dengan identitas personal plus passkey.
- Beri akses ke shared resource lewat broker, bastion, PAM, atau session gateway.
- Catat siapa yang membuka sesi, kapan, dari mana, dan untuk tiket apa.
- Gunakan check-out time limit, sehingga akses tidak menggantung.
- Rotasi secret backend otomatis walau user depan login dengan passkey.
Ini ide yang sering terasa aneh buat tim lama. Kamu tidak selalu harus menghapus akun bersama lebih dulu. Kamu bisa menghapus sifat “bersamanya” dari sisi audit. Itu langkah transisi yang jauh lebih realistis.
Break-glass access yang sehat itu sulit dipakai sembarangan
Banyak organisasi bikin break-glass account, lalu menyimpannya seperti payung cadangan. Masalahnya, payung itu akhirnya dipakai tiap hujan kecil. Lama-lama status darurat jadi rutinitas.
Desain yang lebih matang biasanya punya ciri ini.
- Terisolasi, tidak dipakai untuk admin harian.
- Dipantau khusus, semua penggunaan memicu alert real-time.
- Terikat alasan, harus terkait incident ID atau change ID.
- Dibatasi waktu, akses kedaluwarsa otomatis.
- Direview pasca-pakai, wajib ada post-incident review.
Untuk panduan teknis WebAuthn dan passkey enterprise, cek dokumentasi resmi W3C WebAuthn dan ringkasan deployment dari FIDO Alliance. Keduanya kuat untuk referensi desain kontrol.
Service desk reset, titik terlemah yang sering dilupakan
Di atas kertas, passkey mengurangi reset password. Namun service desk tetap sibuk karena masalah baru, ganti device, device hilang, sinkronisasi gagal, user belum enroll device kedua, atau kebijakan attestation berubah.
Kalau alur reset-mu masih bertumpu pada data statis, misalnya tanggal lahir, nomor pegawai, atau jawaban yang bisa ditebak, seluruh sistem passkey-mu bocor lewat pintu samping.
Desain reset yang lebih kuat
- Gunakan step-up verification, bukan satu faktor lemah.
- Wajibkan bukti konteks, misalnya manager approval, device posture, atau verified callback.
- Pisahkan antara recover access dan register new authenticator.
- Tambahkan cooling period untuk role sensitif.
- Log semua override untuk kebutuhan audit dan forensik.
Kalau butuh konteks tambahan, baca juga artikel terkait di sini, Passkey Hilang, Password Jangan Balik Lagi dan Passkeys Enterprise Gagal Bukan karena User, Tapi karena Device Trust. Dua topik itu nyambung langsung dengan recovery dan trust model.
Checklist cepat untuk tim compliance
Compliance team biasanya tidak butuh jargon passkey yang panjang. Mereka butuh bukti kontrol. Jadi, cek lima hal ini.
- Apakah akses darurat punya owner, scope, dan masa berlaku yang jelas.
- Apakah akun fungsional punya kompensating control yang terdokumentasi.
- Apakah semua reset akses menghasilkan audit trail yang utuh.
- Apakah ada review berkala untuk penggunaan break-glass.
- Apakah service desk tidak menjadi jalur bypass permanen.
Yang perlu kamu ubah minggu ini
Kalau rollout passkey di tempatmu sudah jalan, jangan langsung puas karena login phishing-resistant sudah aktif. Cek edge case yang paling berbahaya, siapa yang masih pakai akun bersama, siapa yang bisa override enrollment, dan kapan break-glass terakhir dipakai.
Biasanya masalah terbesar bukan di cryptography. Masalahnya ada di workflow manusia. Saat itulah security matang terlihat, bukan saat demo login mulus, tetapi saat keadaan darurat datang dan kontrol tetap rapi.
FAQ
Apakah shared accounts harus dihapus total di era passkey?
Kalau bisa, ya. Namun bila sistem warisan belum memungkinkan, bungkus aksesnya dengan identitas personal, broker session, logging kuat, dan pembatasan scope. Target akhirnya tetap penghapusan bertahap.
Apakah break-glass access berarti password fallback?
Tidak harus. Break-glass bisa berupa jalur autentikasi darurat terpisah, approval khusus, vault-protected credential, atau emergency admin path yang sangat dibatasi. Yang penting, jalur ini tidak menjadi fallback harian.
Bagaimana helpdesk reset tetap cepat tanpa melemahkan auth?
Gunakan verifikasi berlapis, approval berbasis konteks, dan pemisahan antara pemulihan akun dengan pendaftaran authenticator baru. Cepat itu penting, tetapi cepat tanpa kontrol akan membuka serangan social engineering.
