Passkeys: Apakah Mereka Siap untuk Penggunaan Perusahaan?

Blog ini pertama kali diterbitkan pada tahun 2024 dan telah diperbarui. 

Passkey semakin umum digunakan berkat layanan konsumen seperti Google, Apple, Facebook, Meta, dan lainnya. Penggunaan passkey secara signifikan meningkatkan keamanan dibandingkan dengan proses masuk tradisional berbasis kata sandi atau otentikasi multi-faktor (MFA) tanpa kata sandi.

Adalah hal yang wajar jika beberapa solusi konsumen meluas ke penggunaan profesional-pikirkanlah tentang kemampuan untuk mengirim reaksi emoji ke email. Tetapi hanya karena Instagram mengizinkan saya masuk menggunakan kata sandi, apakah itu berarti bisnis juga harus melakukannya?

Singkatnya: apakah kunci sandi sudah siap untuk penggunaan perusahaan?

The Aliansi FIDO didirikan pada tahun 2013 oleh berbagai perusahaan untuk mengembangkan standar otentikasi yang akan berfungsi sebagai faktor kedua; hari ini, FIDO dapat berfungsi sebagai metode otentikasi tanpa kata sandi yang kuat.

Sejak 2013, FIDO telah menjadi salah satu metode masuk tanpa kata sandi yang paling populer, terutama karena metode ini sesuai dengan akronim yang menjadi namanya: metode ini memungkinkan verifikasi identitas secara cepat di dunia maya. Aliansi FIDO sangat berfokus pada lingkungan konsumen. Tidak heran, anggota-anggota utamanya aktif di bidang ini: Apple, Google, PayPal, dan Microsoft. RSA adalah anggota Aliansi FIDO dan menjadi salah satu ketua Kelompok Kerja Penerapan di Perusahaan.

Kredensial FIDO menggunakan pasangan kunci asimetris untuk mengautentikasi ke dalam sebuah layanan. Ketika kredensial FIDO didaftarkan ke sebuah layanan, pasangan kunci baru dibuat pada pengautentikasi FIDO dan layanan tersebut kemudian mempercayai pasangan kunci tersebut-dan hanya pasangan kunci tersebut. Pasangan kunci tersebut terhubung ke nama domain yang tepat dari layanan.

Keterikatan yang ketat antara suatu layanan dan kredensial FIDO itulah yang menghasilkan tingkat ketahanan yang tinggi terhadap serangan phishing: jika seorang pengguna mencoba masuk ke situs phishing palsu menggunakan passkey yang dibuat untuk situs asli, upaya tersebut akan gagal karena nama domain yang disebutkan tidak akan cocok dengan kredensial tersebut.

Pada tahun 2022, Apple, Google, dan Microsoft meluncurkan dukungan untuk jenis kredensial FIDO baru, yang mereka sebut sebagai kunci sandi. Pada tahun 2023, Aliansi FIDO mengadopsi istilah "kunci sandi" untuk semua jenis kredensial FIDO, yang menyebabkan potensi kebingungan tentang apa yang dimaksud oleh sebuah organisasi ketika menyebutkan "kunci sandi."

Kemungkinan ambiguitas ini telah diatasi oleh Aliansi FIDO (lihat di bawah) tetapi masih bisa terjadi di organisasi. Penting untuk mengatasi ambiguitas tersebut, karena tidak semua kunci sandi dibuat sama atau sesuai untuk penggunaan perusahaan.

Jenis-jenis kunci sandi

Sekarang ada dua jenis kunci sandi, seperti yang didefinisikan oleh Aliansi FIDO: terikat perangkat dan disinkronkan.

Tombol sandi yang terikat perangkat vs tombol sandi yang disinkronkan

Kunci akses yang terikat perangkat umumnya disimpan pada perangkat “kunci keamanan” tertentu. Jenis kunci akses ini umumnya dianggap lebih aman karena kunci pribadi tidak pernah meninggalkan perangkat, sehingga tahan terhadap upaya ekstraksi atau serangan jarak jauh.

Namun, hal ini juga berarti bahwa jika perangkat tersebut hilang atau rusak, pengguna harus mendaftarkan kunci akses baru ke perangkat baru. Kunci akses yang terikat pada perangkat sangat disukai di lingkungan dengan tingkat keamanan tinggi dan dalam konteks penggunaan korporat, yang sering kali memanfaatkan perangkat keras seperti kunci keamanan atau Trusted Platform Modules (TPM).

