Passkeys di Lingkungan Teregulasi, Aman Saja Nggak Cukup

Banyak tim security sudah paham satu hal, password makin susah dipertahankan. Masalahnya, di lingkungan teregulasi, aman saja belum cukup. Tim compliance butuh jejak audit, tim procurement butuh bukti kontrol, dan CISO butuh jawaban yang rapi saat auditor bertanya, “siapa login, pakai faktor apa, diverifikasi di mana, dan evidence-nya apa?”

Di sinilah passkeys for regulated environments jadi menarik. Passkey bukan cuma alat login anti-phishing. Kalau dirancang benar, passkey bisa jadi fondasi kontrol akses yang lebih mudah diaudit, lebih kuat untuk user verification, dan lebih enak dipetakan ke evidence compliance.

Jawaban Singkat

Passkey bisa menutup gap governance yang sering muncul di MFA tradisional. Kuncinya bukan cuma adopsi WebAuthn, tetapi pemetaan event autentikasi ke audit log, kebijakan user verification, serta artefak bukti yang siap dipakai untuk audit dan vendor review.

• Passkey mengurangi risiko phishing dan credential theft.
• Auditability naik kalau event login, registration, recovery, dan device binding dicatat dengan struktur yang benar.
• Compliance evidence jadi lebih kuat kalau kontrol teknis, kebijakan, dan log saling nyambung.

Kenapa Passkey Sering Terlihat Bagus di Demo, Tapi Kurang Meyakinkan Saat Audit

Banyak demo passkey fokus ke UX. Login lebih cepat. Friksi turun. Phishing resistance naik. Semua itu benar, tetapi auditor biasanya bertanya hal lain.

• Apakah user verification diwajibkan atau opsional?
• Bagaimana organisasi membedakan perangkat pribadi dan perangkat yang dikelola?
• Apa bukti bahwa hanya pengguna sah yang bisa mengakses data sensitif?
• Bagaimana proses recovery dicatat dan disetujui?

Kalau jawabanmu masih berupa diagram arsitektur umum, gap governance belum tertutup. Regulated access control butuh lebih dari sekadar login modern.

Tiga Lapisan yang Harus Ada Agar Passkey Layak untuk Lingkungan Teregulasi

1. Lapisan autentikasi, bukti bahwa login memang tahan phishing

Passkey berbasis WebAuthn dan ekosistem FIDO memberi fondasi autentikasi berbasis kriptografi kunci publik. Artinya, secret tidak dikirim seperti password biasa, sehingga serangan phishing klasik jauh lebih susah berhasil.

2. Lapisan verifikasi pengguna, bukti bahwa yang pegang device memang orang yang benar

Ini bagian yang sering diremehkan. Banyak tim merasa passkey otomatis cukup. Padahal, untuk compliance, user presence dan user verification bukan hal yang sama. Menyentuh device belum tentu sama dengan verifikasi biometrik atau PIN lokal.

Karena itu, kebijakanmu harus eksplisit. Untuk akses sensitif, set requirement ke user verification required. Jadi, yang dibuktikan bukan cuma device hadir, tetapi pengguna benar-benar lolos verifikasi lokal.

3. Lapisan evidence, bukti yang bisa dibaca auditor dan pembeli enterprise

Di sinilah banyak proyek gagal. Tim teknis punya event. Tim compliance punya spreadsheet. Tim buyer punya kuesioner vendor. Namun, ketiganya nggak terhubung.

Solusinya, bangun model evidence yang konsisten. Setiap event passkey harus bisa ditarik ke kontrol, kebijakan, dan artefak review.

Framework Praktis, 4E untuk Passkey Governance

Kalau kamu ingin passkey mudah dijelaskan ke auditor, pakai kerangka sederhana ini, Enroll, Enforce, Evidence, Exception.

Enroll

• Catat kapan passkey dibuat.
• Catat akun, device class, platform, dan metode verifikasi awal.
• Bedakan enrollment mandiri, enrollment hasil invite admin, dan rebind setelah recovery.

Enforce

• Tentukan aplikasi mana yang wajib passkey.
• Tentukan kapan user verification wajib.
• Terapkan kebijakan berbeda untuk admin, finance, developer production, dan user biasa.

Evidence

