クラウドSaaSの利用拡大とリモートワークの定着で、ID／パスワードだけの認証では守りきれない時代になりました。フィッシング・パスワードリスト型攻撃・退職者アカウントの悪用といった脅威に対し、最初に打つべき対策がMFA（多要素認証）です。

「MFAを入れたほうがいい」という認識はあっても、要素の組み合わせや製品選定、ユーザー体験への影響が見えず、導入が止まっている情シスも少なくありません。

本記事ではMFAの仕組みを認証要素の3分類から噛み砕き、SSO／IDaaSとの関係、導入手順、ユーザー体験への配慮、製品選定の観点までを情シスがそのまま設計に使える形で整理します。

MFA導入や見直しを検討している情報システム部門・セキュリティ責任者を主な読者として想定しています。

先に結論をまとめます。時間がない方はここだけ読めば全体像がつかめます。

以降では、この6行それぞれの根拠と設計上の判断ポイントを順に掘り下げます。

MFA（多要素認証）とは

MFA（Multi-Factor Authentication、多要素認証）は、ログイン時に2つ以上の異なる種類の認証要素を要求する認証方式です。パスワード単独の認証ではなく、スマートフォンの認証アプリや生体認証など複数の要素を組み合わせて本人性を確認します

パスワードが漏れても、攻撃者は「本人が持っているもの」または「本人自身の身体的特徴」を同時に用意できません。この非対称性がMFAの効果の源です。逆に言えば、2つの要素が同じ原理で破られる組み合わせ（たとえばパスワードと秘密の質問）はMFAの効果を持ちません。

認証の3要素

MFAで使われる認証要素は「知識（Something you know）」「所持（Something you have）」「生体（Something you are）」の3種類に分類されます。

知識はパスワード・PIN・秘密の質問など本人だけが知っている情報、所持はスマートフォン・ハードウェアトークン・ICカードなど本人だけが持っている物、生体は指紋・顔・虹彩など本人固有の身体的特徴です。

3要素の対応関係と、それぞれが抱える弱点を整理すると次のとおりです。

MFAの設計とは、この表の「弱点」が互いに重ならないように要素を選ぶ作業だと言い換えられます。パスワード（知識）と認証アプリ（所持）の組み合わせが標準解になっているのは、漏洩経路が重ならないためです。

2段階認証との違い

2段階認証（2SV）は「同じ要素を2回求める」場合も含む広い概念で、たとえばパスワード＋秘密の質問は2段階認証ですがMFAではありません。MFAは異なる種類の要素を組み合わせる点が本質的な違いです。

MFAの正式名称と表記のバリエーション

MFAは multi-factor authentication の略で、日本語では「多要素認証」と訳されます。読み方は「エムエフエー」です。社内資料や製品ドキュメントでは次のような表記が混在するため、用語の関係を先に押さえておくと混乱を避けられます。

海外ベンダーの管理コンソールでは MFA、Multi-Factor Authentication、Two-Step Verification が同じ設定項目を指していることが少なくありません。社内規程を書く際は「異なる2分類以上の要素を要求する」という定義を明文化しておくと、製品を乗り換えても規程を書き直す必要がなくなります。

MFAが2026年に事実上の必須要件になった理由

MFAは「推奨される対策」から「前提として設定されているもの」へと位置づけが変わりました。理由は3つあります。

1つ目は、クラウド事業者側が強制を始めたことです。Microsoftは2024年10月からAzureポータル・Microsoft Entra管理センター・Microsoft Intune管理センターへのサインインにMFAを必須化し、2025年2月からMicrosoft 365管理センターへ、2025年10月1日からはAzure CLI・Azure PowerShell・REST APIなどのクライアントへ順次適用しています。準備期間の延期申請にも2026年7月1日という期限が設けられており、オプトアウトの手段はありません。

