多要素認証(MFA)とは？公的ソースから見るメリットや必要性|セキュリティ対策Lab

投稿日時: 2025年03月07日更新日時: 2026年08月02日

多要素認証（MFA）は、いまや追加のセキュリティ機能というより、企業のID防御で最低限そろえておくべき土台になっています。以前は「パスワードにワンタイムパスワードを足す」程度の説明でも十分でしたが、2026年時点では事情が少し変わっています。

Microsoft、Google、CISA、NIST、英国NCSC、Verizon DBIRの資料を並べて見ると、MFAの必要性ははっきりしています。一方で、SMS認証や単純なプッシュ通知だけでは、フィッシングやセッション情報の窃取に対して十分とは言い切れません。これからのMFA導入では、「設定したか」ではなく、「どの方式を、どのアカウントに、どこまで強制しているか」が問われます。

多要素認証（MFA）とは？海外統計から見る必要性と導入時の注意点のサマリー

Microsoftは、侵害されたアカウントの99.9%以上がMFAを利用していなかったと説明しています。
Microsoft関連研究では、MFAにより全体のアカウント侵害リスクが99.22%、漏えい資格情報がある場合でも98.56%低下したとされています。
Google Cloudは2025年中に全ユーザーへMFAを段階的に必須化すると発表しており、クラウド事業者側でもMFA前提の流れが進んでいます。
Verizon DBIR 2026では脆弱性悪用が初期侵入経路として拡大していますが、認証情報の悪用やフィッシングは依然として主要な侵入経路です。
情報システム部門は、管理者、VPN、クラウド、メール、IDプロバイダ、外部委託先アカウントから優先して、耐フィッシングMFAへ移行すべきです。

項目	内容
記事テーマ	多要素認証（MFA）の必要性と導入時の注意点
主な対象	情報システム部門、IT管理者、セキュリティ担当者
注目すべき海外統計	Microsoftの99.9%以上、MFAによる99.22%リスク低減、Verizon DBIRの認証情報悪用データ
推奨される方向性	重要アカウントからFIDO2、WebAuthn、パスキー、証明書ベース認証へ移行
注意点	MFAを有効化するだけでは不十分。SMS、メールOTP、単純なプッシュ通知はフィッシング耐性が低い
情シスの優先領域	特権管理者、Microsoft 365、Google Workspace、VPN、SSO、リモートアクセス、外部委託先ID

多要素認証はパスワードの追加機能ではなく、ID防御の最低ラインです

多要素認証（MFA）とは、パスワードだけに頼らず、複数の認証要素を組み合わせて本人確認を行う仕組みです。一般的には、パスワードやPINのような知識要素、スマートフォンやセキュリティキーのような所有要素、指紋や顔認証のような生体要素を組み合わせます。

昔ながらの説明では、MFAは「パスワードが盗まれても追加の認証で止める仕組み」とされます。これは間違いではありません。ただ、現場で見ていると、MFAは単なるログイン画面の追加機能ではなく、IDを入口にした攻撃の被害範囲を狭めるための基盤です。

特にMicrosoft 365、Google Workspace、Salesforce、Slack、GitHub、VPN、リモートデスクトップ、IDプロバイダの管理者アカウントでは、ログインに成功した時点でメール、ファイル、顧客情報、社内チャット、ソースコード、クラウド環境に一気に到達されることがあります。境界防御だけで守る時代ではなくなった以上、MFAはネットワークの内側に入る前の門番ではなく、業務アプリごとの最後の確認点として考える必要があります。

海外統計が示すMFAの効果

MFAの効果を説明するとき、よく引用されるのがMicrosoftの統計です。Microsoftは、侵害されたアカウントの99.9%以上がMFAを利用していなかったと説明しています。これは「MFAがあれば絶対に侵害されない」という意味ではありませんが、パスワードスプレー、フィッシング、パスワード使い回しに対して、MFAが非常に大きな防壁になることを示しています。

Microsoft Azure Active Directory利用者を対象にした研究でも、MFAを有効化したアカウントの99.99%以上が調査期間中に保護され、MFA導入により全体の侵害リスクが99.22%低下したとされています。漏えいした資格情報がある場合でも、リスク低減は98.56%とされており、これは企業の実務感覚にも近い数字です。パスワードが漏れることをゼロにはできませんが、漏れたパスワードだけで業務アカウントへ入られる状況は、かなり減らせます。