Kunci akses yang terikat pada perangkat kini juga didukung di beberapa aplikasi seluler, seperti aplikasi RSA Authenticator untuk iOS dan Android.

Kunci sandi yang disinkronkan

Dengan passkey yang disinkronkan, materi kunci disimpan melalui apa yang disebut “remote sync fabric”, dan materi kunci tersebut kemudian dapat dipulihkan di perangkat lain mana pun yang dimiliki oleh pengguna yang sama. Jaringan sinkronisasi utama saat ini adalah Microsoft, Google, dan Apple. Artinya, jika Anda mendaftarkan ponsel Android Anda sebagai passkey, maka materi kunci yang terkait akan disimpan oleh Google, dan karenanya akan tersedia di semua perangkat Android Anda yang lain tak lama setelahnya.

Kunci sandi yang disinkronkan-selain mendapat dukungan dari layanan yang digunakan secara luas seperti WhatsApp atau Facebook-merupakan alasan utama peningkatan tajam dalam penggunaan kunci sandi secara umum. Sangat mudah untuk mengetahui alasannya: satu pengguna dengan banyak akun dan banyak perangkat dapat menggunakan kunci sandi yang disinkronkan yang sama di antara semuanya.

Passkeys menggantikan kata sandi tradisional dengan pasangan kunci kriptografi, sehingga memberikan otentikasi yang kuat dan tahan terhadap serangan phishing. Saat pengguna mendaftar ke suatu layanan, perangkatnya akan menghasilkan pasangan kunci privat-publik yang unik. Kunci privat disimpan dengan aman di perangkat pengguna, sedangkan kunci publik dibagikan kepada layanan tersebut. Selama proses otentikasi, perangkat membuktikan kepemilikan kunci pribadi dengan menandatangani tantangan yang dikirimkan oleh layanan, dan tanda tangan tersebut diverifikasi menggunakan kunci publik yang tersimpan. Tidak ada rahasia bersama yang dikirimkan, dan tidak ada kata sandi yang dibuat atau disimpan, sehingga secara drastis mengurangi risiko pencurian kredensial atau serangan replay.

Kata sandi tradisional bergantung pada rahasia bersama yang dapat ditebak, dicuri, atau dibobol, sehingga menjadi pintu masuk yang umum bagi para penyerang. Kata sandi ini sering kali digunakan kembali di berbagai akun, disimpan dengan tidak aman, dan rentan terhadap serangan brute-force atau serangan pengisian kredensial.

Passkey menghilangkan risiko-risiko ini dengan menggantikan kata sandi menggunakan kriptografi kunci publik-pribadi. Otentikasi dilakukan dengan membuktikan kepemilikan kunci tersebut—tanpa perlu mengirimkannya. Pendekatan ini membuat sebagian besar vektor serangan umum menjadi tidak relevan lagi, termasuk phishing, pencurian kredensial, dan penggunaan ulang kata sandi. Bagi organisasi, passkeys menawarkan lompatan maju dalam otentikasi yang aman, sekaligus mengurangi beban terkait pengaturan ulang kata sandi dan tiket dukungan.

• Tahan phishing: Kunci sandi dirancang untuk mencegah serangan phishing tradisional. Karena tidak ada kata sandi yang terlibat, tidak ada yang bisa dicuri atau digunakan kembali.
• Cepat dan nyaman: Masuk dengan kunci sandi sering kali semudah menggunakan biometrik (seperti ID Wajah atau sidik jari), sehingga pengalaman pengguna menjadi lebih lancar.
• Pengalaman pengguna yang akrab: Login dengan kunci sandi menyerupai pola autentikasi seluler pada umumnya, jadi hanya sedikit atau bahkan tidak ada kurva pembelajaran.
• Keamanan pencocokan domain: Passkey menawarkan lapisan perlindungan ekstra dengan memastikan materi kunci hanya bekerja dengan domain layanan asli - manfaat yang tidak diberikan oleh semua metode MFA.
• Disetujui pemerintah: Di A.S., perlawanan terhadap phishing adalah pendorong utama di balik mandat federal. Perintah Eksekutif 14028 membutuhkan autentikasi tanpa kata sandi dan tahan phishing untuk melindungi infrastruktur penting.

Meskipun kunci sandi memberikan keuntungan yang signifikan, kunci sandi juga memiliki beberapa tantangan dan masalah yang signifikan.