2つ目は、脅威の実態です。IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の1位が「ランサム攻撃による被害」、2位が「サプライチェーンや委託先を狙った攻撃」、3位に初選出の「AIの利用をめぐるサイバーリスク」となっています。侵入の起点として認証情報の窃取が使われる構図は変わっておらず、認証の強度がそのまま被害の分岐点になります。

3つ目は、監査要件です。ISMS・SOC2・PCI DSSといった枠組みで、管理者権限を持つアカウントへのMFAは実質的に必須項目として扱われます。「入れていない理由」を説明するコストのほうが高くなっている状況です。

参考：必須の Microsoft Entra 多要素認証 (MFA) を計画する - Microsoft Learn 参考：情報セキュリティ10大脅威 2026 - 情報処理推進機構（IPA）

参考：不正ログイン対策特集ページ - 情報処理推進機構（IPA）

MFAの主な認証方式

MFAで使われる「2つ目の要素」には複数の選択肢があります。セキュリティ強度・ユーザー体験・コストのバランスを見て、組織と用途に合わせて選定します。

SMS認証

携帯電話番号にSMSでワンタイムコードを送る方式。導入が容易な反面、SIMスワップ攻撃やフィッシングに脆弱なため、近年は推奨度が下がっています。NIST SP 800-63B（Revision 3）では、公衆交換電話網（PSTN）を使った帯域外認証を「RESTRICTED（制限付き）」と分類しています。使用を禁じているわけではなく、リスクを評価・記録したうえで、利用者に制限のない代替手段とリスクの説明を提供することを求めるという位置づけです。つまりSMS認証は「使ってはいけない」ではなく「使うなら移行計画とセットで」という扱いになります。

認証アプリ（TOTP）

Microsoft Authenticator、Google Authenticator、Authyなどのアプリで30秒ごとに変わる6桁コードを生成する方式。SMSより安全でコストも低く、現在の主流です。仕組みはRFC 6238で標準化されているため、特定ベンダーに縛られず相互運用できる点も実務上の利点です。

プッシュ通知

認証アプリへ「ログインしますか？」のプッシュ通知を送り、タップで承認する方式。ユーザー体験が良好な一方、MFA疲労攻撃（連続プッシュで誤承認を誘う）への対策として番号一致機能が必須です。Microsoft Authenticatorではすべてのプッシュ通知で番号照合が有効になっており、ユーザー側でオプトアウトすることはできません。他社製品を使う場合は、同等の機能が既定で有効かどうかを設定画面で確認してください。

FIDO2／パスキー

物理キー（YubiKeyなど）またはデバイス内蔵の生体認証で公開鍵暗号方式の認証を行う方式。フィッシング耐性を持つ最強のMFAで、Microsoft・Google・Appleが大規模に推進しています。秘密鍵が認証器の外へ出ず、認証の対象となるドメインが鍵に紐づくため、偽サイトへ認証情報を渡すことが原理的にできません。

生体認証

Windows Hello、Touch ID、Face IDなどデバイス側の生体認証を使う方式。FIDO2と組み合わせて使われるケースが多く、ユーザー体験を犠牲にせず強度を上げられます。

認証方式の選び方（対象別の推奨組み合わせ）

方式ごとの特性を並べると、どの対象にどれを割り当てるかの判断がつきます。

実務上は「一般従業員はプッシュ通知（番号照合あり）＋会社管理端末のデバイス条件、特権アカウントはFIDO2セキュリティキー必須」という2段構成から始めるのが現実的です。全員を一度にFIDO2へ寄せようとすると、認証器の調達と登録支援で情シスの工数が破綻します。

なお、緊急用アカウント（ブレークグラスアカウント）にもMFAは必要です。Microsoftはこの用途にパスキー（FIDO2）または証明書ベース認証の利用を推奨しています。スマートフォン依存の方式だけで設計すると、障害時に誰も入れなくなるという事故が起こります。

参考：FIDO2／パスキーとは - FIDOアライアンス 参考：NIST SP 800-63B Authentication and Lifecycle Management