Google Cloudの動きも象徴的です。Google Cloudは、2025年中に全世界のユーザーを対象にMFAを段階的に必須化すると発表しました。Googleは、すでにGoogleサービス全体で2段階認証の利用が広がっているとしつつ、クラウド環境の機密性を踏まえると、全ユーザーへのMFA要求が必要だと説明しています。大手クラウド事業者がMFAを任意設定から必須設定へ寄せている点は、企業の情シス部門にとっても重要です。

一方で、Verizon DBIR 2026では、初期侵入経路として脆弱性悪用が31%に上昇し、認証情報の悪用は13%に低下したとされています。この数字だけを見ると、MFAの重要性が下がったようにも見えますが、そうではありません。DBIR 2025では、侵害済み認証情報の利用が初期侵入経路の22%を占めており、認証情報の使い回し、インフォスティーラー、フィッシングは依然として企業を狙う主要な攻撃経路です。

ここでの見方はシンプルです。MFAは万能薬ではありません。脆弱性管理、EDR、メール防御、ログ監視と組み合わせて初めて効きます。ただし、MFAが弱い組織では、攻撃者に「ログインするだけで入れる入口」を残してしまいます。

MFAの方式ごとの実務評価

MFAと一口に言っても、方式によって強度はかなり違います。SMSのワンタイムパスワード、メールOTP、認証アプリのTOTP、プッシュ通知、番号照合付きプッシュ、FIDO2セキュリティキー、パスキー、証明書ベース認証を同じMFAとして扱うと、導入後に想定外の穴が残ります。

方式	実務上の評価
SMS OTP	導入しやすい一方で、SIMスワップ、端末乗っ取り、フィッシング、通信経路への依存が残ります。高リスク用途では優先度を下げるべきです。
メールOTP	メールアカウント自体が侵害されると意味を失いやすく、業務システムの強い認証としては扱いにくい方式です。
認証アプリのTOTP	SMSよりは扱いやすい場面が多いものの、偽ログイン画面に入力されるとリアルタイムに悪用される可能性があります。
単純なプッシュ通知	利便性は高いものの、MFA疲れ攻撃に弱く、利用者が内容を確認せず承認するリスクがあります。
番号照合付きプッシュ	単純な承認より安全ですが、フィッシング耐性という意味ではFIDO2やパスキーには劣ります。
FIDO2、WebAuthn、セキュリティキー	サービスの正規ドメインと暗号的に結び付くため、耐フィッシング性が高い方式です。管理者や高権限アカウントで優先すべきです。
パスキー	FIDO2を一般利用者向けに扱いやすくした選択肢です。同期型パスキーの運用設計は必要ですが、従来型MFAより強い選択肢になりつつあります。
証明書ベース認証、PIV、CAC	米国政府機関などで用いられる高保証の認証方式です。一般企業では導入負荷がありますが、特権アクセスでは検討余地があります。

CISAは、耐フィッシングMFAとしてFIDO/WebAuthnや証明書ベースの認証を重視しています。さらに、耐フィッシングMFAをすぐ導入できない組織に対しては、プッシュ通知の番号照合を使ってMFA疲れ攻撃を軽減するよう促しています。

英国NCSCも2026年、サービスが対応している場合はパスキーを推奨し、対応していない場合は従来の2段階認証を利用するという方向へ舵を切りました。NCSCは、SMSコード、メールコード、TOTP、プッシュ承認を含む従来型MFAは本質的にフィッシング可能であり、FIDO2やパスキーは一般的な資格情報攻撃に対して従来型MFA以上の強度を持つと評価しています。

2026年の論点は、MFAの有無ではなく耐フィッシング性です

2026年時点で、MFAを導入しているかどうかだけを聞くチェックリストは、少し粗くなっています。情シスの現場では、MFAを有効にしているのに侵害された、という相談が珍しくありません。

典型的なのは、利用者が偽のログインページに誘導され、パスワードだけでなくOTPや承認操作まで攻撃者に渡してしまうケースです。もう一つは、ログイン後に発行されたセッション情報やトークンが窃取されるケースです。Microsoftは、パスワードベースの攻撃が同社で観測する攻撃の99%以上を占める一方、MFAの普及に伴い、攻撃者がトークン窃取やAdversary-in-the-Middle型のフィッシングへ移っていると説明しています。

この流れを踏まえると、管理者や高リスク利用者にSMSや単純なプッシュ通知だけを使わせ続けるのは、だんだん説明しにくくなっています。NIST SP 800-63B-4でも、AAL2では2つの異なる認証要素が必要とされ、フィッシング耐性のある認証オプションを提供することが求められています。WebAuthnやFIDO2は、認証先ドメインと暗号的に結び付くため、攻撃者が偽サイトで認証情報を中継する攻撃に対して強い構造を持ちます。