• Pengalaman pengguna: Permintaan memasukkan kunci keamanan, seperti permintaan untuk memasukkan kunci keamanan ke port USB atau memasukkan PIN, misalnya, tampilannya berbeda-beda tergantung pada sistem operasi dan peramban yang digunakan. Permintaan-permintaan tersebut kemungkinan akan mempersulit proses pelatihan pengguna dan meningkatkan jumlah panggilan ke layanan dukungan.
• Pengalihan perhatian dari serangan lain: Siapa pun yang mengira bahwa penggunaan passkey tiba-tiba membuat mereka kebal terhadap upaya bypass MFA seperti serangan rekayasa sosial, sungguh keliru. Kunci akses membantu melindungi dari satu jenis serangan rekayasa sosial: phishing. Sayangnya, masih ada varian lain. Serangan terhadap MGM Resorts atau Caesars Palace di Las Vegas memiliki unsur rekayasa sosial: memanfaatkan layanan bantuan (help desk) agar penyerang dapat mendaftarkan sendiri perangkat otentikasi MFA.
• Tantangan terkait kehilangan perangkat atau penggantian perangkat: Jika pengguna kehilangan akses ke perangkat yang mendukung kunci akses terikat perangkat, kunci tersebut tidak dapat dipulihkan.
• Dukungan yang terbatas di seluruh layanan: Meskipun penggunaannya semakin meluas, belum semua situs web atau sistem perusahaan mendukung passkey, sehingga hal ini dapat membatasi kegunaannya dalam kegiatan sehari-hari.
• Kebingungan pengguna atau kurangnya kesadaran: Konsep passkey masih tergolong baru bagi banyak pengguna, yang dapat menimbulkan kebingungan terkait pengaturan, sinkronisasi, atau proses yang terjadi di balik layar. Perbedaan istilah (passkeys, security keys, FIDO keys) serta standar yang terus berkembang di seluruh industri dapat memperparah kebingungan ini dan menyulitkan pengguna serta organisasi untuk memahami praktik terbaik secara jelas, serta menerapkan dan mengadopsi passkeys secara konsisten. Hal ini juga dapat menyebabkan kesalahan selama pengaturan dan penggunaan, peningkatan jumlah panggilan dukungan, serta potensi celah keamanan.
• Kesiapan infrastruktur: Penerapan passkey mungkin mengharuskan organisasi untuk melakukan pembaruan pada platform identitas, kebijakan pengelolaan perangkat, dan program pelatihan—terutama saat beralih dari sistem otentikasi lama. Organisasi mungkin mendapati bahwa sumber daya lama atau yang berada di lokasi (on-premises) mungkin tidak kompatibel dengan passkey karena sistem otentikasi yang hanya berbasis web. Dalam kasus tersebut, organisasi sebaiknya memodernisasi sistem MFA mereka dengan tanpa kata sandi kemampuan yang dapat diterapkan di berbagai lingkungan dan tetap mendukung infrastruktur lama.

Mengingat tantangan yang dihadapi oleh passkey saat ini dalam hal menghadirkan alur kerja yang seragam di berbagai peramban, perangkat, dan sistem operasi, apa yang dapat dilakukan oleh industri ini untuk memastikan pengalaman lintas platform yang benar-benar mulus? Bagaimana kita dapat menentukan jalan terbaik untuk menyelesaikan ketidakkonsistenan yang dapat membingungkan pengguna dan menghambat adopsi secara luas?

Di RSA, kepemimpinan UX kami secara aktif terlibat dalam kelompok kerja Aliansi FIDO untuk mengadvokasi pengalaman pengguna yang konsisten. Dengan menyumbangkan wawasan kami, kami bertujuan untuk membantu membentuk standar yang menghasilkan lebih sedikit gangguan, lebih sedikit gesekan, dan lebih banyak keseragaman bagi pengguna akhir.

Mobilitas adalah aspek lain dalam menciptakan pengalaman passkey yang mulus di seluruh lingkungan. Pengguna tenaga kerja semakin mengharapkan kenyamanan alur kerja yang mengutamakan perangkat seluler. Jika mengakses sumber daya perusahaan di ponsel pintar terasa sama intuitifnya dengan membuka kunci perangkat yang sama, adopsi metode autentikasi baru-seperti kunci sandi-menjadi jauh lebih mudah. Pengalaman seluler tanpa hambatan membantu meruntuhkan resistensi pengguna, meminimalkan kurva pembelajaran dan membuat transisi dari kata sandi menjadi jauh lebih lancar. Dengan menghadirkan antarmuka yang familiar, transparan tentang izin, dan konsisten terlepas dari perangkat atau platform pengguna, organisasi dapat mengurangi kebingungan dan meningkatkan kepercayaan. Solusi RSA mobile FIDO berfungsi sebagai contoh bagaimana mengimplementasikan kata sandi dengan cara yang bersifat perangkat-agnostik.