MFAとSSO・IDaaSの関係

MFAはSSOやIDaaSと組み合わせることで真価を発揮します。認証ポイントをIdPに集約し、そこにMFAを必須化することで、全SaaSの強度を一気に底上げできる構造です。

SSOにMFAを必須化する意味

SSOは「1度の認証で複数SaaSを使える」仕組みなので、IdPへの認証が破られると全SaaSが侵入されます。だからこそIdPの認証にMFAを必須化することで、認証ポイントの単一化リスクを補強します。SSO自体の仕組みや認証方式の違いはSSO（シングルサインオン）とはで整理しています。

IDaaS提供のMFA機能

Microsoft Entra ID、Okta、Google Workspace、HENNGE OneなどのIDaaSは標準でMFA機能を提供します。条件付きアクセスと組み合わせて、デバイス・場所・リスクスコアに応じた段階的なMFA要求も実現できます。IDaaSという製品カテゴリ自体の位置づけはIDaaSとは、Microsoft環境の具体的な設計はEntra IDとはを参照してください。

条件付きアクセスとリスクベース認証

「未管理デバイスからのアクセス時のみMFA」「海外IPからのアクセス時のみFIDO2」など、リスクスコアに応じてMFA要求を出し分ける運用が現実解です。ユーザー体験とセキュリティのバランスを取れる設計が可能になります。

MFAとゼロトラストの関係

ゼロトラストは「社内ネットワークだからといって信頼しない」という考え方で、アクセスのたびに主体・デバイス・コンテキストを検証します。MFAはこのうち「主体が本人かどうか」を検証する部品にあたり、ゼロトラスト構成の入口を担います

ただしMFAだけではゼロトラストになりません。認証が通った後にどの権限で何にアクセスできるかを制御する仕組み（最小権限の設計とアクセス権限の棚卸し）が伴わないと、乗っ取られなかったアカウントが持つ過剰な権限がそのまま残ります。考え方の全体像はゼロトラストセキュリティとは、権限側の運用はアクセス権限管理の方法で解説しています。

ジョーシスのプラットフォームを使えば、IDaaSのMFA運用とSaaSアカウント管理を統合できます。資料ダウンロードは5分でわかるJosysからどうぞ。

MFA導入のメリット

MFAは「入れる手間」のコストに対して、セキュリティ・コンプライアンス・運用工数の3軸で大きなリターンが返ってくる施策です。

アカウント乗っ取りリスクの大幅低減

Microsoftは、MFAがアカウント侵害攻撃の99.2%を超える割合をブロックできるとしています。この数値はAzure Active Directoryの不審なサインインを対象にした調査に基づくもので、Microsoftが2019年に公表した「99.9%以上をブロックできる」という主張を、より新しい検証結果で置き換えたものです。いずれにしてもパスワード単独の認証と比べ、攻撃成功率を桁違いに下げられることは変わりません。

注意したいのは、この数字が「MFAを入れれば99%安全」という意味ではない点です。ブロックされるのはパスワード窃取を起点とした自動化された攻撃であり、後述するAiTM（Adversary-in-the-Middle）フィッシングやMFA疲労攻撃は別途の対策が必要です。

コンプライアンス対応の効率化

ISMS、SOC2、PCI DSS、J-SOX、改正電帳法といった監査要件で、特権アカウントへのMFAは事実上必須化しています。MFA導入はそのまま監査対応の標準化につながります。

ヘルプデスク負荷の削減

MFA導入によりパスワードリセット要求が減るのは直感に反しますが、認証ポイント集約とSSO併用により、ユーザーが「複数SaaSのパスワードを覚える」状況が消えるため問い合わせ総数が下がります。

参考：One simple action you can take to prevent 99.9 percent of attacks on your accounts - Microsoft Security Blog

MFA導入の注意点

メリットの大きさに反して、設計を誤ると業務影響やユーザー反発を招きます。情シスが事前に押さえるべきポイントを3つ紹介します。

