パスワードが漏れても、それだけではログインできないようにする仕組みが二要素認証（2FA）です。混同されがちな2段階認証との違いと、方式ごとの強弱を整理します（攻撃手順は載せません）。
「2要素」と「2段階」の違い
言葉が似ていて混同されますが、狙いを押さえると簡単です。認証の“要素”は次の3カテゴリに分かれます。
**二要素認証（2FA）**は、この異なるカテゴリを2種類混ぜます（例：パスワード＝知識＋スマホの認証アプリ＝所持）。狙いは「1つが破られても、別カテゴリが残るので突破されない」こと。
対して2段階認証（2SV）は「2回確認する」だけの意味で、両方が同じカテゴリでも成立してしまいます（パスワード＋秘密の質問はどちらも知識＝2段階だが2要素ではない）。だから本当に強くしたいなら、別カテゴリを混ぜることが大切です。
方式の強弱：偽サイトに入力すると盗まれるかどうかで決まる
2FAを入れても、方式によって強さは大きく変わります。決め手は「偽サイトにうっかり“証明”を渡してしまえるか」です。
強 ── パスキー / 物理キー（FIDO2）
署名がドメインに紐づく＝偽サイトに原理的に出せない（フィッシング耐性）
中 ── 認証アプリ（TOTP）
SMSより強いが、コードを人が読む＝偽サイトには渡せてしまう
弱 ── SMS / メールのコード
手入力コードにはフィッシングのリスク。SMSには電話番号乗っ取りのリスクもある
弱い：SMS / メールのコード
- コードを人が読んで打ち込む＝偽サイトにそのまま渡せてしまう
- SIMスワップはSMSや音声の受信先となる電話番号を狙います。メールのコードはメールボックスと復旧手段の保護が重要で、どちらの手入力コードにもフィッシングのリスクがあります
- それでもパスワードだけよりは確実に強い（入れないよりずっと良い）
強い：パスキー / 物理キー（FIDO2）
- 署名がサイトのドメインに紐づく＝偽サイトには原理的に出せない
- パスキーやキー単独でMFAとして使うには、サービスがPIN・生体認証などの利用者確認を要求し、結果を検証する必要があります。キーとパスワードを併用する構成もあり、タッチだけでは第2の要素になりません
- 認証アプリ（TOTP）はその中間＝SMSより強いが偽サイトには出せてしまう
2FA・2段階認証・MFA・OTP・パスキーの違い
似た言葉が多いのは、「考え方」を表す言葉と「方式」を表す言葉が混ざっているためです。
| 言葉 | 何を指すか | 例 |
|---|---|---|
| 二要素認証（2FA） | 種類の違う証明を2つ組み合わせる考え方 | パスワード＋認証アプリのコード |
| 多要素認証（MFA） | 種類の違う証明を2つ以上組み合わせる考え方（2FAを含む） | パスワード＋認証アプリのコード、サービスが利用者確認を要求・検証するパスキー |
| 2段階認証（2SV） | 確認を2回行うこと（種類が同じでもよい） | パスワード＋秘密の質問 |
| ワンタイムパスワード（OTP） | 2つ目の証明に使われる、使い捨てのコード | 認証アプリ・SMS・メールのコード |
| パスキー | 端末の秘密鍵で署名するログイン方式 | 指紋や顔でロックを解除してログイン |
2FAとMFAは「何を満たせばよいか」を、OTPとパスキーは「どうやって満たすか」を表しています。コードの仕組みは ワンタイムパスワード（OTP）とは、署名の仕組みは パスキーとは で解説しています。サービスの画面で「2段階認証」と書かれていても、中身はパスワード＋認証アプリのような2FAであることが多いので、実際の方式を見て判断します。
2FAでどれだけ防げるか
Microsoftの研究者が同社のクラウドの利用者を分析した2023年の研究では、MFAを有効にしたアカウントは、乗っ取られる危険が全体で99.22%、漏えいした認証情報が使われた場合でも98.56%下がっていました。パスワードの使い回しや漏えいによる乗っ取りの大半は、どの方式であれ2FAを入れるだけで止まります。
一方で、2FAでも防げないものがあります。
- 偽サイトへの入力：SMSや認証アプリのコードは、偽サイトに入力すると本物へ中継されます。防げるのはパスキーや物理キーです
- 弱い復旧手段：SMSや登録メールだけでアカウントを戻せるなら、そこが入口になります
- 2FAのないアカウント：2FAを入れていない社用メールや外部サービスのアカウントから入られれば、ほかの対策は効きません
具体例：2FAがなかった決済アプリと、必須化の流れ
2019年の決済サービス「7pay」では、不正アクセスに伴う被害が発生しました。運営グループの8月1日発表によると、被害は7月31日17時時点で808人・38,615,473円で、不正チャージと不正利用を含みます。同社はリスト型攻撃の可能性が高いとし、追加認証等の検討が十分でなかったことが防御力を弱めたと説明しました。一方、再設定等が直接原因になった事例は、その時点では見つかっていないとしています（当時の公式説明、公表事実と対策の整理）。原因の評価と、一般的に再設定を安全に設計する必要性は区別します。
その後、2FAを利用者任せにせず、必須にするサービスが増えています。GitHubは2023年3月から、コードを公開・投稿するユーザーに段階的に2FAを必須化しました（設定は GitHubの2段階認証の設定）。2026年8月に国内で公表された主な事案を当サイトで分類すると、脆弱性を突かれたものより、委託先のMicrosoft 365や社用メール、GitHubの認証情報など、正規の認証情報で入られたもののほうが多くなりました（2026年の国内情報漏えいの侵入経路）。
自分のアカウントで確認する方法
守る順番を決める
最初はメールとパスワードマネージャー。この2つは、ほかのアカウントのパスワード再設定や管理に使われるからだ。次にドメイン・クラウド・GitHub、そして銀行・証券・決済の順に進める。
各アカウントの2FAの方式を確かめる
セキュリティ設定で、2FAが有効か、どの方式かを見る。SMSやメールのコードなら、認証アプリかパスキーを追加して優先にする。選び方は 多要素認証（MFA）の選び方 で比較している。
リカバリーコードと2つ目の方法を用意する
リカバリーコードはパスワードマネージャーなどスマホとは別の場所に保存する。予備のパスキーや物理キーなど、2つ目の方法も登録しておく。
復旧用のメールと電話番号を見直す
登録された復旧用メールアドレスと電話番号が今も自分のものか、そのメールアカウント自体に2FAがかかっているかを確認する。パスワードがすでに漏れていないかは パスワードが漏れていないか確認する方法 で調べられる。
管理する側は、2FAを必須にする
社内のメール・GitHubの組織・クラウドの管理画面では、2FAを各自の任意にせず、組織の設定で必須にする。管理者アカウントには、パスキーか物理キーを求める。
当サイトの視点：まず導入し、次にフィッシングで盗まれない方式へ
2FAで最も多い失敗は「どれが最強か」を考えすぎて、結局どれも入れないことです。優先順位ははっきりしています。まず全アカウントで何らかの2FAを有効化し、そのうえでメール・ドメイン・決済といった重要なアカウントから順に、フィッシングに出せない方式（パスキー）へ切り替えます。
当サイトは「注意力で偽サイトを見破る」ことを防御戦略に数えません。人の注意力ではなく、仕組みとして偽サイトに証明を出せない方式に切り替えるのが正しい方向です。
出典（一次情報）
- NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」（2025年7月） — pages.nist.gov（認証の要素、フィッシング耐性、電話網を使う方式は制限付き）
- Meyer ほか「How effective is multifactor authentication at deterring cyberattacks?」（Microsoft、2023年） — arxiv.org（MFAで乗っ取りの危険が99.22%、漏えいした認証情報の場合で98.56%低下）
- CISA「Implementing Phishing-Resistant MFA」（2022年10月） — cisa.gov（PDF）（方式を強い順に並べた表、SMSを狙うSIMスワップ）
- GitHub Docs「必須の 2 要素認証について」 — docs.github.com（2023年3月からの段階的な必須化）
- 運営グループ「7payサービス廃止とこれまでの経緯」（2019年8月1日） — 被害の集計時点・原因評価・追加認証の説明
次に読む
- GitHub の設定：GitHub の2段階認証（2FA）の設定方法
- 用語：ワンタイムパスワード（OTP）とは（認証アプリのコードの仕組み・TOTP/HOTP/SMS）／ パスキーとは（フィッシングで盗まれない最も強い方式）
- 用語：フィッシングとは（2FAを狙う中間者型AiTMの理解）
- 入門：多要素認証（MFA）の選び方（方式の選定を実務で）
- 事例：7pay 不正利用事件（2019）（追加認証と復旧を公表事実から考える）