Untuk fasilitas yang aman dan lingkungan dengan tingkat keamanan tinggi di mana otentikasi mobile tidak diizinkan, Seri RSA iShield Key 2 Menyediakan autentikator perangkat keras yang bersertifikat FIPS 140-3 Level 3, FIDO2, yang menawarkan keamanan tanpa kata sandi yang tahan terhadap phishing dan kompatibel dengan berbagai platform.

Mereka mengatakan bahwa ketika Anda memiliki palu, segala sesuatu dapat terlihat seperti paku. Mengubah solusi-bahkan solusi yang hebat-yang awalnya ditujukan untuk penggunaan konsumen menjadi aplikasi perusahaan dapat menimbulkan risiko yang signifikan.

Sewaktu membaca artikel ini, Anda mungkin merasa mual saat menyebutkan "kain sinkronisasi". Firasat Anda benar.

Fakta bahwa kunci akses yang disinkronkan muncul seolah-olah secara ajaib di semua perangkat tempat pengguna telah masuk melalui Apple atau Google merupakan tanda bahaya besar di lingkungan korporat dan seharusnya memunculkan beberapa pertanyaan penting:

• Haruskah pengguna diizinkan untuk menggunakan beberapa perangkat (mungkin juga yang digunakan secara pribadi) untuk autentikasi sama sekali? Jika ya... berapa banyak?
• Kunci sandi yang disinkronkan memungkinkan pemulihan kunci sandi yang "hilang" dengan proses pemulihan akun, misalnya, Google atau Apple. Itu bagus... tetapi apakah proses ini cukup aman untuk Anda?
• Fitur Apple yang memungkinkan pengguna untuk berbagi kunci sandi dengan teman atau keluarga cukup bagus... tetapi apakah ini juga berlaku untuk kunci sandi yang digunakan untuk masuk ke aplikasi perusahaan?

Ketika menggunakan kunci sandi yang disinkronkan, keamanan perusahaan Anda tiba-tiba sangat bergantung pada keamanan teknis dan organisasi Apple dan Google. Tentu saja, ada ketergantungan tertentu karena penggunaan iOS dan Android-tetapi kunci sandi yang disinkronkan meningkatkan ketergantungan ini secara signifikan.

Ini juga bukan kerentanan teoretis. Retool membahas bagaimana pelaku ancaman telah menggunakannya untuk mendapatkan akses ke sistemnya, dengan mencatat bahwa fungsionalitas tersebut berarti bahwa “jika akun Google Anda disusupi, maka sekarang adalah kode MFA Anda.”

Apakah kunci sandi harus digunakan di perusahaan tidak bisa dijawab dengan cara yang umum. Setiap organisasi berbeda dan harus menyeimbangkan antara keamanan dan prioritas operasionalnya yang unik.

Selain itu, apakah akan menggunakan kunci sandi atau tidak, seharusnya tidak menjadi pertanyaan ya/tidak. Pengenalan kunci sandi atau login tanpa kata sandi secara umum harus digunakan untuk meninjau secara mendasar seluruh proses MFA organisasi. Apa yang baik untuk token OTP perangkat keras selama 15 tahun mungkin tidak lagi sepenuhnya benar untuk kunci sandi atau metode MFA lainnya saat ini.

RSA meyakini bahwa passkey dapat diterapkan untuk keperluan perusahaan jika selaras dengan strategi organisasi dan jika organisasi telah mempertimbangkan dengan matang jawaban atas pertanyaan-pertanyaan berikut. Kami telah melihat organisasi-organisasi yang berhasil menggunakan passkey dengan RSA^® ID Plus, platform manajemen identitas dan akses (IAM) kami yang komprehensif yang menyediakan berbagai opsi tanpa kata sandi.

Karena kami adalah organisasi yang mengutamakan keamanan dan menggunakan prinsip-prinsip Secure by Design/Secure by Default, kami mencegah penggunaan kata sandi yang disinkronkan secara default. Hanya kunci sandi yang terikat pada perangkat yang tersedia secara default di lingkungan RSA untuk memberikan tingkat keamanan maksimum di luar kotak, dan tanpa pekerjaan tambahan oleh admin.