MFA疲労攻撃への対策

プッシュ通知MFAでは、攻撃者がパスワードを入手したうえで連続プッシュを送り、ユーザーの誤承認を誘うMFA疲労攻撃が増えています。番号一致機能（Number Matching）を必ず有効化し、可能ならFIDO2への移行を進めます。番号照合が有効な環境では、ユーザーはサインイン画面に表示された数字を認証アプリ側に入力する必要があるため、通知をただタップしただけでは承認が成立しません。深夜に連続通知が届く時点で異常だと気づける運用（ユーザーへの周知と、サインインログの異常検知アラート）まで含めて設計してください。

バックアップ手段の整備

スマートフォン紛失時、生体認証失敗時の代替手段を用意しておかないと業務が止まります。バックアップコード発行、複数の認証方式登録、情シスへのリセットフロー整備を導入時に必ずセットで設計します。

ユーザー教育と段階展開

MFAは認証ステップが1つ増えるため、初期導入時のユーザー反発が起こりがちです。事前周知・FAQ整備・部署単位の段階展開を組み合わせ、現場の理解を得ながら進めます。

MFAをすり抜ける攻撃手口

MFAを入れても突破される経路が存在します。手口を知らないと「MFAを入れたから大丈夫」という誤った安心につながるため、代表的な3つを押さえておきます。

AiTM（Adversary-in-the-Middle）フィッシングは、攻撃者が用意したリバースプロキシを経由させ、本物のログイン画面をそのまま中継する手口です。ユーザーが入力したパスワードとワンタイムコードは本物のサイトへ転送されるため認証は成功し、攻撃者は発行されたセッションCookieを盗みます。TOTPやプッシュ通知では防げず、認証対象のドメインを鍵に紐づけるFIDO2／パスキーが有効な対策になります。

セッションCookie窃取（Pass-the-Cookie）は、端末に感染したインフォスティーラーがブラウザの認証済みCookieを抜き取る手口です。認証そのものを迂回するため、MFAの強度とは無関係に成立します。デバイスの健全性を条件付きアクセスの条件に入れ、セッションの有効期間を短くする設計が必要です。

SIMスワップは、攻撃者が通信事業者を騙してSIMを再発行し、SMSのワンタイムコードを受け取る手口です。SMS認証をMFAの唯一の第2要素にしている場合の典型的な突破経路になります。

これら3つに共通しているのは、認証を強くするだけでは足りず「どの端末から、どのセッションで、どの権限を使っているか」を管理する側の仕組みが必要になる点です。認証情報が漏れることを前提に置いた設計が求められます。ジョーシスが2026年に225社を対象に実施した調査では、99%の企業で自社に関連する認証情報がダークウェブなどに流出している状態が確認されました。流出そのものをゼロにする前提は現実的ではありません。

参考：Authenticator の MFA プッシュ通知での番号照合のしくみ - Microsoft Learn

フィッシング耐性MFAへの移行ステップ

SMS認証やTOTPから、フィッシング耐性を持つFIDO2／パスキーへ移行することが中期の目標形になります。ただし全社を一度に切り替えるのは非現実的なので、段階を切って進めます。

第1段階は、SMS認証の棚卸しです。IdPの認証方法レポートで、どのユーザーがSMSを唯一の第2要素にしているかを洗い出します。特権アカウント・経営層・財務系SaaSの利用者にSMSが残っていれば最優先で置き換えます。

第2段階は、番号照合付きプッシュ通知またはTOTPへの一斉移行です。ここまでは追加の機材調達が不要なため、コストをかけずに全社の下限を引き上げられます。

第3段階は、特権アカウントへのFIDO2セキュリティキー配布です。人数が限られるため調達も登録支援も現実的な規模に収まります。緊急用アカウントもこの段階で証明書ベース認証またはパスキーへ寄せます。

