二段階認証を設定しようとすると、「SMSでコードを受け取る」「認証アプリに表示されたコードを入力する」といった選択肢が出てきます。結論から言えば、両方を選べるなら、一般にはSMSより認証アプリを優先するのが安全です。SMSには電話番号を奪われるSIMスワップや、通信経路に依存する弱点があるからです。
ただし、認証アプリも万能ではありません。偽サイトへ自分でコードを入力すれば、その場で盗まれる可能性があります。さらに、古い端末を処分する前の移行や回復コードの保存を忘れると、本人もログインできなくなります。重要なアカウントでは、認証アプリよりさらにフィッシングに強いセキュリティキーやパスキーも候補です。
この記事では、「強い方式を選ぶこと」と「締め出されない準備」を分けて考えます。サービスによって選べる方式や復旧条件は異なるため、実際の設定画面と公式ヘルプも併せて確認してください。
1. 二段階認証が防ぐ被害
パスワードだけのログインでは、攻撃者にパスワードを知られると、それだけで本人としてログインされるおそれがあります。パスワードの使い回し、偽サイトへの入力、端末に保存した情報の流出など、漏れる経路は一つではありません。
二段階認証は、パスワードに加えて、SMSで届くコード、認証アプリが生成するコード、物理的なセキュリティキーなどを要求します。パスワードが「本人だけが知っているもの」、スマートフォンやキーが「本人が持っているもの」として別の要素になれば、多要素認証（MFA）になります。NIST（米国国立標準技術研究所）も、知識・所持・生体という異なる認証要素を示し、同じ種類の要素を二つ重ねるだけでは多要素にならないと説明しています。[1]
そのため、攻撃者が漏えいしたパスワードを入手しても、第二の手段を持っていなければログインを止められる可能性が高まります。二段階認証が特に役立つのは、次のような被害です。
- 別サービスから漏れたパスワードを使う不正ログイン
- 推測されたパスワードによるアカウント乗っ取り
- パスワードを一度見られた後の遠隔ログイン
- 自動化された大量のログイン試行
一方、二段階認証を有効にすれば、端末内のデータ流出、ログイン後の詐欺、悪意あるアプリの操作まで防げるわけではありません。また、パスワードと確認コードの両方をリアルタイムで偽サイトへ入力すると、攻撃者に中継される場合があります。方法ごとの違いは、「第二段階があるか」だけでなく、「コードをどの経路で受け取り、どのサイト向けかを機械的に確認できるか」にあります。
2. SMS認証の仕組みと弱点
SMS認証では、ログイン時にサービスが登録済みの電話番号へ短時間だけ使える確認コードを送ります。利用者は受信したコードをログイン画面へ入力します。専用アプリを追加しなくても始めやすく、機種変更後も同じ電話番号を引き継げれば利用を継続しやすい点が長所です。
しかし、SMSのコードは電話番号と携帯電話網に依存します。FTC（米国連邦取引委員会）は、攻撃者が携帯電話会社をだまして被害者の番号を別のSIMへ移す「SIMスワップ」が成功すると、攻撃者側に通話やSMSが届き、SMSによる多要素認証のコードも受け取られると注意喚起しています。[2] NISTも、SMSや音声通話を含む公衆電話網による認証を制限付きの方式と位置づけ、SIM変更、端末交換、番号移行などの異常を考慮するようサービス提供者へ求めています。[3]
主な弱点を整理すると、次の通りです。
| 弱点 | 起きること | 利用者ができる対策 |
|---|---|---|
| SIMスワップ・番号移行の悪用 | 電話番号が攻撃者のSIMへ移され、コードを受信される | 携帯電話会社の契約者用暗証番号を設定し、不審な圏外や変更通知を見逃さない |
| フィッシング | 偽サイトへ入力したコードを正規サイトへ中継される | メールやSMS内のリンクから入らず、公式アプリや保存したURLから開く |
| 通信への依存 | 圏外、海外滞在、障害、受信遅延でコードが届かない | 別方式と回復コードを事前に登録する |
| 電話番号の再利用・変更 | 古い番号が復旧経路に残る | 番号変更時に全アカウントの登録情報を更新する |
| 画面上の漏えい | ロック画面の通知にコードが表示される | 通知内容を非表示にし、端末ロックを有効にする |
SMSは「危険だから何も設定しない方がよい」という意味ではありません。CISA（米国サイバーセキュリティ・社会基盤安全保障庁）は、認証方法を安全性の高い順に示し、SMSやメールのコードを最も弱い層に置きながらも、強い方式を使えない場合の選択肢として案内しています。[4] 認証アプリやセキュリティキーを選べないサービスでは、SMSを使いつつ、携帯電話会社側の保護と復旧手段を整えるのが現実的です。
3. 認証アプリの仕組みと弱点
認証アプリには複数の方式がありますが、よく使われるのはTOTP（時刻ベースのワンタイムパスワード）です。初期設定時にサービスとアプリが秘密情報を共有し、その後は同じ時刻と秘密情報を使って、双方が一致する短いコードを計算します。IETFのRFC 6238では、標準の時間刻みを30秒とするTOTPの仕組みが定義されています。[5]
この方式では、コード生成のたびにSMSを受信する必要がありません。携帯電話番号を攻撃者へ移されても、認証アプリ内の秘密情報まで自動的に移るわけではないため、SMSが抱えるSIMスワップの影響を受けにくくなります。圏外でも、端末の時刻が適切ならTOTPコードを生成できます。
一方、認証アプリにも次の弱点があります。
- フィッシングには残る：TOTPコードを偽サイトへ入力すれば、有効時間内に攻撃者が正規サイトへ中継できる可能性があります。NISTは、利用者が手入力するOTPをフィッシング耐性のある方式とはみなしません。[3]
- 端末の侵害に弱い：ロックされていない端末を盗まれたり、端末内の秘密情報を読み取る不正ソフトに侵入されたりすれば、コードを生成されるおそれがあります。
- 初期登録用QRコードの保管が危険：QRコードには、将来のコード生成に使う秘密情報が含まれることがあります。スクリーンショットを無防備な写真フォルダや共有クラウドへ残すと、第二の認証器を複製される原因になります。
- 機種変更で詰まることがある：アプリによって、クラウド同期、端末間転送、手動の再登録など移行方法が異なります。同期されると思い込んで旧端末を消去すると、コードを出せなくなる場合があります。
また、「認証アプリ」という名前でも、TOTPコード、承認通知、番号照合など仕組みは同一ではありません。突然届いた承認通知で「許可」を押すだけの方式は、連続通知による誤承認を狙われることがあります。ログイン画面に表示された番号をアプリ側へ入力する番号照合は、単純な承認よりログイン操作との対応を確認しやすい方式です。Microsoftも、番号照合を従来の第二要素通知に対する重要な安全性向上と説明しています。[9] 設定画面ではアプリ名だけで判断せず、コード入力なのか、番号照合なのかを確認しましょう。
比較の中心をまとめると、SMSよりTOTP認証アプリの方が電話番号の乗っ取りに強く、通信圏外でも使いやすい一方、どちらも手入力コードである限りフィッシングへの完全な耐性はありません。
4. セキュリティキーとの違い
セキュリティキーは、USB、NFC（近距離無線通信）などで端末へ接続する物理的な認証器です。FIDO2/WebAuthn対応のキーは、ログイン先の正しいドメインと結びついた暗号処理を行います。W3CのWebAuthn仕様では、公開鍵認証情報は登録先のRP（サービス提供者）に限定され、別のRP IDでは使えないよう設計されています。[8] 偽サイトが見た目をコピーしても、正規サイト向けの認証をそのまま成立させにくいのが、SMSやTOTPコードとの大きな違いです。
NISTはWebAuthnを、認証先の名前に暗号学的に結びつくフィッシング耐性の例として挙げています。[3] CISAも、一般に利用できる方式ではFIDO/WebAuthnをフィッシング耐性のある認証として推奨し、SMS、アプリのOTP、番号照合、セキュリティキーという順で強さが異なることを案内しています。[4]
| 方法 | SIMスワップへの強さ | 偽サイトへの強さ | 通信の条件 | 導入・復旧の要点 |
|---|---|---|---|---|
| SMSコード | 弱い | 弱い | SMS受信が必要 | 始めやすい。電話番号以外の代替手段を用意する |
| TOTP認証アプリ | 比較的強い | 弱い | コード生成は圏外でも可能 | 無料で使える場合が多い。回復コードと移行手順を確認する |
| 番号照合付き通知 | 比較的強い | TOTPより誤承認を減らしやすいが方式依存 | 通信が必要な場合が多い | 通知の番号がログイン画面と一致するか確認する |
| FIDO2セキュリティキー | 強い | 強い | 携帯電話網には依存しない | 対応サービスと端子を確認し、予備キーか回復手段を用意する |
セキュリティキーにも、購入と持ち運び、端子やNFC対応、サービスごとの対応状況という負担があります。一本だけ登録して紛失すれば復旧が難しくなるため、重要アカウントでは予備のキーや別の安全な方式も登録します。端末に内蔵され、同期できる場合もあるパスキーとの関係は、既存記事のパスキーはパスワードより安全？仕組みを解説で詳しく確認できます。
5. 端末紛失時の復旧方法
強い認証を設定しても、復旧経路がSMSだけなら、アカウント全体の安全性はその弱い経路に引っ張られます。反対に、復旧方法を何も用意しなければ、端末の故障や紛失時に本人が締め出されます。認証方法を決めるときは、普段のログインと復旧を一組で設計する必要があります。
設定直後に、次の準備を行います。
- サービスが発行する回復コードを保存する。
- 可能なら予備の認証器を登録する。
- 登録した電話番号とメールアドレスが現在も自分の管理下にあるか確認する。
- 認証アプリの移行・同期方法を公式ヘルプで確認する。
- 旧端末を初期化する前に、新端末で実際にログインできるか試す。
- 紛失した端末やキーをアカウント設定から無効化する手順を把握する。
NISTは、アカウント復旧の代表的な方法として、保存済み回復コード、別経路で発行される回復コード、回復を助ける連絡先、本人確認のやり直しを挙げています。また、保存する回復コードは印刷や書き写しなどでオフラインに保ち、安全に保存することを想定しています。[6]
回復コードは、パスワードと同じ画面、同じ端末、同じ無保護のメモへまとめない方が安全です。紙で保管するなら、自宅内の重要書類と同様に、第三者が簡単に見られず、災害や紛失にも備えられる場所を選びます。デジタルで保管するなら、ロックされたパスワード管理環境など、普段の認証端末を失ってもアクセスできるかまで確認します。
Googleの公式ヘルプでも、主要端末を失った場合の代替として、別のログイン済み端末、追加済み電話番号、事前保存したバックアップコード、登録済みセキュリティキー、別端末のパスキーなどが案内されています。[7] これはGoogleの例であり、利用できる復旧手段や審査期間はサービスごとに異なります。本人確認書類を送れば必ず戻れる、サポートへ連絡すれば解除できる、と決めつけず、設定前に対象サービスの公式手順を確認してください。
6. 用途別の選び方
迷ったときは、「一番強い方式が使えるか」「使い続けられるか」「安全に復旧できるか」の順で選びます。
| 用途 | 推奨する考え方 | 理由 |
|---|---|---|
| メール、パスワード管理、主要クラウド | FIDO2セキュリティキーまたは対応するパスキーを第一候補にする | 他アカウントの復旧起点になりやすく、フィッシング耐性の価値が大きい |
| 金融、決済、行政・業務アカウント | サービスが提供する最も強い方式を選び、公式の復旧条件を確認する | 独自アプリや端末登録を含み、一般的なSMS対アプリだけでは判断できない |
| SNS、通販、一般的なクラウド | 認証アプリを優先し、利用可能ならセキュリティキーやパスキーへ進む | SMSより電話番号乗っ取りの影響を減らせる |
| SMSしか選べないサービス | SMSを有効にし、携帯電話契約の暗証番号と回復手段を整える | 二段階認証なしより防げる攻撃を増やせる |
| 家族や初心者のアカウント | 操作できる強さを選び、回復コードの保管場所と紛失時の連絡手順を共有する | 複雑すぎて無効化したり、復旧できなくなったりする失敗を避ける |
特に優先したいのは、メールとパスワード管理のアカウントです。メールを奪われると、ほかのサービスのパスワード再設定を受け取られる可能性があります。パスワード管理をまだ整えていない場合は、パスワード管理アプリの始め方も併せて確認してください。重要度の高いアカウントから順に強化すれば、すべてを一日で変更する必要はありません。
なお、端末の画面ロック、OSとアプリの更新、異常なログイン通知の確認も必要です。認証アプリを入れたスマートフォン自体が無防備なら、第二段階の価値を下げます。認証コード、回復コード、初期登録用QRコードは、生成AIを含む第三者サービスへ貼り付けないでください。機密情報を外部サービスへ渡す前の判断は、生成AIに入力してはいけない情報と安全な渡し方でも整理しています。
7. 安全に移行する手順
SMSから認証アプリへ移るときは、SMSを先に削除しないことが重要です。新しい方式が正しく動き、復旧手段も確保できた後で、弱い方式を無効にします。
-
公式画面から設定を開く
メールや検索広告のリンクではなく、普段使う公式アプリか、保存済みの正規URLからセキュリティ設定へ入ります。 -
現在の復旧情報を更新する
古い電話番号や使えないメールアドレスを整理します。ただし、代替手段を登録する前に唯一の復旧先を削除しないでください。 -
認証アプリを追加する
公式設定画面が表示したQRコードをアプリで読み取り、確認コードを入力します。QRコードの画像は共有せず、不要なスクリーンショットも残しません。 -
回復コードと予備手段を用意する
回復コードを普段の端末とは別の安全な場所へ保存します。対応していれば、予備端末、予備キー、パスキーなども登録します。 -
別のブラウザで試す
現在ログイン中の画面を残したまま、別ブラウザやプライベートウィンドウでログインし、パスワードと新しい認証方式で入れることを確認します。 -
SMSを無効化できるか確認する
新方式と復旧手段のテスト後、サービスが許すならSMSをログイン手段から外します。認証アプリを追加してもSMSが自動的に解除されないサービスがあります。 -
記録と通知を見直す
どの方式を登録したか、予備手段の保管場所、紛失時の公式窓口を自分用に記録します。ログイン通知と復旧通知を有効にし、不審な変更を早く見つけられるようにします。
最終的な優先順位は、FIDO2セキュリティキーまたは適切に実装されたパスキー、番号照合、TOTP認証アプリ、SMSという考え方が目安です。ただし、サービスの実装、端末、利用者の管理方法によって安全性は変わります。まず二段階認証を有効にし、その後に重要アカウントからフィッシング耐性のある方式へ移すと、締め出しを避けながら段階的に強化できます。
8. よくある質問
SMS認証しか選べない場合は、設定しない方がよいですか？
いいえ。SMSにも弱点はありますが、パスワードだけより防げる不正ログインは増えます。SMSを有効にしたうえで、携帯電話会社の契約者用暗証番号、回復コード、ログイン通知も整え、より強い方式が追加されたら移行を検討してください。
認証アプリを入れれば、SMSはすぐ削除してよいですか？
新しい方式でログインでき、回復コードや予備手段も使えることを確認してから判断します。サービスによってはSMSが唯一の復旧経路になっているため、設定画面と公式ヘルプを先に確認してください。
認証アプリのQRコードは保存してもよいですか？
無防備なスクリーンショットとして残すのは避けます。QRコードに含まれる秘密情報を読み取られると、別端末でも同じコードを生成されるおそれがあります。復旧には、サービスが正式に発行する回復コードや予備の認証器を使います。
機種変更前に何をしておけばよいですか？
認証アプリの公式な移行方法を確認し、回復コードを確保します。旧端末を消去する前に、新端末または別のブラウザで実際にログインできるところまで試してください。
二段階認証のコードを入力したのに不審な画面が出たら？
それ以上入力せず画面を閉じ、保存済みの公式URLや公式アプリから入り直します。パスワードとコードを偽サイトへ入力した可能性がある場合は、正規サイトでパスワード変更、登録済み端末の確認、セッションの終了を行います。見分け方はフィッシングメッセージの確認手順も参考にしてください。
一次情報の確認記録（2026年7月24日確認）
- NIST Digital Identity Model：認証要素と多要素認証の考え方
https://pages.nist.gov/800-63-4/sp800-63/model/ - FTC Consumer Advice「SIM Swap Scams: How to Protect Yourself」：SIMスワップの仕組みとSMS認証への影響
https://consumer.ftc.gov/consumer-alerts/2019/10/sim-swap-scams-how-protect-yourself - NIST SP 800-63B：SMSを含む公衆電話網の制限、OTPのフィッシング耐性、WebAuthn
https://pages.nist.gov/800-63-4/sp800-63b.html - CISA「Require Multifactor Authentication」「More than a Password」：認証方式の強さとFIDO/WebAuthnの推奨
https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication
https://www.cisa.gov/more-password - IETF RFC 6238：TOTPの計算方式と標準の時間刻み
https://www.rfc-editor.org/rfc/rfc6238 - NIST SP 800-63B「Account Recovery」：回復コード、回復連絡先、本人確認による復旧
https://pages.nist.gov/800-63-4/sp800-63b.html#account-recovery - Google Account Help「Fix common issues with 2-Step Verification」：端末紛失時の代替手段
https://support.google.com/accounts/answer/185834 - W3C「Web Authentication: An API for accessing Public Key Credentials - Level 3」：WebAuthn認証情報のRP IDへの限定とオリジン検証
https://www.w3.org/TR/webauthn-3/ - Microsoft Learn「How number matching works in MFA push notifications for Authenticator」：番号照合の仕組みと従来の承認通知からの安全性向上
https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match