• Simpan log autentikasi yang bisa ditautkan ke user, app, waktu, hasil, dan level assurance.
• Hubungkan log ke kebijakan akses dan kontrol internal.
• Siapkan ekspor untuk audit periodik dan due diligence pembeli enterprise.

Exception

• Recovery flow harus lebih ketat daripada login normal.
• Setiap bypass, fallback, atau temporary access harus punya approval dan expiry.
• Dokumentasikan kompensating control bila passkey belum bisa diwajibkan di semua skenario.

Bagian paling penting justru Exception. Ini agak berlawanan dengan intuisi umum. Banyak tim fokus memperkuat login utama, padahal auditor sering menemukan kelemahan terbesar di recovery, helpdesk override, atau device replacement. Jalur belakang yang lemah akan merusak jalur depan yang kuat.

Event Audit yang Wajib Masuk Log

Kalau kamu ingin auditability kuat, minimal catat event berikut.

• Passkey registration created, siapa, kapan, untuk aplikasi apa.
• Authentication success or failure, lengkap dengan alasan gagal.
• User verification state, required, performed, atau bypassed.
• Device or authenticator binding change, termasuk rotasi device.
• Recovery initiated and completed, siapa approve, SLA, dan jalur verifikasi.
• Policy change, misalnya perubahan dari optional ke required.
• Admin override, emergency access, atau fallback OTP sementara.

Idealnya, setiap log punya field yang konsisten, seperti user ID, app ID, risk level, policy ID, session ID, result, timestamp UTC, serta actor type. Struktur begini jauh lebih berguna daripada log naratif yang susah di-query.

Mapping Passkey ke Kebutuhan Compliance

Bahasa compliance dan bahasa engineering sering beda. Jadi, kamu perlu jembatan yang jelas.

• Kontrol akses → passkey + user verification required untuk resource sensitif.
• Audit trail → event autentikasi, enrollment, recovery, dan override tersimpan rapi.
• Segregation of duties → approval recovery tidak boleh dilakukan aktor yang sama.
• Periodic review → daftar passkey aktif, device terkait, dan exception yang belum ditutup.
• Incident response → revocation, rebind, dan forced re-auth punya prosedur terdokumentasi.

Kalau organisasimu sedang menilai strategi MFA, baca juga cara mendesain MFA yang tahan phishing. Kalau isu utamanya device posture, lanjutkan ke pembahasan device trust di passkeys enterprise.

Apa yang Harus Ditanyakan Enterprise Buyer Sebelum Membeli Solusi Passkey

• Apakah platform mendukung policy-based user verification per aplikasi atau per peran?
• Apakah audit log bisa diekspor ke SIEM atau data lake?
• Apakah recovery flow punya approval, evidence, dan expiry?
• Apakah admin bisa melihat state enrollment dan exception secara terpusat?
• Apakah vendor menyediakan dokumentasi kontrol untuk review keamanan dan compliance?

Kalau jawaban vendor hanya bicara UX dan adoption, hati-hati. Untuk regulated environment, buyer butuh bukti operasional, bukan sekadar klaim keamanan.

FAQ

Apakah passkey otomatis memenuhi kebutuhan compliance?

Belum tentu. Passkey memperkuat autentikasi, tetapi compliance membutuhkan kebijakan, audit log, recovery control, dan bukti review berkala.

Bedanya user presence dan user verification apa?

User presence hanya menunjukkan ada interaksi dengan authenticator. User verification menunjukkan pengguna lolos verifikasi lokal, misalnya biometrik atau PIN perangkat.

Kenapa recovery flow sangat penting di lingkungan teregulasi?

Karena jalur recovery sering jadi titik bypass. Jika prosesnya longgar, kontrol passkey yang kuat di login utama bisa runtuh.

Penutup

Passkey memang bisa membuat login lebih aman dan lebih nyaman. Namun, di sektor yang diatur ketat, nilai terbesarnya muncul saat passkey diubah menjadi sistem kontrol yang bisa diaudit. Jadi, fokusnya bukan hanya implementasi WebAuthn, tetapi juga bagaimana event, kebijakan, dan evidence dirangkai menjadi satu cerita yang utuh.

Kalau kamu sedang menyusun roadmap autentikasi untuk tim compliance, CISO, atau pembeli enterprise, mulai dari satu pertanyaan ini, bukti apa yang ingin auditor lihat enam bulan dari sekarang? Dari situ, desain passkey-mu akan jauh lebih matang.