第4段階は、一般従業員へのパスキー展開です。会社管理のPC・スマートフォンで生体認証を有効にし、パスワードレスサインインを既定にします。Microsoft Entra IDの場合、認証方法ポリシーでパスキー（FIDO2）を有効化し、条件付きアクセスの認証強度で「フィッシングに強いMFA」を要求する構成になります。

第5段階は、パスワード自体の廃止に向けた整理です。パスワードが残っている限りフィッシングの余地は残るため、パスワードレスサインインが定着したユーザーからパスワード認証を無効化していきます。

移行の途中では方式が混在します。混在は問題ではなく、混在していることを台帳で把握できていない状態が問題です。どのユーザーがどの方式を登録しているかを定期的に出力し、棚卸しの対象に含めてください。

参考：Microsoft Entra ID でのパスキー (FIDO2) の有効化 - Microsoft Learn

MFA代表製品の比較

国内外で利用される主要なMFA／IDaaS製品を、情シスの選定観点で整理しました。価格や機能は2026年5月時点の公開情報に基づいています。

まず全体像を一覧で示します。

選定時に見落としやすいのは、条件付きアクセスが上位ライセンスの機能である点です。Microsoft Entra IDの条件付きアクセスにはP1またはP2ライセンスが必要で、MFAそのものが使えることと、リスクに応じて出し分けられることは別の話になります。

Microsoft Entra ID（Authenticator）

Microsoft 365契約企業の標準解です。FreeでもMFAは利用可能で、P1で条件付きアクセス、P2でリスクベース認証が解放されます。詳細はMicrosoft Entra ID 公式で確認できます。

Okta Verify

Oktaの主力MFAアプリで、プッシュ通知・TOTP・FIDO2に対応。Okta Adaptive MFAでリスクベース認証も提供します。詳細はOkta Adaptive MFA 公式で確認できます。

Google認証

Google Workspace付属で、認証アプリ・FIDO2セキュリティキー・パスキーに対応。Workspace Premium版で高度な条件付きアクセスを利用可能です。詳細はGoogle認証 公式で確認できます。

Duo Security（Cisco）

エンタープライズ向けMFAの代表格。VPN・オンプレシステム・SaaSの統合認証に強く、Cisco Secure Accessの基盤として利用されます。詳細はDuo Security 公式で確認できます。

YubiKey（Yubico）

FIDO2対応の物理セキュリティキー。フィッシング耐性最強の選択肢で、特権アカウントや経営層向けに導入される傾向があります。詳細はYubiKey 5シリーズ 公式で確認できます。

HENNGE One

国産IDaaSのMFA機能。Microsoft 365／Google Workspaceとの連携が手厚く、日本語サポートと国産プロダクトの安心感を重視する企業に選ばれています。詳細はHENNGE One 公式で確認できます。

参考：多要素認証(MFA)ツールの比較 - ITreview

自社サービスにMFAを実装する場合の選択肢

ここまでは社内システムを守る側の話でしたが、自社が提供するWebサービスやアプリにMFAを実装したいケースもあります。情シスと開発部門が兼務している組織では、この2つが同時に議題に上がります。実装方針は3つに分かれます。

1つ目は、認証をIDaaSへ委譲する方式です。Microsoft Entra External ID、Okta Customer Identity、Auth0などのCIAM（顧客ID管理）サービスにOpenID Connectで接続し、MFAの設定・登録・リカバリをすべて外部に任せます。自社でワンタイムコードの生成やバックアップコードの保管を実装する必要がなくなるため、セキュリティ実装の負債を持たずに済みます。

2つ目は、認証APIを組み込む方式です。ワンタイムコード送信やパスキー登録のAPIを提供するサービスを使い、自社アプリのログイン画面はそのまま維持します。ユーザー体験を自社で制御したい場合に選ばれます。

3つ目は、自前実装です。TOTPはRFC 6238で標準化されているため実装自体は可能ですが、シークレットの保管、レート制限、バックアップコードの発行と失効、リカバリ時の本人確認まで自前で設計する必要があります。よほどの理由がない限り推奨しません。

