MFA Berbasis Risiko Perbankan POJK 11/2022: Panduan Bank

Hampir setiap diskusi tentang MFA berbasis risiko perbankan POJK 11/2022 berangkat dari dua pertanyaan yang sama: apakah regulator mewajibkan teknologi autentikasi tertentu, dan apakah metode yang dipakai bank hari ini masih memadai. POJK Nomor 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum tidak menyusun daftar belanja teknologi. Yang diwajibkan adalah proses: bank mengidentifikasi risiko, menetapkan kontrol yang proporsional, lalu membuktikan kontrol itu benar-benar bekerja. Artikel ini membedah cara membaca kerangka tersebut, sekaligus menunjukkan di titik mana security key hardware masuk akal ditempatkan. Untuk gambaran menyeluruh soal MFA tahan phishing di luar konteks POJK, lihat panduan lengkap MFA tahan phishing untuk enterprise dan perbankan.

Apa yang Diatur POJK 11/2022 dan Mengapa Pendekatannya Berbasis Risiko

POJK 11/2022 menggantikan POJK 38/POJK.03/2016 tentang Penerapan Manajemen Risiko dalam Penggunaan Teknologi Informasi oleh Bank Umum, dengan cakupan yang jauh lebih luas: tata kelola TI, manajemen risiko TI, pengamanan informasi, pengelolaan pusat data dan pusat pemulihan bencana, penyelenggaraan layanan perbankan elektronik, pemanfaatan pihak ketiga termasuk komputasi awan, sampai kewajiban pelaporan kepada Otoritas Jasa Keuangan. Rincian teknisnya dituangkan dalam surat edaran turunan, SEOJK 29/SEOJK.03/2022, yang menerjemahkan prinsip-prinsip POJK ke tataran operasional.

Karakter utama regulasi ini principle-based dan risk-based. Bank memang diminta menyelenggarakan pengamanan informasi yang mencakup pengendalian akses, autentikasi pengguna, kerahasiaan dan integritas data, serta pemantauan insiden. Tetapi kekuatan kontrolnya tidak diseragamkan untuk semua kanal dan semua pengguna. Bank berskala besar dengan kanal digital masif tidak diharapkan menerapkan kontrol yang identik dengan bank berprofil risiko sederhana. Yang harus sama justru kualitas argumennya: asesmen risiko ada, keputusan kontrol tercatat, pengujian dilakukan, dan evaluasinya berjalan berkala.

Konsekuensi praktis bagi desain autentikasi

Karena kerangkanya berbasis risiko, kalimat “kami sudah memakai MFA” tidak akan menyelamatkan Anda di hadapan auditor internal maupun pemeriksa OJK. Pertanyaan lanjutannya selalu sama: MFA jenis apa, untuk pengguna mana, melindungi aset apa, dari skenario ancaman apa. MFA yang cukup untuk menahan pencurian kata sandi belum tentu bertahan menghadapi phishing real-time dengan proxy, SIM swap, atau MFA fatigue. Perbedaan itulah yang perlu dituangkan secara eksplisit dalam dokumen asesmen risiko Anda.

Menerjemahkan MFA Berbasis Risiko Perbankan POJK 11/2022 ke Desain Kontrol

Pendekatan yang paling mudah dipertahankan saat pemeriksaan: petakan populasi pengguna dan jenis transaksi ke tingkat risiko, lalu tetapkan kekuatan autentikasi minimum per tingkat. Tabel berikut contoh kerangkanya. Silakan sesuaikan dengan selera risiko bank Anda — angka dan batasnya adalah keputusan internal, bukan kutipan regulasi.

Inti MFA berbasis risiko perbankan POJK 11/2022 bukan menyamaratakan kontrol terkuat ke seluruh populasi. Yang penting, tidak ada aset bernilai tinggi yang hanya dilindungi faktor yang lemah terhadap ancaman dominannya. Model risiko adaptif sekaligus menolong pengalaman nasabah: gesekan baru ditambahkan ketika sinyal risiko naik, misalnya perangkat baru, alamat IP asing, atau perubahan data penerima.

Peran Security Key dalam Bauran Autentikasi Bank

Security key hardware seperti YubiKey bekerja sebagai autentikator kriptografis yang terikat pada domain. Kunci privat tidak pernah meninggalkan perangkat, dan protokol WebAuthn hanya mau menandatangani challenge untuk origin yang cocok dengan saat pendaftaran. Karakteristik inilah yang membuatnya menahan phishing secara struktural — bukan sekadar mempersulit penyerang. Mekanisme teknisnya dapat Anda baca pada ulasan cara kerja FIDO2 dan WebAuthn. Perbandingan ketahanannya terhadap kode sekali pakai dibahas pada artikel security key versus OTP SMS, sedangkan versi yang berfokus pada konteks perbankan tersedia pada security key vs OTP SMS untuk perbankan.

Dalam konteks perbankan, penempatan yang paling bernilai umumnya justru bukan di sisi nasabah ritel, melainkan pada populasi internal berisiko tinggi:

