---
url: 'https://www.corbado.com/id/blog/passkey-day-2-problems'
title: 'Masalah Hari Ke-2 Kunci Sandi: 5 Risiko setelah Peluncuran'
description: 'Kunci sandi sangat bagus jika diterapkan dengan benar. Pelajari 5 masalah hari ke-2 seputar pemulihan, UX lintas perangkat, aplikasi native, adopsi, dan perubahan platform.'
lang: 'id'
author: 'Vincent Delitz'
date: '2026-05-27T11:05:36.623Z'
lastModified: '2026-06-16T06:06:43.792Z'
keywords: 'masalah hari ke-2 kunci sandi, tantangan operasional kunci sandi, risiko kunci sandi setelah peluncuran, masalah produksi kunci sandi, implementasi kunci sandi'
category: 'Passkeys Strategy'
---

# Masalah Hari Ke-2 Kunci Sandi: 5 Risiko setelah Peluncuran

## Key Facts

- **Adopsi rendah** adalah kegagalan yang paling umum: enterprise yang melewatkan strategi
  peluncuran melihat penggunaan kunci sandi di bawah 5% meskipun implementasi teknisnya
  kuat, meniadakan seluruh investasi rekayasa.
- **Desain fallback pemulihan** menentukan apakah Anda memperkenalkan kembali risiko
  phising atau mengunci pengguna dalam skala besar. Reset berbasis email mem-bypass kunci
  sandi yang tahan phising sepenuhnya jika penyerang mengontrol kotak masuk.
- **Perubahan platform** merusak kunci sandi secara diam-diam, seperti yang ditunjukkan
  oleh bug iOS 26.2 di mana `isUserVerifyingPlatformAuthenticatorAvailable()`
  mengembalikan false di semua browser non-Safari, sehingga memerlukan pembaruan logika
  deteksi.
- **Kompleksitas aplikasi native** melipatgandakan cakupan QA di web, iOS, dan Android,
  dengan kode kesalahan spesifik platform dan siklus peninjauan app store yang menghalangi
  perbaikan regresi kunci sandi yang mendesak.

## 1. Pendahuluan: Risiko Kunci Sandi setelah Peluncuran

**Jangan implementasikan kunci sandi.**

Setidaknya tidak dengan cara apa pun dan tidak jika Anda tidak memiliki sumber daya untuk
melakukannya dengan benar.