パスキー対応を検討する場合、実装の鍵になるのはW3CのWebAuthn APIです。ブラウザ経由で認証器を呼び出し、公開鍵を自社サーバーに登録する流れになります。ドメイン（Relying Party ID）が鍵に紐づく仕様のため、認証を受け付けるドメインの設計を最初に決めておく必要があります。サブドメインを分けてサービスを提供している場合、後から統合するのは容易ではありません。

社内システム向けと顧客向けで別のIdPを使う構成は珍しくありませんが、その場合は「従業員が顧客向けサービスの管理画面に入る経路」がどちらのMFAポリシーの配下にあるかを必ず確認してください。この境界が曖昧なまま運用されている状態が、監査で指摘を受ける典型例です。

参考：Microsoft Entra ID を使用したパスキー (FIDO2) 認証マトリックス - Microsoft Learn 参考：RFC 6238 - TOTP: Time-Based One-Time Password Algorithm

MFA導入の進め方

「現状把握 → 対象優先度付け → IdPでの一元設定 → パイロット → 全社展開」の5ステップで進めます。最初から100%カバーを目指さず、リスクの高い領域から段階導入します。

ステップ1：現状把握とリスク評価

特権アカウント、経営層、外部公開ポータル、リモートアクセスの4領域を最優先のMFA対象として抽出します。残りはユーザー数・データ機密度・業務影響度で順位付けします。

ステップ2：対象アカウントの優先度付け

特権・経営層へは即時、一般従業員は段階展開、外部委託先には別ポリシーといった切り分けを定義します。「どこを最初にMFA必須化するか」が導入計画の軸になります。

ステップ3：IdPでのMFAポリシー設定

Entra ID／Oktaなど既存IdPでMFAポリシーを定義し、条件付きアクセスでデバイス・場所・リスクに応じた要求条件を設計します。SaaS個別ではなくIdP一元での設定が原則です。

ステップ4：パイロット導入

情シス部門と1部署でMFAを先行導入し、ユーザーからのフィードバック・問い合わせ傾向・障害時のリカバリ手順を検証します。FAQとマニュアルを整備したうえで全社展開に進みます。

ステップ5：全社展開と継続改善

優先度の高い対象から順にMFA必須化し、定期的にMFA方式の見直し（SMS→TOTP→FIDO2）と棚卸しを実施します。フィッシング耐性のあるFIDO2／パスキーへの移行が中期的な目標です。

Entra IDでMFAを必須化する設定手順

Microsoft Entra IDを前提にした場合、実装の流れは次のようになります。ライセンスによって使える機能が変わるため、条件付きアクセスが使えるかどうかを最初に確認してください。

P1またはP2ライセンスがある場合は、条件付きアクセスポリシーを作成します。対象ユーザーを指定し、対象アプリを全クラウドアプリに設定し、アクセス制御で多要素認証の要求を有効にします。フィッシング耐性を求める段階に進んだら、認証強度の設定で「フィッシングに強いMFA」を指定します。除外設定を入れる場合は、除外したアカウントの一覧を台帳に残してください。除外が残ったまま忘れられるのが最も多い抜け穴です。

条件付きアクセスが使えない場合は、セキュリティの既定値（Security Defaults）を有効にします。細かい出し分けはできませんが、全ユーザーへのMFA登録要求と特権操作時のMFA要求が有効になります。

いずれの構成でも、緊急用アカウントの扱いを先に決めます。必須MFAの適用対象からは除外されないため、パスキー（FIDO2）または証明書ベース認証を登録しておく必要があります。スマートフォンのアプリだけに依存した設計にしないことが重要です。

設定後は、サインインログでMFA要件のソースがどのポリシーになっているかを確認します。意図したポリシーが効いていないケースは、レガシーのMFAテナント全体ポリシーが併存していることが原因になりがちです。

MFA導入チェックリスト