Ketika menilai apakah akan memperkenalkan kunci sandi, organisasi harus bertanya: Bagaimana autentikator kita terdaftar? Apakah ada proses yang dengan aman menangani skenario "Saya kehilangan pengautentikasi saya"? Bagaimana dengan klasifikasi pengguna, aplikasi, dan data?

Kunci sandi adalah satu Metode MFA salah satunya. Ya, ketahanannya terhadap serangan phishing memang luar biasa, tetapi apakah pengguna dapat masuk ke semua sumber daya yang dilindungi dan perlu mereka akses menggunakan fitur tersebut?.

Untuk alasan ini dan banyak alasan lainnya, penting bahwa sistem MFA Anda tidak hanya mutakhir secara teknis, tetapi juga mendukung berbagai macam metode MFA, seperti kode QR, biometrik, OTP, pesan push, dan kunci sandi.

Penting juga bahwa proses di sekitar MFA disesuaikan dengan ancaman-ancaman baru. Hal ini jauh melampaui sistem MFA yang sebenarnya: apakah meja bantuan Anda juga aman dari serangan rekayasa sosial?

Jika kunci sandi masuk akal bagi Anda, maka kami ingin membantu. Hubungi kami untuk mempelajari lebih lanjut atau memulai uji coba ID Plus gratis selama 45 hari.

Memutuskan untuk menerapkan passkey adalah bagian yang mudah. Panduan ini membahas tiga fase penerapan yang sukses — penilaian, uji coba, dan penerapan di seluruh perusahaan — dengan contoh nyata dari organisasi yang telah melalui proses tersebut. Untuk gambaran lengkap mengenai fitur tanpa kata sandi dari RSA, kunjungi Halaman solusi tanpa kata sandi RSA.

Tahap 1: Penilaian dan perencanaan (empat hingga delapan minggu)

1. Lakukan audit otentikasi. Identifikasi setiap aplikasi, infrastruktur, dan sistem yang memerlukan atau terlibat dalam proses otentikasi, serta catat mana saja yang belum mendukung FIDO2.
2. Identifikasi kelompok pengguna berisiko tinggi. Administrator dengan hak akses istimewa, staf keuangan, pekerja jarak jauh, dan pengguna perangkat bersama masing-masing memerlukan pendekatan yang berbeda — segmentasikan tenaga kerja Anda berdasarkan tingkat risiko sebelum merencanakan implementasi.
3. Tentukan kebijakan passkey Anda. Tentukan kelompok pengguna mana yang sebaiknya menggunakan passkey yang terikat perangkat, passkey yang disinkronkan, atau kombinasi keduanya. RSA merekomendasikan passkey yang terikat perangkat sebagai pengaturan default, sedangkan passkey yang disinkronkan disisihkan untuk kasus-kasus di mana pertimbangan pro dan kontra tersebut dapat dibenarkan.
4. Tinjau kebijakan internal yang mungkin memengaruhi penggunaan passkey, seperti batasan penggunaan port USB, BLE, atau perangkat seluler. Buat jadwal implementasi bertahap. Tetapkan tonggak pencapaian, tunjuk penanggung jawab, dan tentukan kriteria untuk melanjutkan atau membatalkan. Dapatkan dukungan dari jajaran eksekutif sejak dini.

Tahap 2: Pelaksanaan uji coba (enam hingga sepuluh minggu)

1. Pilihlah kelompok percontohan Anda dengan cermat. Staf TI dan keamanan merupakan pengguna awal yang ideal. Dengan menambahkan sekelompok kecil asisten eksekutif, hal ini akan membantu mengidentifikasi kasus-kasus khusus yang praktis, seperti penggunaan komputer bersama dan skenario pendelegasian tugas.
2. Sesuai dengan kebutuhan penggunaan Anda, uji kedua jenis passkey tersebut di lingkungan Anda. Pastikan proses pendaftaran, masuk, otentikasi ulang setelah perangkat dalam mode tidur, serta SSO berfungsi dengan baik di seluruh jenis perangkat dan sistem operasi yang digunakan oleh organisasi Anda.
3. Buat dan uji prosedur layanan bantuan. Simulasikan skenario kehilangan perangkat, lupa PIN, proses onboarding, dan offboarding sebelum hal-hal tersebut terjadi di lingkungan produksi. Staf layanan bantuan harus mampu menjalankan alur kerja pemulihan secara aman tanpa rentan terhadap rekayasa sosial.
4. Tentukan metrik keberhasilan. Pantau tingkat pendaftaran, tingkat keberhasilan/kegagalan otentikasi, dan volume tiket layanan bantuan sebagai patokan sebelum melakukan penskalaan.
5. Kumpulkan umpan balik yang terstruktur. Lakukan survei terhadap pengguna uji coba pada minggu kedua dan keenam. Gunakan hasil yang diperoleh untuk memperbarui materi pelatihan dan konfigurasi sebelum peluncuran secara luas.