Ya, [kunci sandi](https://www.corbado.com/id/glossary/cda) (passkeys) adalah hal terbaik yang terjadi pada
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) konsumen dalam satu dekade
terakhir. Ya, mereka membunuh phising. Ya, mereka dapat meningkatkan UX secara
besar-besaran. Namun, [kunci sandi](https://www.corbado.com/id/glossary/cda) yang diterapkan dengan salah juga
dapat menyebabkan banyak kerugian.

Mengimplementasikan server WebAuthn tidak terlalu rumit. Tantangan sebenarnya adalah
segala sesuatu di sekitarnya. Mengoperasikan [kunci sandi](https://www.corbado.com/id/glossary/cda) secara
efisien dalam skala besar memerlukan perencanaan ke depan. Anda perlu memikirkan semua
masalah "Hari ke-2" - realitas operasional yang baru muncul setelah Anda memulai
peluncuran kunci sandi.

Artikel ini membahas lima masalah Hari ke-2 yang secara konsisten membunuh proyek kunci
sandi. Jika Anda tidak dapat menyelesaikan semuanya, Anda belum siap untuk meluncurkan
kunci sandi. Jika Anda bisa, Anda akan membangun
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang lebih aman dan lebih
mudah digunakan daripada yang bisa ditawarkan oleh
[kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android).

## 2. Apa itu Masalah Hari Ke-2 Kunci Sandi?

Dalam rekayasa perangkat lunak, "Hari ke-1" adalah saat Anda membangun dan meluncurkannya.
"Hari ke-2" adalah saat Anda mengoperasikan, memelihara, dan menskalakan apa yang telah
Anda luncurkan. Untuk kunci sandi, Hari ke-1 bisa sangat mudah:

- integrasikan server WebAuthn ke dalam stack enterprise Anda
- tambahkan alur frontend dan luncurkan.

Sebagian besar tim bisa mendapatkan implementasi kunci sandi dasar berjalan dalam beberapa
hari atau minggu.

Hari ke-2 adalah saat proyek gagal. Ini adalah momen pengguna nyata pada perangkat nyata
dengan edge case nyata berinteraksi dengan sistem kunci sandi Anda. Ini adalah saat Anda
menyadari bahwa demo mengkilap yang berfungsi sempurna di MacBook Anda, rusak di laptop
Windows yang menjalankan Chrome di balik proxy perusahaan. Ini adalah saat tim dukungan
Anda dibanjiri tiket "Saya tidak bisa masuk lagi".

Kesenjangan antara demo kunci sandi yang berfungsi dan penerapan kunci sandi tingkat
produksi sangatlah besar. Kami telah membahas jebakan implementasi teknis dan alasan
strategis mengapa proyek
[kunci sandi gagal](https://www.corbado.com/id/blog/mengapa-implementasi-kunci-sandi-gagal) sebelumnya. Artikel
ini berfokus secara khusus pada apa yang terjadi setelah Anda _go live_ dari perspektif
operasional.

Berikut adalah lima masalah Hari ke-2 yang akan kami bahas:

- [Masalah 1: Pemulihan dan Fallback sulit diamankan](#3-issue-1-recovery-and-fallback-are-hard-to-secure)
- [Masalah 2: Edge Case Lintas Perangkat dan Lintas Ekosistem merusak Alur Kunci Sandi](#4-issue-2-cross-device-and-cross-ecosystem-edge-cases-break-passkey-flows)
- [Masalah 3: Aplikasi Native melipatgandakan Kompleksitas Kunci Sandi](#5-issue-3-native-apps-multiply-passkey-complexity)
- [Masalah 4: Adopsi adalah Masalah Produk, bukan Masalah Teknologi](#6-issue-4-adoption-is-a-product-problem-not-a-tech-problem)
- [Masalah 5: Perubahan Platform merusak Kunci Sandi secara diam-diam](#7-issue-5-platform-changes-break-passkeys-silently)

## 3. Masalah 1: Pemulihan dan Fallback sulit diamankan

Jika Anda tidak merancang pemulihan dan fallback dengan benar, Anda akan mengunci pengguna
dalam skala besar atau Anda diam-diam memperkenalkan kembali alur rentan phising yang sama
dengan yang ingin Anda hilangkan.

### 3.1 Risiko Penguncian Akun dalam Skala Besar

Pertimbangkan pengguna yang mendaftar kunci sandi di iPhone mereka, lalu kehilangan iPhone
tersebut. Biasanya, sebagian besar kasus pemulihan ini sekarang ditangani oleh manajer
kredensial (kemungkinan besar [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) di iPhone).
Selama pengguna memiliki akses ke akun Apple mereka, mereka memiliki kunci sandi yang
disinkronkan untuk masuk (log in) di perangkat baru. Tetapi bagaimana jika mereka tidak
lagi memiliki akses ke akun cloud tersebut? Inilah saat jalur pemulihan rutin Anda
berperan.

Katakanlah Anda mengasumsikan bahwa private key (kunci privat) masih tersedia di perangkat
yang dicoba pengguna untuk masuk, sehingga Anda memulai seremonial login WebAuthn. Ini
akan menghasilkan modal OS / browser yang meminta pengguna untuk "masuk dengan kunci sandi
Anda di perangkat lain". Pada dasarnya, pengguna sekarang terkunci dari akun mereka. Tidak
ada perangkat lain tempat kunci sandi disimpan. Pengguna menjadi sangat bingung. Kalikan
ini dengan ribuan pengguna dan Anda akan menghadapi krisis dukungan.

Reaksi umumnya adalah menambahkan reset akun berbasis email sebagai fallback. Tetapi ini
menggagalkan tujuan dari kunci sandi: Anda baru saja memperkenalkan kembali saluran
pemulihan yang rentan phising. Penyerang yang dapat membahayakan email pengguna kini dapat
mem-bypass implementasi kunci sandi tahan phising Anda sepenuhnya.

### 3.2 Merancang Fallback tanpa memperkenalkan kembali Phising

Menurut pendapat kami, pendekatan yang tepat adalah pemulihan berlapis:

1. **Kunci sandi yang disinkronkan** sebagai strategi utama: pastikan pengguna membuat
   kunci sandi yang disinkronkan (melalui [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
   Google [Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) atau penyedia
   [kunci sandi pihak ketiga](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi)) sehingga
   kehilangan perangkat tidak berarti kehilangan kredensial
2. **Autentikasi lintas perangkat** sebagai lapisan kedua: izinkan pengguna untuk
   mengautentikasi dari perangkat lain di mana kunci sandi lain tersedia dengan memindai
   [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi)
3. **Verifikasi identitas (IDV)** sebagai lapisan ketiga: tawarkan IDV otomatis dengan
   pemeriksaan keaktifan (liveness checks) alih-alih fallback ke
   [kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android)/OTP.
4. **Kredensial yang dapat diverifikasi secara digital** sebagai lapisan keempat: ini
   adalah versi [pemulihan akun](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) yang
   paling aman, menjaga privasi, dan ramah pengguna. Ini memungkinkan pengguna untuk
   menggunakan kredensial yang dapat diverifikasi secara digital (mis. ID nasional digital
   atau [mDL](https://www.corbado.com/blog/mobile-drivers-license)) untuk memverifikasi identitas mereka dengan
   menggunakan API standar (mis.
   [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api)). Teknologi ini masih cukup
   baru dan tingkat adopsinya tidak tinggi tetapi akan memainkan peran utama dalam
   beberapa bulan dan tahun mendatang.

Secara umum, Anda perlu memutuskan lapisan
[pemulihan akun](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) mana yang dapat
dijustifikasi dari perspektif biaya / gesekan. Misalnya, di
[ritel](https://www.corbado.com/passkeys-for-e-commerce) / [e-commerce](https://www.corbado.com/passkeys-for-e-commerce), Anda mungkin
hanya menawarkan dua lapisan pertama dan menerima risiko phising karena alasan keuangan.
Di industri lain, di mana keamanan lebih penting, Anda lanjut ke lapisan 3 dan 4.

Setiap lapisan menambah kompleksitas. Anda perlu memutuskan lapisan mana yang dibutuhkan
use case Anda, membangunnya, mengujinya di semua kombinasi perangkat, dan memantau
penggunaannya. Ini jauh lebih banyak pekerjaan daripada integrasi WebAuthn awal.

### 3.3 Apa yang salah dilakukan oleh sebagian besar Tim

Sebagian besar tim terlalu menyederhanakan pemulihan (fallback ke
[kata sandi](https://www.corbado.com/id/blog/cara-mengaktifkan-passkey-android) atau SMS OTP) atau terlalu
mempersulitnya (mis. mewajibkan
[kunci keamanan perangkat keras](https://www.corbado.com/id/blog/kunci-keamanan-perangkat-keras-fido2-terbaik)
untuk setiap pemulihan). Keseimbangan yang tepat tergantung pada model ancaman Anda, basis
pengguna, dan persyaratan peraturan. Melakukan kesalahan berarti melemahkan postur
keamanan Anda atau menciptakan begitu banyak gesekan sehingga pengguna meninggalkan alur
tersebut.

## 4. Masalah 2: Edge Case Lintas Perangkat dan Lintas Ekosistem merusak Alur Kunci Sandi

Pengguna Anda tidak hidup di dunia Apple-only yang bersih. Mereka berganti perangkat,
mencampur Windows dengan [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios), menggunakan browser yang
berbeda, dan bekerja pada pengaturan yang dikelola perusahaan. Di situlah alur kunci sandi
rusak jika Anda belum merencanakannya.

### 4.1 Fragmentasi Ekosistem itu nyata

Ekosistem kunci sandi mencakup tiga platform utama (Apple, Google, dan Microsoft),
beberapa browser (Chrome, Safari, Firefox, dan Edge), puluhan
[penyedia kunci sandi](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) / manajer kredensial (mis.
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis),
[Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024),
[Dashlane](https://www.corbado.com/blog/dashlane-passkeys) dan lainnya) dan banyak kombinasi
OS/browser/perangkat. Setiap kombinasi dapat berperilaku sedikit berbeda, mis.:

- **Apple** menyinkronkan kunci sandi secara default melalui
  [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) di seluruh
  [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios), iPadOS, dan macOS tetapi tidak ke Windows atau
  [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)
- **Google** menyinkronkan melalui
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) di seluruh
  [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) dan Chrome tetapi pengalamannya di
  [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) berbeda (Anda perlu mengaturnya secara manual)
- **Windows** memiliki perilaku kunci sandi sendiri yang berbeda secara signifikan dari
  platform lain
- **Manajer kata sandi** masing-masing menangani pembuatan dan pemilihan kunci sandi
  secara berbeda, terkadang bertentangan dengan prompt asli platform

### 4.2 Alur Autentikasi Lintas Perangkat

Ketika pengguna membuat kunci sandi di iPhone mereka tetapi ingin masuk di laptop Windows,
mereka dapat menggunakan [autentikasi lintas perangkat](https://www.corbado.com/id/glossary/cda) (biasanya
melalui [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi) dan Bluetooth). Alur ini berfungsi
tetapi rapuh:

- Ini memerlukan Bluetooth untuk diaktifkan di kedua perangkat
- Firewall perusahaan dan kebijakan MDM dapat mengganggu karena ada tunnel yang disiapkan
  di latar belakang
- UX sangat bervariasi antar browser
- Pengguna sering tidak mengerti apa yang sedang terjadi atau mengapa mereka memindai
  [kode QR](https://www.corbado.com/id/blog/kode-qr-login-autentikasi)

Kami telah melihat sendiri edge case ini di ribuan kombinasi perangkat. Jika Anda
membangun kunci sandi secara in-house, Anda perlu menguji dan menangani setiap edge case
tersebut. Jika tidak bisa, pengguna Anda akan mengalami kesalahan yang tidak dapat
dijelaskan oleh tim dukungan Anda.

### 4.3 Ketidakkonsistenan Browser dan OS

Bahkan pada perangkat yang sama, browser yang berbeda berperilaku berbeda. Chrome di macOS
menampilkan modal kunci sandi yang berbeda dari Safari di macOS. Firefox memiliki
perilakunya sendiri. [Client hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
dan deteksi agen pengguna menjadi sangat penting untuk memberikan alur yang tepat kepada
pengguna yang tepat, tetapi menguraikannya dengan benar di semua kombinasi adalah beban
pemeliharaan yang tidak pernah berakhir.

## 5. Masalah 3: Aplikasi Native melipatgandakan Kompleksitas Kunci Sandi

[Pengujian kunci sandi](https://www.corbado.com/id/blog/pengujian-kunci-sandi) dan QA sudah menjadi tantangan
untuk [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) (kami membahasnya secara
rinci di
[Masalah 5: Perubahan Platform](#7-issue-5-platform-changes-break-passkeys-silently)).
Tetapi jika produk Anda juga memiliki aplikasi iOS dan
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) native, kompleksitasnya berlipat ganda
karena keputusan arsitektur dan perilaku spesifik platform yang tidak pernah dihadapi oleh
tim web-only.

### 5.1 Keputusan Native vs. WebView

Keputusan pertama adalah apakah akan mengimplementasikan kunci sandi secara native atau
melalui [WebView](https://www.corbado.com/blog/native-app-passkeys). Setiap pendekatan memiliki trade-off:

| Aspek                    | Implementasi Native                        | Implementasi WebView                                 |
| ------------------------ | ------------------------------------------ | ---------------------------------------------------- |
| **Kualitas UX**          | Terbaik di kelasnya, nuansa platform asli  | Tergantung pada jenis WebView                        |
| **Pemeliharaan**         | Basis kode terpisah untuk iOS dan Android  | Logika web bersama                                   |
| **Persyaratan platform** | Harus mengikuti perubahan SDK Apple/Google | Harus menangani masalah dukungan kunci sandi WebView |
| **Kompleksitas**         | Tinggi (API spesifik platform)             | Menengah (tetapi jenis WebView penting)              |

Di iOS saja, Anda dapat memilih antara [WKWebView](https://www.corbado.com/blog/native-app-passkeys),
[SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys),
[SFAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) dan
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) - masing-masing dengan
karakteristik dukungan kunci sandi yang berbeda. Di Android, Chrome Custom Tabs
berperilaku berbeda dari [WebView](https://www.corbado.com/blog/native-app-passkeys) standar. Ini adalah
keputusan yang tidak pernah harus dibuat oleh tim web-only, dan setiap pilihan menciptakan
permukaan pemeliharaannya sendiri.

### 5.2 Perilaku Spesifik Platform di Aplikasi Native

Di luar keputusan arsitektur, iOS dan Android menangani kunci sandi secara berbeda di
tingkat OS:

- **iOS** mengintegrasikan kunci sandi dalam-dalam ke dalam manajer kredensial sistem,
  dengan perilaku autofill khusus yang dapat berubah di setiap versi iOS
- **Android** merutekan permintaan kunci sandi melalui Credential Manager API, yang
  berinteraksi dengan beberapa
  [penyedia kunci sandi](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi) secara bersamaan
- Kondisi kesalahan (error states), perilaku timeout, dan prompt pengguna berbeda antar
  platform. Pengguna yang sama yang membatalkan (cancel) akan memunculkan
  `NotAllowedError` di web tetapi sebagai
  `SimpleAuthenticationServices.AuthorizationError` di iOS dan
  `User cancelled the operation` di Android's Credential Manager - lihat
  [webAuthn errors](https://www.corbado.com/blog/webauthn-errors) in production untuk pemetaan kesalahan lintas
  platform secara lengkap
- Siklus peninjauan app store menambah penundaan ketika Anda perlu merilis perbaikan
  mendesak untuk regresi kunci sandi

### 5.3 Cakupan QA yang Dilipatgandakan

Jika Anda mengoperasikan [aplikasi web](https://www.corbado.com/id/blog/aplikasi-crud-react-express-mysql) dan
[aplikasi native](https://www.corbado.com/id/blog/webauthn-relying-party-id-rpid-kunci-sandi), Anda bukan hanya
menggandakan upaya QA tetapi Anda melipatgandakannya. Web, iOS, dan Android masing-masing
berperilaku sebagai lingkungan kunci sandi terpisah yang memerlukan pengujian end-to-end
independen dan pemantauan. Dan tidak seperti web, di mana Anda dapat menerapkan perbaikan
secara instan, perbaikan
[aplikasi native](https://www.corbado.com/id/blog/webauthn-relying-party-id-rpid-kunci-sandi) dibatasi oleh
siklus peninjauan app store.

## 6. Masalah 4: Adopsi adalah Masalah Produk, bukan Masalah Teknologi

"Kunci sandi didukung" bukan berarti "kunci sandi digunakan." Jika Anda tidak memiliki
strategi peluncuran dan pengukuran, adopsi Anda akan mengecewakan dan proyek tersebut akan
dicap gagal secara internal.

### 6.1 Mengapa Adopsi yang Rendah Membunuh Proyek Anda

Kami telah membahas hal ini secara ekstensif dalam artikel kami tentang mengapa
implementasi [kunci sandi gagal](https://www.corbado.com/id/blog/mengapa-implementasi-kunci-sandi-gagal): jika
pengguna tidak beralih ke kunci sandi, proyek tersebut sudah gagal. Kata sandi tetap
dominan, [biaya SMS OTP](https://www.corbado.com/id/blog/mengurangi-biaya-sms-dengan-passkeys) tetap tinggi,
risiko phising bertahan, dan organisasi Anda tidak melihat hasil atas investasi rekayasa
yang signifikan.

[Kasus bisnis](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey) untuk
[adopsi kunci sandi](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey) sangat kuat tetapi hanya jika
adopsi benar-benar terjadi. Kami telah melihat enterprise meluncurkan kunci sandi dengan
implementasi teknis hebat yang mencapai adopsi kurang dari 5% karena tidak ada yang
memikirkan peluncuran dan strategi adopsi.

### 6.2 Adopsi Membutuhkan Pekerjaan Produk yang Disengaja

Mendorong [adopsi kunci sandi](https://www.corbado.com/id/blog/kasus-bisnis-adopsi-passkey) adalah tantangan
produk yang membutuhkan:

- **Progressive enrollment**: mendorong pengguna untuk membuat kunci sandi pada momen yang
  tepat (mis. setelah berhasil masuk, selama peninjauan
  [keamanan akun](https://www.corbado.com/id/blog/kata-sandi-rumit-akan-terpecahkan))
- **Komunikasi pengguna yang jelas**: menjelaskan apa itu kunci sandi dan mengapa kunci
  sandi lebih baik, dalam bahasa yang dipahami pengguna non-teknis
- **Prompt yang sadar perangkat**: hanya menawarkan
  [pembuatan kunci sandi](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) ketika perangkat
  pengguna benar-benar mendukungnya dengan baik, menghindari pengalaman yang membuat
  frustrasi pada konfigurasi yang tidak didukung
- **Infrastruktur pengukuran**: melacak tingkat
  [pembuatan kunci sandi](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey), tingkat
  keberhasilan login, tingkat fallback, dan tingkat pengabaian untuk mengidentifikasi dan
  memperbaiki hambatan

### 6.3 Seperti apa Adopsi yang "Bagus"

Berdasarkan pengalaman kami dengan penerapan kunci sandi berskala besar, berikut yang
harus ditargetkan enterprise:

| Metrik                                                                 | Lemah   | Cukup  | Kuat    |
| ---------------------------------------------------------------------- | ------- | ------ | ------- |
| **Tingkat Pembuatan Kunci Sandi** (dari pengguna yang memenuhi syarat) | <10% | 10-60% | >60% |
| **Tingkat Login Kunci Sandi** (dari semua login)                       | <5%  | 5-40%  | >40% |

Jika angka adopsi Anda terlihat seperti kolom "lemah" setelah tiga bulan, proyek tersebut
sedang dalam masalah. Tanpa analitik untuk mengukur ini, Anda bahkan tidak akan tahu.

## 7. Masalah 5: Perubahan Platform merusak Kunci Sandi secara diam-diam

Pembaruan OS dan browser mengubah prompt, perilaku autofill, dan alur fallback. Jika Anda
tidak memiliki pemantauan berkelanjutan, Anda akan mendapatkan regresi dan tiket dukungan
tanpa peringatan.

Kami baru saja menerbitkan ikhtisar komprehensif tentang
[kesalahan WebAuthn](https://www.corbado.com/id/blog/pemecahan-masalah-passkey-solusi) yang terjadi dalam
produksi.

### 7.1 Mengapa Kunci Sandi sangat terpengaruh oleh Perubahan Platform

Tidak seperti kata sandi (yang hanya berupa string yang divalidasi server Anda), kunci
sandi bergantung pada integrasi yang mendalam dengan sistem operasi, browser, dan manajer
kredensial. Saat Apple merilis versi iOS baru, prompt
[pembuatan kunci sandi](https://www.corbado.com/id/blog/praktik-terbaik-pembuatan-passkey) mungkin terlihat
berbeda. Saat Chrome memperbarui logika autofill-nya, alur login Anda mungkin rusak. Saat
manajer kata sandi merilis versi baru, ia mungkin mulai mencegat permintaan kunci sandi
dengan cara yang tidak Anda antisipasi.

Satu contoh baru-baru ini adalah bug [iOS 26](https://www.corbado.com/blog/ios-26-passkeys).2 di mana
`isUserVerifyingPlatformAuthenticatorAvailable()` mengembalikan `false` di semua browser
non-Safari (Chrome, Edge, Firefox), membutuhkan logika deteksi sadar platform menggunakan
`getClientCapabilities()` sebagai perbaikan (workaround).

### 7.2 Pemantauan bukan opsional

Untuk memastikan Anda mengetahui semua potensi bug dan melacak adopsinya, Anda perlu
mengatur stack observabilitas
[autentikasi](https://www.corbado.com/id/blog/cara-menjadi-sepenuhnya-tanpa-password) Anda. Kami merekomendasikan
setidaknya hal berikut:

- **Analitik autentikasi real-time**: melacak tingkat keberhasilan dan kegagalan
  berdasarkan kombinasi OS, browser, dan
  [penyedia kunci sandi](https://www.corbado.com/id/blog/penyedia-passkey-aaguid-adopsi)
- **Pemantauan sadar versi**: deteksi saat versi OS atau browser baru menyebabkan lonjakan
  kesalahan atau fallback. Bedakan antara kesalahan yang diharapkan (pembatalan pengguna
  yang muncul sebagai `NotAllowedError`) dan kesalahan tak terduga (lonjakan `AbortError`
  karena bug konkurensi atau
  [kesalahan kunci sandi](https://www.corbado.com/id/blog/pemecahan-masalah-passkey-solusi) Credential Manager
  baru setelah pembaruan Android)
- **Peringatan (Alerting)**: dapatkan notifikasi sebelum pengguna Anda mulai mengajukan
  tiket dukungan
- **Kemampuan respons cepat**: kemampuan untuk mendorong perbaikan atau menonaktifkan
  kunci sandi untuk kombinasi perangkat yang terpengaruh dengan cepat

Ini adalah jenis infrastruktur analitik autentikasi yang sebagian besar tim tidak bangun
sampai mereka mengalami insiden. Pada saat itu, kerusakan pada kepercayaan pengguna dan
kredibilitas proyek internal telah terjadi.

### 7.3 Biaya Pemeliharaan Berkelanjutan

Biaya sebenarnya dari penerapan kunci sandi bukan pada pembuatan awalnya. Melainkan pada
pemeliharaan berkelanjutan:

- Memantau perubahan platform di iOS, Android, Windows, macOS, dan semua browser utama
- Menguji setiap pembaruan untuk regresi
- Memperbarui SDK frontend Anda saat API browser berubah
- Menjaga kompatibilitas dengan ekosistem penyedia kunci sandi yang terus berkembang
- Mendokumentasikan dan mengomunikasikan perubahan ke tim dukungan Anda

## 8. Kapan Anda (tidak) Harus Meluncurkan Kunci Sandi

Mengingat masalah Hari ke-2 ini, berikut adalah penilaian jujur tentang kapan Anda harus
dan tidak boleh meluncurkan kunci sandi.

### 8.1 Jangan luncurkan Kunci Sandi jika

- Anda tidak memiliki strategi fallback dan pemulihan yang jelas
- Anda belum menguji di berbagai kombinasi perangkat yang benar-benar digunakan pengguna
  Anda
- Anda memiliki [aplikasi native](https://www.corbado.com/id/blog/webauthn-relying-party-id-rpid-kunci-sandi)
  tetapi tidak ada rencana untuk QA spesifik platform yang berkelanjutan
- Anda tidak memiliki infrastruktur analitik untuk mengukur adopsi
- Anda tidak dapat memberikan komitmen sumber daya rekayasa untuk pemeliharaan
  berkelanjutan
- Anda menerapkan kunci sandi murni untuk persyaratan kepatuhan (compliance) tanpa
  perencanaan yang tepat

Mengerahkan segalanya karena alasan regulasi tanpa perencanaan yang tepat dapat
meningkatkan biaya secara signifikan. Sistem kunci sandi yang diimplementasikan dengan
buruk lebih buruk daripada tidak ada sistem kunci sandi sama sekali: hal itu mengikis
kepercayaan pengguna, menghasilkan beban dukungan, dan memberi pemangku kepentingan
internal alasan untuk membunuh proyek tersebut.

### 8.2 Luncurkan Kunci Sandi jika

- Anda telah merencanakan kelima masalah Hari ke-2 yang dijelaskan di atas
- Anda memiliki kemampuan produk, rekayasa, keamanan, dan analitik untuk mendukung
  peluncuran berkelanjutan
- Anda telah menganggarkan untuk pemeliharaan berkelanjutan, bukan hanya pembuatan awal
- Anda memiliki strategi peluncuran bertahap dengan target adopsi yang jelas
- Anda bekerja dengan mitra seperti Corbado yang menangani kompleksitas operasional untuk
  Anda

### 8.3 Keputusan Bangun (Build) vs Beli (Buy)

Masalah Hari ke-2 yang dijelaskan dalam artikel ini adalah alasan yang tepat mengapa
banyak enterprise memilih untuk membeli daripada membangun infrastruktur kunci sandi
mereka. Membangun server WebAuthn adalah bagian yang mudah. Mengoperasikan sistem kunci
sandi tingkat produksi di ribuan kombinasi perangkat, dengan pemulihan yang tepat,
pemantauan, dan analitik adopsi, adalah hal yang membedakan demo dari penerapan nyata.

## 9. Bagaimana Corbado Menyelesaikan Masalah Hari Ke-2 Kunci Sandi

Corbado ada khusus karena masalah Hari ke-2 itu sulit. Platform kami menangani
kompleksitas operasional sehingga Anda tidak perlu membangun dan memeliharanya sendiri.

### 9.1 Pemulihan dan Fallback

Corbado menyediakan alur pemulihan _out-of-the-box_ dengan tingkat keamanan adaptif. Mulai
dari strategi kunci sandi yang disinkronkan,
[autentikasi lintas perangkat](https://www.corbado.com/id/glossary/cda), hingga verifikasi identitas otomatis.
Logika pemulihan dibangun di dalam dan diperbarui secara berkelanjutan.

### 9.2 Kompatibilitas Lintas Perangkat

SDK frontend kami telah diuji sebelumnya pada ribuan kombinasi OS, browser, dan penyedia
kunci sandi. Deteksi perangkat, penanganan UI bersyarat (conditional UI) dan perutean
fallback terjadi secara otomatis. Ketika versi browser baru merusak sesuatu, kami
memperbaikinya di SDK kami sebelum pengguna Anda menyadarinya.

### 9.3 Dukungan Aplikasi Native

Corbado mendukung implementasi kunci sandi native dan [WebView](https://www.corbado.com/blog/native-app-passkeys)
dengan SDK yang mengabstraksi perbedaan platform. Anda fokus pada UX aplikasi Anda
sementara kami menangani teknis dasar kunci sandi di seluruh iOS dan Android.

### 9.4 Analitik Adopsi

Dasbor analitik kami melacak setiap metrik yang penting: tingkat pembuatan kunci sandi,
tingkat keberhasilan login, tingkat fallback, dan rincian tingkat perangkat. Anda
mendapatkan wawasan yang dapat ditindaklanjuti untuk mendorong adopsi, bukan hanya data
mentah.

### 9.5 Pemantauan Perubahan Platform

Corbado terus memantau perubahan OS dan browser yang memengaruhi kunci sandi. SDK kami
diperbarui secara proaktif. Penerapan kunci sandi Anda tetap stabil bahkan saat lanskap
platform bergeser di bawahnya.

## 10. Kesimpulan

Kunci sandi adalah standar emas autentikasi. Itu tidak dipertanyakan. Namun jalan dari
"mendukung kunci sandi" ke "kunci sandi yang bekerja secara andal dalam skala besar"
diaspal dengan masalah Hari ke-2 yang diremehkan oleh sebagian besar tim.

Kelima masalah yang telah kita bahas (pemulihan, edge case lintas perangkat, kompleksitas
aplikasi native, adopsi, dan perubahan platform) tidak jarang terjadi. Itu adalah inti
tantangan operasional dari setiap penerapan kunci sandi produksi. Mengabaikannya tidak
membuatnya hilang. Itu hanya berarti pengguna Anda yang akan menemukannya lebih dulu.

Rekomendasi jujur saya: jika Anda tidak memiliki _know-how_ dan sumber daya untuk
mengimplementasikan kunci sandi dengan benar, jangan meluncurkannya. Baik Anda
berinvestasi dalam kapabilitas (produk, rekayasa, keamanan, dan analitik) atau bekerja
sama dengan mitra yang telah menyelesaikan masalah ini. Hasil terburuknya adalah penerapan
kunci sandi setengah matang yang dibatalkan karena tidak ada yang merencanakan Hari ke-2.

## Pertanyaan yang Sering Diajukan (FAQ)

### Apa saja 5 masalah Hari ke-2 yang menyebabkan kegagalan proyek kunci sandi setelah peluncuran?

Kelima masalah operasional tersebut adalah alur pemulihan dan fallback yang tidak aman,
edge case ekosistem lintas perangkat, kompleksitas aplikasi native, adopsi pengguna yang
rendah, dan regresi diam-diam dari pembaruan OS serta browser. Sebagian besar tim fokus
pada integrasi WebAuthn awal dan meremehkan tantangan pasca-peluncuran ini, yang
menyebabkan banyak proyek kunci sandi dibatalkan atau diam-diam ditinggalkan secara
internal.

### Bagaimana cara menangani autentikasi kunci sandi lintas perangkat untuk pengguna enterprise di Windows yang mendaftar di iPhone?

Pengguna dapat mengautentikasi melalui kode QR dan alur lintas perangkat Bluetooth, tetapi
ini memerlukan Bluetooth yang aktif di kedua perangkat dan dapat diblokir oleh kebijakan
MDM perusahaan dan firewall. UX bervariasi secara signifikan antar browser dan pengguna
sering kali tidak mengerti mengapa mereka memindai kode QR, membuat perutean fallback yang
sadar perangkat dan komunikasi yang jelas menjadi sangat penting untuk penerapan
enterprise.

### Metrik adopsi kunci sandi apa yang harus saya targetkan dan pantau setelah peluncuran?

Adopsi yang kuat berarti tingkat pembuatan kunci sandi di atas 60% dari pengguna yang
memenuhi syarat dan
[tingkat login kunci sandi](https://www.corbado.com/id/blog/hari-kunci-sandi-sedunia-passkey-benchmark-2026) di
atas 40% dari semua login. Tingkat pembuatan di bawah 10% dan login di bawah 5% setelah
tiga bulan menandakan peluncuran yang gagal. Mengukur ini memerlukan pelacakan
infrastruktur khusus untuk tingkat pembuatan, tingkat keberhasilan login, tingkat
fallback, dan pengabaian yang dirinci berdasarkan kombinasi perangkat dan OS.

### Haruskah saya membangun kunci sandi secara native di aplikasi seluler saya atau menggunakan WebView?

Implementasi native memberikan UX terbaik di kelasnya tetapi memerlukan basis kode iOS dan
Android yang terpisah dengan penanganan API spesifik platform dan pipeline QA independen.
Pendekatan WebView berbagi logika web tetapi memperkenalkan ketidakkonsistenan dukungan
kunci sandi tergantung pada jenis WebView. Di iOS saja, pilihan antara
[WKWebView](https://www.corbado.com/blog/native-app-passkeys),
[SFSafariViewController](https://www.corbado.com/blog/native-app-passkeys), dan
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) masing-masing membawa
karakteristik dukungan kunci sandi yang berbeda yang harus dievaluasi sebelum berkomitmen
pada arsitektur.

### Mengapa pemulihan akun kunci sandi lebih sulit daripada kelihatannya dan apa pendekatan yang tepat?

Pemulihan yang disederhanakan seperti reset berbasis email memperkenalkan kembali saluran
rentan phising, sementara pemulihan yang terlalu ketat seperti wajib menggunakan
[kunci keamanan perangkat keras](https://www.corbado.com/id/blog/kunci-keamanan-perangkat-keras-fido2-terbaik)
menciptakan pengabaian. Pendekatan yang disarankan berlapis: kunci sandi yang disinkronkan
sebagai strategi utama, autentikasi kode QR lintas perangkat sebagai lapisan kedua,
verifikasi identitas otomatis dengan pemeriksaan keaktifan (liveness checks) sebagai
lapisan ketiga, dan kredensial yang dapat diverifikasi secara digital sebagai lapisan
keempat. Lapisan mana yang akan diimplementasikan bergantung pada model ancaman, basis
pengguna, dan persyaratan peraturan Anda.