{"id":5507,"date":"2026-09-30T08:45:48","date_gmt":"2026-09-30T01:45:48","guid":{"rendered":"https:\/\/dtisolution.id\/blog\/?p=5507"},"modified":"2026-09-30T08:45:48","modified_gmt":"2026-09-30T01:45:48","slug":"migrasi-sms-otp-ke-security-key-alasan-tahapan","status":"publish","type":"post","link":"https:\/\/dtisolution.id\/blog\/migrasi-sms-otp-ke-security-key-alasan-tahapan\/","title":{"rendered":"Migrasi SMS OTP ke Security Key: Alasan & Tahapannya"},"content":{"rendered":"
Jawaban singkat:<\/strong> SMS OTP rentan SIM swap, penyadapan SS7, dan phishing real-time, sehingga NIST SP 800-63B menggolongkannya sebagai autentikator restricted sejak 2017. Migrasi ke security key FIDO2 dijalankan bertahap: inventarisasi aplikasi dan IdP, penetapan kebijakan fallback, pilot pada akun berisiko tinggi, enrollment dua kunci per pengguna, lalu penonaktifan SMS OTP secara terukur.<\/div>\n

Satu nomor ponsel yang berpindah tangan ternyata cukup untuk menguras rekening. Kasus SIM swap yang menimpa jurnalis senior Ilham Bintang pada Januari 2020 memperlihatkan polanya: pelaku menerbitkan ulang kartu SIM korban di gerai operator, menerima seluruh SMS OTP perbankan yang seharusnya masuk ke ponsel korban, lalu memindahkan dana dalam hitungan hari. Insiden semacam inilah yang mendorong banyak tim keamanan menyusun rencana migrasi SMS OTP ke security key seperti YubiKey, autentikator fisik berbasis FIDO2 yang tidak bergantung pada jaringan seluler sama sekali.<\/p>\n

\"Ilustrasi
YubiKey dari DTI.<\/figcaption><\/figure>\n

Artikel ini membahas dua hal secara berurutan: alasan teknis dan regulasi mengapa SMS OTP layak dipensiunkan, lalu tahapan migrasi yang realistis untuk organisasi di industri teregulasi, dari bank dan multifinance sampai rumah sakit yang mengelola akses ke rekam medis elektronik.<\/p>\n

Mengapa SMS OTP layak diganti<\/h2>\n

Kanalnya berada di luar kendali Anda<\/h3>\n

SMS berjalan di atas infrastruktur telekomunikasi yang dirancang jauh sebelum ada ancaman siber modern. Protokol pensinyalan SS7 yang menghubungkan antar-operator memungkinkan pihak dengan akses ke jaringan operator mengalihkan SMS tanpa menyentuh ponsel korban. Di Indonesia, vektor yang lebih sering dipakai justru lebih sederhana: penerbitan ulang SIM di gerai dengan identitas palsu, atau rekayasa sosial ke call center operator. Apa pun kontrol yang Anda pasang di aplikasi, keamanan SMS OTP pada akhirnya bergantung pada prosedur verifikasi petugas gerai operator seluler. Itu bukan risiko yang bisa Anda mitigasi dari sisi sistem.<\/p>\n

NIST sudah memberi label “restricted” sejak 2017<\/h3>\n

NIST SP 800-63B, panduan autentikasi digital yang menjadi rujukan banyak kerangka keamanan, menggolongkan OTP yang dikirim melalui jaringan telepon publik (SMS maupun panggilan suara) sebagai autentikator restricted<\/em>. Statusnya bukan larangan. Namun organisasi yang tetap memakainya diminta menilai risikonya secara eksplisit, menawarkan alternatif kepada pengguna, dan menyiapkan rencana penggantian. Dengan kata lain: SMS OTP boleh dipakai, tetapi dengan catatan bahwa Anda sadar sedang memakai autentikator kelas dua.<\/p>\n

OTP bisa diserahkan ke situs palsu, security key tidak<\/h3>\n

Kelemahan paling mendasar tidak ada hubungannya dengan operator. Enam digit OTP bisa diketik korban di halaman phishing, diteruskan pelaku ke situs asli, dan sesi pun dibajak sebelum OTP kedaluwarsa. Serangan relay semacam ini kini dijual sebagai layanan jadi. Security key FIDO2 menutup celah itu lewat origin binding: kredensial hanya merespons domain tempat ia didaftarkan, sehingga halaman tiruan tidak mendapat apa-apa. Perbandingan teknis kedua metode ini sudah kami kupas di artikel security key vs OTP SMS dari sisi ketahanan phishing<\/a>, jadi di sini cukup satu kesimpulan: OTP melindungi dari penebakan password, bukan dari phishing.<\/p>\n

Biaya variabel yang terus berjalan<\/h3>\n

SMS OTP punya tagihan bulanan. Dengan tarif agregator di kisaran Rp350 sampai Rp600 per pesan, aplikasi dengan satu juta permintaan OTP per bulan menghabiskan miliaran rupiah per tahun, belum termasuk pesan yang dikirim ulang karena terlambat tiba atau gagal terkirim saat pengguna roaming. Security key adalah belanja satu kali per pengguna dengan umur pakai bertahun-tahun. Untuk populasi karyawan internal, titik impasnya sering tercapai kurang dari dua tahun; hitungan persisnya tentu bergantung volume OTP Anda.<\/p>\n

Migrasi SMS OTP ke security key: lima tahap yang realistis<\/h2>\n

Migrasi yang gagal biasanya gagal di perencanaan, bukan di teknologi. Kelima tahap berikut disusun untuk organisasi yang aplikasinya sudah, atau akan, terhubung ke identity provider (Entra ID, Okta, Keycloak, atau sejenisnya) yang mendukung WebAuthn.<\/p>\n\n\n\n\n\n\n\n\n\n
Tahap<\/th>\nDurasi tipikal<\/th>\nKeluaran utama<\/th>\n<\/tr>\n<\/thead>\n
1. Inventarisasi titik autentikasi<\/td>\n2\u20134 minggu<\/td>\nDaftar aplikasi, protokol login, dan populasi pengguna per aplikasi<\/td>\n<\/tr>\n
2. Kebijakan dan desain fallback<\/td>\n1\u20132 minggu<\/td>\nKebijakan MFA, urutan prioritas pengguna, prosedur kehilangan kunci<\/td>\n<\/tr>\n
3. Pilot kelompok berisiko tinggi<\/td>\n4\u20136 minggu<\/td>\nBukti kelayakan, daftar hambatan teknis, materi sosialisasi<\/td>\n<\/tr>\n
4. Enrollment massal dua kunci<\/td>\n2\u20133 bulan<\/td>\nSeluruh populasi target terdaftar dengan kunci utama dan cadangan<\/td>\n<\/tr>\n
5. Penonaktifan SMS OTP bertahap<\/td>\n1\u20132 bulan<\/td>\nSMS OTP mati per kelompok, metrik reset dan insiden terpantau<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tahap 1: inventarisasi titik autentikasi<\/h3>\n

Petakan semua tempat SMS OTP dipakai: login karyawan, VPN, approval transaksi, portal nasabah. Catat protokolnya. Aplikasi yang sudah login lewat SAML atau OIDC ke identity provider praktis siap; aplikasi legacy dengan autentikasi lokal butuh jalur federasi dulu. Di rumah sakit, jangan lupakan workstation bersama di ruang perawat, karena pola satu komputer banyak pengguna menentukan pilihan alur login.<\/p>\n

Tahap 2: kebijakan dan desain fallback<\/h3>\n

Putuskan sebelum membeli perangkat: siapa yang wajib pindah lebih dulu, apa cadangan yang sah bila kunci tertinggal, dan bagaimana prosedur kehilangan kunci diverifikasi. Fallback adalah titik terlemah desain ini. Kalau pengguna yang kehilangan security key bisa kembali ke SMS OTP tanpa verifikasi ketat, penyerang tinggal mengaku kehilangan kunci. Praktik yang lebih aman: kunci cadangan yang disimpan terpisah, atau verifikasi identitas tatap muka oleh IT sebelum kredensial diterbitkan ulang.<\/p>\n

Tahap 3: pilot pada kelompok berisiko tinggi<\/h3>\n

Mulai dari akun yang paling menarik bagi penyerang: administrator domain, tim treasury yang menyetujui transfer, operator core banking, staf dengan akses ke data pribadi dalam jumlah besar. Kelompok ini kecil, dampak perlindungannya paling besar, dan hambatan yang mereka temukan (browser lama, aplikasi yang belum bicara WebAuthn, port USB yang dikunci kebijakan endpoint) menjadi daftar pekerjaan sebelum enrollment massal.<\/p>\n

Tahap 4: enrollment massal dengan dua kunci per pengguna<\/h3>\n

Standar yang lazim: setiap pengguna mendaftarkan dua kunci sekaligus, satu dipakai harian, satu disimpan sebagai cadangan. Pilihan bentuknya perlu mengikuti cara orang bekerja, misalnya USB-C untuk laptop baru, NFC untuk pengguna yang sering login dari ponsel, dan seri FIPS untuk lingkungan yang mensyaratkan modul kriptografi tervalidasi FIPS 140-2. Pertimbangan memilih model dan skema pengadaannya kami bahas terpisah di panduan memilih YubiKey untuk perusahaan<\/a>.<\/p>\n

Tahap 5: matikan SMS OTP bertahap dan ukur<\/h3>\n

Selama SMS OTP masih aktif berdampingan, penyerang akan memilih jalur yang lebih lemah. Nonaktifkan per kelompok begitu tingkat enrollment kelompok itu melewati ambang yang Anda tetapkan, lalu pantau tiga metrik: permintaan reset kredensial, tiket helpdesk terkait login, dan insiden pengambilalihan akun. Penurunan angka insiden itulah bukti yang layak dibawa ke rapat manajemen risiko.<\/p>\n

Posisi regulasi: tidak mewajibkan, tetapi mengarah ke sana<\/h2>\n

Perlu jujur di sini: tidak ada regulasi Indonesia yang mewajibkan security key. POJK 11\/POJK.03\/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum mewajibkan bank mengelola risiko TI dan menerapkan pengamanan yang sepadan dengan profil risikonya, tanpa menyebut teknologi autentikasi tertentu. Justru karena pendekatannya berbasis risiko, bank yang masih mengandalkan autentikator berstatus restricted untuk transaksi bernilai tinggi perlu bisa mempertahankan pilihan itu di hadapan penilaian risikonya sendiri. Bagaimana menerjemahkan pendekatan berbasis risiko ini ke arsitektur MFA sudah kami uraikan di artikel MFA berbasis risiko menurut POJK 11\/2022<\/a>.<\/p>\n

Di luar perbankan, PP 71\/2019 mewajibkan penyelenggara sistem elektronik memiliki sistem pengamanan yang layak, dan UU 27\/2022 tentang Pelindungan Data Pribadi menuntut pengendali data mencegah akses tidak sah. Pengambilalihan akun karyawan yang berujung bocornya data pribadi nasabah atau pasien akan dinilai dari sudut itu: apakah kontrol autentikasinya memadai untuk risiko yang sudah diketahui umum. Migrasi ke autentikator tahan phishing adalah salah satu jawaban paling terukur atas pertanyaan tersebut.<\/p>\n

Pertanyaan yang sering diajukan<\/h3>\n

Apakah regulator melarang penggunaan SMS OTP?<\/h3>\n

Tidak. Baik OJK maupun regulasi PDP tidak melarang SMS OTP. Yang ada adalah kewajiban pengamanan berbasis risiko, ditambah status restricted dari NIST SP 800-63B yang meminta organisasi menilai risiko dan menyiapkan alternatif. Keputusan mengganti tetap keputusan manajemen risiko Anda, bukan perintah regulasi.<\/p>\n

Bagaimana jika pengguna kehilangan security key-nya?<\/h3>\n

Di sinilah kebijakan dua kunci berperan: kunci cadangan yang didaftarkan sejak awal membuat kehilangan kunci utama tidak menghentikan pekerjaan. Kunci yang hilang dicabut dari sistem saat itu juga. Bila kedua kunci hilang, penerbitan ulang harus melalui verifikasi identitas yang ketat, bukan jatuh kembali ke SMS OTP tanpa pemeriksaan.<\/p>\n

Apakah aplikasi internal lama bisa langsung memakai security key?<\/h3>\n

Jarang bisa langsung. Jalur umumnya adalah menghubungkan aplikasi ke identity provider lewat SAML atau OIDC, lalu identity provider yang menangani WebAuthn. Aplikasi yang belum bisa difederasikan dapat memakai TOTP dari aplikasi autentikator sebagai jembatan sementara; masih lebih baik daripada SMS, meski belum tahan phishing.<\/p>\n

Berapa lama migrasi biasanya berjalan?<\/h3>\n

Untuk populasi internal beberapa ratus sampai beberapa ribu pengguna, empat sampai enam bulan dari inventarisasi sampai SMS OTP nonaktif adalah rentang yang wajar. Migrasi untuk nasabah atau pengguna eksternal berjalan lebih lama karena melibatkan edukasi dan distribusi perangkat, dan biasanya dimulai dari segmen bernilai transaksi tertinggi.<\/p>\n

Butuh security key hardware untuk organisasi Anda?<\/strong>
Pelajari YubiKey security key resmi dari DTI<\/strong><\/a>.<\/div>\n","protected":false},"excerpt":{"rendered":"

Alasan mengganti SMS OTP dengan security key: SIM swap, status restricted NIST SP 800-63B, biaya per pesan. Plus lima tahap migrasi untuk industri teregulasi.<\/p>\n","protected":false},"author":19941,"featured_media":5506,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"coauthors":[1470],"class_list":["post-5507","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledge"],"_links":{"self":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5507","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/users\/19941"}],"replies":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/comments?post=5507"}],"version-history":[{"count":1,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5507\/revisions"}],"predecessor-version":[{"id":5649,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/posts\/5507\/revisions\/5649"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/media\/5506"}],"wp:attachment":[{"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/media?parent=5507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/categories?post=5507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/tags?post=5507"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/dtisolution.id\/blog\/wp-json\/wp\/v2\/coauthors?post=5507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}