Fase 3: Peluncuran di tingkat perusahaan (dua hingga enam bulan)

1. Luncurkan program manajemen perubahan. Video panduan singkat dan panduan kerja tertulis lebih efektif daripada dokumentasi yang panjang. Sesuaikan konten berdasarkan segmen pengguna — pengalaman seorang pengembang yang bekerja dari jarak jauh tentu berbeda dengan pengguna yang bekerja di ruang kerja dengan workstation bersama.
2. Lakukan peluncuran secara bertahap. Lakukan penerapan berdasarkan departemen, wilayah geografis, atau tingkatan risiko. Pengguna berisiko tinggi biasanya didahulukan; sedangkan pengguna yang menggunakan perangkat bersama dan yang bergantung pada sistem lama dilakukan terakhir.
3. Pastikan metode otentikasi cadangan tetap tersedia. Jangan langsung menghapus MFA versi lama. Pertahankan layanan OTP push, kode QR, atau token perangkat keras sebagai opsi cadangan hingga jumlah pengguna yang terdaftar mencapai ambang batas target Anda (biasanya 90%+ per departemen).
4. Pantau tingkat adopsi dan kondisi otentikasi. Gunakan dasbor platform untuk melacak penyelesaian pendaftaran, tingkat kegagalan, dan tren layanan bantuan. Atur peringatan sedini mungkin untuk mendeteksi anomali.
5. Pastikan keamanan terintegrasi sepenuhnya. Setelah implementasi selesai, perbarui dokumentasi kebijakan MFA Anda dan lakukan tinjauan pasca-implementasi. Passkeys menghilangkan risiko phishing kredensial — namun, teknik rekayasa sosial di layanan bantuan tetap menjadi ancaman nyata.

Berikut ini adalah contoh-contoh ilustratif yang didasarkan pada pola penerapan yang umum.

Skenario 1: Jasa keuangan—bank regional, 5.000 karyawan
Sebuah bank regional berukuran menengah menerapkan kunci akses yang terikat pada perangkat melalui RSA ID Plus dengan Kunci keamanan perangkat keras bersertifikasi FIPS 140-3 untuk pengguna dengan hak istimewa dan staf cabang.

• Tantangan utama: Aplikasi teller versi lama memerlukan lapisan proxy FIDO2; staf help desk perlu mengikuti pelatihan ketahanan terhadap rekayasa sosial sebelum peluncuran.
• Jenis kata sandi: Kunci keamanan perangkat keras yang terikat pada perangkat
• Garis Waktu: Enam bulan
• Hasil: Penurunan jumlah tiket layanan bantuan 43%; tidak ada pelanggaran keamanan yang terkait dengan kata sandi setelah implementasi

Skenario 2: Pemerintah—lembaga federal, 12.000 pegawai
Sebuah lembaga federal sipil perlu memenuhi persyaratan Perintah Eksekutif (EO) 14028 dan OMB M-22-09 mengenai otentikasi multi-faktor (MFA) yang tahan terhadap serangan phishing di lingkungan hibrida yang mencakup segmen jaringan rahasia yang terisolasi secara fisik.

• Tantangan utama: Segmen yang terisolasi secara fisik memerlukan otentikasi tanpa koneksi internet; sistem manajemen kasus lama memerlukan lapisan proxy FIDO2; lebih dari 30 kantor cabang memerlukan dukungan pendaftaran jarak jauh.
• Jenis kata sandi: FIPS 140-3 Tingkat 3 RSA iShield Key 2 untuk seluruh staf; token OTP RSA DS100 untuk segmen yang terisolasi secara fisik
• Garis Waktu: Sepuluh bulan
• Hasil: Telah disertifikasi sepenuhnya sesuai dengan Perintah Eksekutif 14028 / M-22-09; tingkat pencatatan kredensial turun dari 18% menjadi di bawah 1%; terjadi penurunan jumlah tiket layanan bantuan sebesar 38%