SMS認証は安全？企業が確認したいリスク・対策・使い分け

パスワードと組み合わせたSMS認証は、パスワードだけで認証するよりも防御層を増やしやすい一方、すべての場面で十分な安全性を確保できるわけではありません。リアルタイムフィッシングやSIMスワップなどにより、認証コードを第三者に取得されるリスクがあります。

会員登録時の電話番号確認や通常ログインの追加認証には導入しやすい方法です。一方、高額決済、アカウント復旧、管理者権限の変更などでは、SMSだけに依存しない設計が必要です。電話番号への依存を減らす場合は認証アプリを検討し、影響の大きい操作では、パスキーなどフィッシング耐性を備えた方式を優先します。

この記事では、SMS認証の安全性、主なリスク、企業側で実施したい対策、他の認証方式との違い、導入・運用時の確認項目を整理します。

SMS認証は安全？二要素認証として使う場合の考え方

SMS認証は、パスワードだけの認証より防御層を増やせますが、フィッシングやSIMスワップに対して十分な耐性を備えた認証方式ではありません。安全性は、組み合わせる認証要素と利用する操作のリスクによって判断します。

SMS認証とは、登録された電話番号へ認証コード（OTP／ワンタイムパスワード）を送り、利用者がそのコードを入力する認証方法です。確認できるのは、利用者がその時点でSMSを受信できる電話番号を利用していることです。氏名や住所などを照合する本人確認とは役割が異なります。

また、SMS認証だけで二要素認証になるとは限りません。パスワードなどの知識要素と、登録済みの電話番号で受け取る認証コードを組み合わせる場合に、SMSを使った二要素認証として機能します。単に認証を複数の段階で行う方式と、異なる種類の認証要素を組み合わせる多要素認証は、同じ意味ではありません。認証要素の考え方は、IPAの多要素認証に関する説明でも確認できます。

SMS認証が現在も使われている理由は、専用アプリのインストールを前提とせず、幅広い利用者に案内しやすいためです。既存の登録・ログイン画面にも組み込みやすく、電話番号を基に追加認証を始めたい企業にとって現実的な選択肢になります。

SMS認証の基本的な仕組みや導入方法を詳しく確認したい方は、SMS認証のやり方・仕組み・導入ポイントをご覧ください。電話番号認証サービスの選び方は、電話番号認証サービスの仕組み・機能・選び方で整理しています。

SMS認証の主なセキュリティリスク

SMS認証のリスクは、認証コードが届かないといった運用上の問題と、認証コードを攻撃者に取得されるセキュリティ上の問題に分けて考える必要があります。ここでは、認証を突破される原因になり得る主なリスクを確認します。

リアルタイムフィッシング

攻撃者が正規サイトに似せた偽サイトへ利用者を誘導し、ID・パスワードと認証コードを入力させる手口です。取得した認証コードを有効期限内に正規サイトへ転送すると、SMS二要素認証でも不正ログインを許してしまう可能性があります。

IPAは、ワンタイムパスワードをその場で正規サイトへ転送するリアルタイムフィッシングに注意を呼びかけています。手入力型のOTPは、SMSでも認証アプリでも、利用者が偽サイトへ入力すると攻撃者に利用される可能性があります。詳しくは、IPAによるリアルタイムフィッシングの解説をご確認ください。

SIMスワップ

SIMスワップは、攻撃者が通信事業者の手続きなどを悪用し、被害者の電話番号を攻撃者側のSIMや端末へ移す手口です。電話番号を乗っ取られると、正規ユーザー向けの認証コードが第三者へ届く可能性があります。

SMSの通信経路や端末からコードが漏れるリスク

SMSは通信事業者のネットワークを経由して端末へ届きます。通信経路の不正利用、端末上の悪意あるアプリ、第三者による端末操作などにより、認証コードを取得される可能性があります。

SMSにはパスキーのようなフィッシング耐性はなく、通信事業者のネットワークにも依存します。

通知画面から認証コードを見られるリスク

端末のロック画面に認証コードの全文を表示すると、端末を操作できない第三者にもコードを見られるおそれがあります。

SMS認証の安全性を高めるための対策

SMS認証を利用する場合は、コードを送るだけでなく、発行、入力、再送、電話番号変更、アカウント復旧まで含めて認証フローを設計します。企業側で確認したい主な対策は次のとおりです。

• 認証コードの有効期限を設定する： 利用者が操作を完了できる範囲で有効期限を短くし、古いコードを長時間使える状態にしない
• 認証コードを一度だけ使用できるようにする： 検証に成功したコードを再利用できないようにし、同じコードの使い回しを防ぐ
• 入力試行回数を自社システム側で制限する： 認証コードの入力失敗が続いた場合は一時的に停止し、コードを再発行しても不正試行が無条件に続かないようにする
• 送信・再送リクエストを制御する： 同じ電話番号やIPアドレスから短時間に大量のコードを要求できないようにし、不正利用や過剰送信を抑える
• 電話番号変更とアカウント復旧を分けて設計する： 端末変更、SIM変更、番号移転の兆候がある場合もSMSだけに依存せず、既存の認証手段や別の確認方法を組み合わせる
• 高リスク操作では別方式を追加する： 高額決済や管理者操作では、パスキーなどフィッシング耐性を備えた方式を優先して検討する

認証コードの有効期限、再利用防止、入力試行回数の制限、電話番号変更を新しい認証手段の登録として扱う考え方は、NIST SP 800-63B（英語）に示されています。アカウント復旧も通常のログインとは分けて設計します。

利用者への案内も必要です。認証コードをロック画面に表示しない設定を案内し、企業やサポート担当者が認証コードを尋ねることはないと明示します。偽サイトや偽サポートへコードを入力・共有しないよう注意を促します。