展開前に確認する項目を一覧にしました。社内の展開計画書にそのまま転記できる粒度でまとめています。

最後の項目が抜けている組織が最も多く、そのままMFA適用漏れの温床になります。次のセクションで詳しく扱います。

MFA用語集

MFA関連で頻出する技術用語を簡潔にまとめました。検討資料の作成や社内説明にもそのまま使えます。

TOTP（Time-based One-Time Password）

時刻ベースで30秒ごとに生成される6桁ワンタイムコード。RFC 6238で標準化されており、認証アプリのほぼすべてが対応しています。

FIDO2／WebAuthn

パスワードレス認証の業界標準。公開鍵暗号方式を使い、サーバ側に秘密鍵を保存しないためフィッシング・サーバ侵害耐性が極めて高い特徴があります。

パスキー

FIDO2をクラウド同期可能にした実装で、Apple／Google／Microsoftが大規模推進中。スマートフォン紛失時もクラウド復元できる利便性とFIDO2のセキュリティを両立します。

MFA疲労攻撃

攻撃者がパスワードを入手したうえで連続プッシュ通知を送り、ユーザーの誤承認を誘う攻撃手法。Number Matching対策が必須です。

Number Matching（番号一致）

プッシュ通知MFAで、画面とアプリに表示される数字を入力して一致を確認する機能。MFA疲労攻撃を防ぐ標準対策です。

バックアップコード

スマートフォン紛失や認証アプリ障害時に使う一回限りの予備コード。導入時に必ず発行・保管ルールを設計します。

AiTM（Adversary-in-the-Middle）攻撃

攻撃者のリバースプロキシを経由させて本物のログイン画面を中継し、認証を成立させたうえでセッションCookieを盗む手口。TOTPやプッシュ通知では防げず、FIDO2／パスキーが有効な対策になります。

条件付きアクセス（Conditional Access）

ユーザー・デバイス・場所・リスクスコアなどの条件に応じて、アクセスの許可・ブロック・MFA要求を出し分ける機能。Microsoft Entra IDではP1またはP2ライセンスが必要です。

パスワードレス認証

知識要素であるパスワードを使わず、所持要素と生体要素の組み合わせで認証する方式。パスキーやWindows Helloが代表例で、MFAの要件を満たしながらパスワード起因の攻撃経路を消せます。

SIMスワップ

攻撃者が通信事業者を騙してSIMを再発行し、被害者の電話番号でSMSのワンタイムコードを受け取る手口。SMS認証の推奨度が下がっている主要な理由です。

MFAだけでは解決しないSaaS管理の課題

MFAは認証強度を上げる強力な仕組みですが、SaaS全体のライフサイクル（誰がどのSaaSをどう使っているか、ライセンス利用率、契約・更新管理）までは守備範囲外です。利用しているSaaSの種類が30を超える組織では、MFAとSaaS管理プラットフォーム（SMP）の組み合わせが現実解になります。

未管理SaaSのMFA設定漏れ

部署が情シス無断で契約したシャドーITは、IdP連携されていないためMFAが適用されません。SaaS購買データやクレジットカード明細を横断的に取得する仕組みでなければ、こうした抜け穴は塞げません。この構造そのものについてはシャドーITとはで整理しています。

ライセンス利用率の可視化

MFAはログイン可否を判定しますが、有償ライセンスの利用率や過剰契約までは追跡しません。年間SaaSコストを最適化するには、ライセンス単位の利用実態データが必要です。

退職者アカウントの完全削除

IdP側でアカウント無効化しても、SaaS側に残ったアカウント情報やAPIトークンが完全に削除されないケースがあります。SaaS横断での削除プロセスとしてはSCIM自動化＋管理プラットフォームでの監査が必要です。残ったまま誰の管理下にもない状態は孤立アカウントと呼ばれ、MFAの適用対象からも外れます。具体的な削除手順は退職者アカウントの削除方法、自動化の仕組みはSCIMとはを参照してください。