• Akses privileged dan administratif ke core banking, switching, basis data nasabah, serta konsol penyedia cloud.
• Akses jarak jauh pegawai melalui VPN atau ZTNA — termasuk vendor dan pihak ketiga yang mendapat akses terbatas.
• Rekayasa dan operasi: repositori kode, pipeline CI/CD, penandatanganan artefak, dan akses ke lingkungan produksi.
• Peran finansial sensitif: persetujuan pembayaran bernilai besar, treasury, dan pemeliharaan data master vendor yang kerap menjadi sasaran business email compromise.
• Akun break-glass pada penyedia identitas — akun yang justru paling sering luput dari kebijakan MFA organisasi.

Pertimbangan pengadaan dan sertifikasi

Bagi bank yang menuntut jejak sertifikasi pada modul kriptografi, tersedia varian yang divalidasi FIPS 140 (mis. seri YubiKey 5 FIPS). Satu hal perlu ditegaskan: OJK tidak mewajibkan sertifikasi FIPS untuk autentikator. Validasi tersebut berguna sebagai bukti pendukung dalam asesmen dan dokumen pengadaan, terutama bila bank Anda bagian dari grup dengan standar keamanan lintas entitas. Soal pemilihan bentuk faktor, antarmuka, dan model distribusi, lihat panduan memilih YubiKey untuk perusahaan.

Roadmap Implementasi Bertahap

Penerapan serentak untuk seluruh pengguna jarang berhasil di institusi perbankan. Urutan berikut biasanya lebih realistis. Fase 1: inventarisasi identitas dan aset, tentukan mana yang kritikal, dan catat metode autentikasi yang berlaku saat ini berikut kelemahannya. Fase 2: terapkan security key untuk administrator, akun break-glass, dan akses jarak jauh istimewa — minimal dua kunci per pengguna supaya ada cadangan. Fase 3: perluas ke populasi pegawai berisiko tinggi, integrasikan dengan penyedia identitas dan PAM, lalu tutup jalur pemulihan yang lemah; proses reset lewat helpdesk sering menjadi titik terlemah dari keseluruhan rantai. Fase 4: kurangi ketergantungan pada kata sandi bagi populasi yang sudah siap, seperti diuraikan pada pembahasan passwordless login untuk enterprise. Sepanjang keempat fase, dokumentasikan asesmen risiko, hasil pengujian keamanan, dan evaluasi berkala. Artefak inilah yang akan diminta saat pemeriksaan.

Batas Klaim: Apa yang Tidak Dinyatakan Regulasi

Ada tiga kesalahpahaman yang sebaiknya tidak masuk ke dokumen internal Anda. Pertama, POJK 11/2022 tidak menyatakan FIDO2 atau security key sebagai kewajiban; keduanya pilihan kontrol yang sah dan kuat, bukan mandat. Kedua, regulasi tidak melarang OTP melalui SMS. Yang diminta adalah menilai apakah metode itu memadai untuk tingkat risiko tertentu, lalu mendokumentasikan mitigasinya bila tetap dipakai. Ketiga, patuh pada POJK 11/2022 tidak otomatis memenuhi kewajiban lain. Perlindungan data pribadi nasabah tunduk pada UU 27/2022 tentang Pelindungan Data Pribadi dan PP 71/2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik, sementara aspek pembuktian elektronik merujuk pada UU ITE beserta perubahannya. Bagi bank yang tergabung dalam konglomerasi keuangan, tata kelola terintegrasi di bawah UU P2SK 4/2023 dan POJK 30/2024 menambah dimensi konsolidasi pelaporan yang perlu diselaraskan dengan kebijakan keamanan grup.

Pertanyaan yang sering diajukan

Apakah POJK 11/2022 mewajibkan multi-factor authentication? Regulasi mewajibkan bank menerapkan pengamanan informasi dan pengendalian akses yang memadai terhadap profil risikonya, termasuk mekanisme autentikasi pengguna. Untuk layanan perbankan elektronik dan akses istimewa, praktik yang lazim diterima memang autentikasi lebih dari satu faktor. Bentuk faktornya, bagaimanapun, tetap keputusan bank — dan keputusan itu harus berdiri di atas asesmen risiko yang terdokumentasi.

Apakah bank harus mengganti seluruh OTP dengan security key? Tidak. Segmentasi lebih efisien: security key untuk populasi dan transaksi berisiko tinggi, mekanisme lain yang tetap dipantau untuk risiko lebih rendah. Penggantian menyeluruh pada kanal ritel berskala besar biasanya sulit dijustifikasi, baik dari sisi biaya maupun operasional.

Bagaimana menangani kehilangan security key oleh pegawai? Terbitkan minimal dua kunci per pengguna sejak awal, lalu definisikan prosedur pencabutan dan penerbitan ulang dengan verifikasi identitas setara pendaftaran awal. Jalur pemulihan yang lemah meniadakan seluruh manfaat autentikator kuat — uji dan audit proses ini seperti kontrol lainnya.

Bukti apa yang perlu disiapkan untuk pemeriksaan? Dokumen asesmen risiko TI, kebijakan dan prosedur pengendalian akses, matriks pemetaan risiko ke kontrol autentikasi, catatan penerbitan dan pencabutan autentikator, hasil pengujian keamanan berkala, serta bukti evaluasi dan tindak lanjut temuan. Yang paling sering diperiksa: konsistensi antara kebijakan tertulis dan konfigurasi sistem yang benar-benar berjalan.