SMS認証が向いている場面・他の認証方式を検討したい場面

SMS認証を採用するかどうかは、操作に伴うリスク、利用者が準備できる端末や認証方法、認証に失敗した場合の影響から判断します。

SMS認証・認証アプリ・パスキーの違い

認証方法は、導入しやすさだけでなく、利用者側の準備、携帯電話回線や電話番号への依存、フィッシングへの耐性を同じ軸で比較します。ここでいう認証アプリ（TOTP）は、端末上で時間ベースの認証コードを生成する方式です。

認証アプリ（TOTP）はSMSの受信環境や電話番号に依存しないため、SIMスワップやSMS通信経路に起因するリスクを避けられます。一方、利用者がコードを手入力する方式では、偽サイトへコードを入力するとリアルタイムフィッシングに利用される可能性があります。

パスキーは、認証情報を正規サイトのドメインに結び付ける仕組みにより、フィッシング耐性を備えています。ただし、対応端末、既存システムとの連携、アカウント復旧方法も含めて導入可否を判断します。IPAの案内は、IPAのパスキー利用に関する案内で確認できます。

SMS認証を導入・運用するときの確認項目

SMS認証を導入する際は、コードを送信できるかだけでなく、認証が完了しない場合の処理や、不正な送信・入力を抑える仕組みまで確認します。

• 到達性と配信速度： 対象とする国・地域や通信環境で、認証コードを安定して届けられるか
• APIと実装方法： 送信結果と検証結果を自社の登録・ログイン・取引フローへ連携できるか
• OTPの有効期限と再利用防止： 用途に合った期限と一度限りの利用を設定できるか
• 入力試行回数の制御： 自社システム側で連続した入力失敗を制限できるか
• 送信・再送リクエストの制御： 同一番号やIPからの過剰な要求を制限できるか
• 不達時の導線： 再送、補助チャネル、問い合わせ先など、利用者が次に取る行動を用意しているか
• 状態確認： 送信、到達、検証成功・失敗、タイムアウトなどの結果を確認できるか
• 運用体制： 障害や不正利用が発生した際の停止手順、担当者、サポート窓口が決まっているか

配信遅延や不達は、認証強度とは別の運用課題です。コードが届かなければ、ログインや会員登録が完了せず、途中離脱や問い合わせの増加につながります。正常系だけでなく、遅延、不達、コード期限切れ、入力失敗を含めてテストしておく必要があります。

EngageLab OTPでSMS認証を導入・運用する

EngageLab OTPは、OTPの送信・検証、状態連携、SMS送信リクエストの頻度制限に対応しています。検証結果を受けてログインや取引を許可するかどうかは、企業側のシステムで、自社のリスク基準に基づいて判断します。

送信・検証と状態確認

OTP送信APIを利用すると、テンプレートに設定した送信チャネルに従って認証コードを送信し、後続の検証に使うmessage_idを取得できます。検証APIでは、利用者が入力したコードとmessage_idを照合します。検証に成功したコードは再度利用できません。

テンプレートごとに認証コードの有効期限を設定でき、ライフサイクルコールバックを利用すると、送信・送信失敗、到達・到達失敗、検証済みなどの状態を自社システムへ連携できます。

SMS OTPでは、同一の電話番号やIPアドレスからの送信リクエストに頻度制限を設定できます。認証コードの入力試行回数は、利用するログインや取引システム側で制御します。

実装方法は、OTP送信APIとOTP検証APIをご覧ください。送信・送信失敗、到達・到達失敗、検証済みなどの状態は、ライフサイクルステータスコールバックで確認できます。

認証コードの有効期限と送信チャネルは、テンプレート管理で設定します。送信リクエストの頻度制限や国・地域の設定は、OTPセキュリティセンターで確認できます。

不達時の補助チャネル

電話番号を使うテンプレートでは、SMS、WhatsApp、Voiceから主送信チャネルと最大2つの補助チャネルを設定できます。主チャネルで送信できない場合は、設定した順序に従って別のチャネルへ切り替わります。Emailは電話番号チャネルのフォールバックではなく、独立した送信戦略として設定します。

補助チャネルは、主チャネルで送信できない場合に別の送信経路へ切り替える仕組みです。リアルタイムフィッシングやSIMスワップに対する認証強度を高めるものではありません。高リスク操作に必要な認証方式は、補助チャネルとは分けて判断します。

詳しくは、EngageLab OTPサービスをご覧ください。

FAQ

SMS認証だけで二要素認証になりますか？

パスワードなどの知識要素と、登録済み電話番号で受け取る認証コードを組み合わせる場合に、二要素認証として機能します。

SMS認証コードが届かない場合、企業は何を準備すべきですか？

再送までの待ち時間、送信回数の上限、補助チャネル、問い合わせ先をあらかじめ決めておきます。コードが届かない利用者を無条件に別番号へ切り替えるのではなく、電話番号変更やアカウント復旧に該当する場合は別の確認方法を組み合わせます。

まとめ

SMS認証は、幅広い利用者へ追加認証を提供しやすく、パスワードだけの認証を補強できる方法です。一方で、リアルタイムフィッシングやSIMスワップなどのリスクがあるため、すべての操作に同じ認証方法を適用するのは適切ではありません。

企業は、操作に伴うリスク、利用者が準備できる認証方法、不達時の影響を整理し、SMSで十分な場面と、認証アプリやパスキーなどを組み合わせる場面を分けて設計する必要があります。

SMS OTPの送信・検証方法や、不達時の補助チャネルを含む運用設計を確認したい場合は、EngageLabへご相談ください。