自分の感覚としても、すべての社員にいきなり物理セキュリティキーを配る必要はありません。ただ、管理者、経理、役員秘書、開発者、クラウド管理者、外部委託先の運用アカウントについては、従来型MFAのまま放置する理由が弱くなってきています。

MFAが効かなくなる運用上の穴

MFAの失敗は、技術そのものより運用の隙間から起きることが多いです。たとえば、管理者にはMFAを強制しているのに、緊急用アカウントや古いサービスアカウントだけ例外になっているケースがあります。攻撃者は正面玄関ではなく、こうした例外を探します。

リモートアクセスも注意が必要です。VPN、VDI、RDPゲートウェイ、SaaS管理画面、クラウドコンソールのうち、どこか1つでもパスワードだけでログインできれば、そこが入口になります。メールだけMFAを入れて安心するのではなく、SSOの外側に残っている個別ログインを洗い出すことが必要です。

復旧手順も見落とされがちです。MFAデバイスを紛失したとき、本人確認が甘いままMFAを解除できる運用だと、攻撃者にとってはそこが抜け道になります。ヘルプデスクが急かされてMFAをリセットしてしまう、本人確認をメールだけで済ませる、退職者や委託先の認証情報が残る、といった運用は、技術的に強いMFAを入れていても台無しにします。

ログ監視も同じです。MFA成功ログだけを見ていると、攻撃に気づけない場合があります。短時間の失敗増加、通常と異なる国や端末からの認証、MFA登録情報の追加、条件付きアクセスの失敗、トークン再利用の疑い、OAuthアプリの同意など、ID周辺のイベントをまとめて見る必要があります。

セキュリティ対策Lab既報から見るMFA導入の優先度

セキュリティ対策Labでは、MFAに関連する解説を複数掲載してきました。たとえば、Microsoftの研究を扱った多要素認証で約99%のセキュリティリスクを削減できる Microsoftが発表では、MFAによる侵害リスク低減の数値を紹介しています。

基礎的な違いを押さえるなら、二要素認証とは多要素認証との違いを解説が入口になります。現場では2段階認証、2FA、MFAが混同されやすいので、調達要件や社内規程では「異なる認証要素を組み合わせるのか」「単なる2ステップなのか」を明確にしておくべきです。

認証方式の個別論点では、ワンタイムパスワード(OTP)とは？種類・メリット・注意点をわかりやすく解説や、パスキーとは？メリットや概要を解説が関連します。OTPは導入しやすい一方、フィッシング耐性には限界があります。パスキーは導入設計に注意が必要ですが、ID防御の方向性としては明らかに重みが増しています。

クラウド側の動きとしては、Google Cloudが2025年に多要素認証(MFA)を必須にも重要です。自社が使うSaaSやクラウドがMFA必須へ向かっている以上、情シス側も「利用者に任せる設定」ではなく、「組織として強制する設定」に移行する必要があります。

これらの既報をつなげて見ると、MFAの議論は、パスワード対策からID基盤対策へ移っています。単にOTPを入れたかではなく、SSO、条件付きアクセス、端末準拠、権限管理、ログ監視まで含めて設計する段階です。

導入時に確認したい実務チェックポイント

MFAを入れる際は、全社員一斉導入だけを考えると失敗しやすくなります。優先順位を付けるなら、最初は特権管理者、役員、経理、人事、開発者、クラウド管理者、外部公開システムの管理アカウントです。ここをFIDO2、パスキー、証明書ベース認証などの強い方式へ寄せるだけでも、リスクはかなり下がります。

次に、MFAがかかっていない認証経路を洗い出します。Microsoft 365やGoogle Workspaceだけでなく、VPN、IdPの管理画面、SaaSのローカルアカウント、古いメールプロトコル、APIトークン、共有アカウント、外部委託先のアカウントも対象です。MFAが有効でも、古い認証プロトコルや例外ポリシーが残っていると、攻撃者はそこを使います。

方式の選定では、SMS OTPを最後の手段に下げ、TOTPや番号照合付きプッシュを中間策、FIDO2やパスキーを本命として位置付けるのが現実的です。すべてを一度に移行できない場合でも、管理者から耐フィッシングMFAへ移し、一般利用者は段階的に移行する形で十分に始められます。

復旧手順は、MFA導入と同じタイミングで見直すべきです。スマートフォンを紛失した、端末を交換した、退職者から引き継いだ、委託先担当者が変わった、といった場面で、誰が、何を確認し、どのログを残すのかを決めておきます。ここが曖昧だと、MFA解除の運用が攻撃者に悪用されます。