SaaS管理プラットフォームが補う領域

ジョーシスのプラットフォームは350以上のSaaS連携と31カテゴリの管理機能を備え、MFA基盤がカバーしないSaaSライフサイクル全体を統合管理できる設計です。国内外700社以上の導入実績があり、IT工数を最大50%、ITコストを最大75%削減した事例も報告されています。

無料デモはJosys デモ予約から日程を選べます。

MFAについてよくある質問

検討フェーズで担当者から多く寄せられる質問を整理しました。

MFAとは何の略ですか

multi-factor authentication の略で、日本語では多要素認証と訳します。読み方は「エムエフエー」です。要素をちょうど2つに限定した場合は2FA（two-factor authentication、二要素認証）と呼ばれ、MFAの部分集合にあたります。

MFAとSSOはどちらを先に入れるべきですか

可能ならSSO先行＋MFA同時が理想ですが、リソースが限られる場合は特権アカウントへのMFAを最優先します。SSOがないとSaaSごとに個別MFA設定が必要になり、運用負荷が高まります。

SMS認証はもう使ってはいけませんか

「MFAなし」よりは確実に良いですが、可能な限りTOTP・プッシュ通知・FIDO2への移行が推奨されます。特権アカウント・経営層・財務系SaaSにはSMS禁止が望ましい運用です。

パスキーは企業利用できますか

Microsoft Entra ID、Okta、Google Workspaceなど主要IDaaSがパスキーに対応しています。スマートフォン紛失時のクラウド復元や、デバイス間の認証情報同期が可能で企業利用に適します。

MFA導入で業務効率が落ちませんか

導入直後の慣れの期間を除けば、SSO併用とリスクベース認証で「毎回MFA要求」を回避できます。条件付きアクセスを使えば信頼済み環境ではMFA要求を省略でき、ユーザー体験はほぼ変わりません。

MFAを入れていても侵害されることはありますか

あります。AiTMフィッシングでセッションCookieを奪われる経路、端末に感染したインフォスティーラーが認証済みCookieを抜く経路、SIMスワップでSMSコードを受け取られる経路が代表的です。認証方式をFIDO2／パスキーへ寄せ、デバイスの健全性を条件付きアクセスの条件に加えることで大幅に狭められます。

MFAはIdPとSaaSのどちらに設定すべきですか

原則としてIdP側に一元設定します。SaaS個別に設定すると、設定漏れの検知ができず、方式の見直し時にすべてのSaaSを触ることになります。IdP連携できないSaaSが残る場合は、そのSaaSを一覧化して個別設定の対象として台帳管理してください。SaaSセキュリティ全体の点検項目はSaaSセキュリティチェックリストにまとめています。

まとめ

MFAは知識・所持・生体の3要素から異なる2つ以上を組み合わせる認証方式で、アカウント乗っ取りリスクを99.9%以上低減できる強力MFA（multi-factor authentication、多要素認証）は知識・所持・生体の3要素から異なる2つ以上を組み合わせる認証方式で、Microsoftの検証ではアカウント侵害攻撃の99.2%を超える割合をブロックできると報告されています。SSO／IDaaSと組み合わせ、認証ポイントを集約したうえでMFAを必須化するのが基本設計になります。

一方で、AiTMフィッシングやセッションCookie窃取のようにMFAをすり抜ける手口も存在します。中期的にはフィッシング耐性を持つFIDO2／パスキーへ移行し、デバイスの健全性を条件に含める構成へ寄せていくことが目標形です。

な対策です。SSO／IDaaSと組み合わせ、認証ポイントを集約したうえでMFAを必須化するのが基本設計になります。

ただしMFA単体ではSaaS全体のライフサイクル管理までは届かないため、SaaS管理プラットフォームとの組み合わせ運用が現実解になります。自社のSaaS環境を統合的に整備したい場合は、5分でわかるJosysから検討を始めるのが近道です。