用語比較
SSOとMFAの違い
一言でいうと
SSOは複数サービスへのログインを共通化し、MFAは異なる要素による本人確認を行う。代替する二者択一ではなく、SSOの認証元で必要なMFAを適用し、対象アプリ・利用者・例外と実際の結果を確認して組み合わせる。ログインできることと、業務権限が適切なことは別に確認する。
SSOとMFAは両方必要？ログインの共通化と本人確認の違いを7軸で比較し、毎回MFA画面が出ない理由、SSO未接続の入口、退職者の停止との違いを解説します。Microsoft Entraの認証強度と契約条件、4状態の受入確認、方式別の実務ガイドで、情シスの導入・見直しを支えます。
- 難易度
- 初級
- 想定読者
- 情シス・SaaS管理者・認証運用担当
- 所要時間
- 約11分
- 最終確認
- 2026-10-30
- 1. 対象をそろえる
アプリ・利用者・入口・既存認証と、承認された例外の担当・期限を確認する。
- 2. 必要な認証を決める
SSOの方式とMFAの要素・適用条件、登録・紛失時の正規手順を決める。
- 3. 4状態で照合する
新規・既存・対象条件・復旧で、期待、実際、未確認事項を記録する。
SSOとは
Single Sign-On。認証元のログイン状態や認証結果を複数のアプリで利用する仕組み。連携方式、対象アプリ、再認証の条件で動作が変わり、全アプリのアカウント作成・削除や全入口へのMFA適用を名称だけで保証しない。
MFAとは
Multi-Factor Authentication。知識・所持・生体など異なる種類の認証要素を組み合わせて本人確認すること。パスワードを2回入力しても別要素にはならず、確認画面の回数だけで多要素かどうかは判断できない。
違いの比較表
| 比較軸 | SSO | MFA |
|---|---|---|
| 目的 | 複数アプリへのログインと認証方針の共通化 | なりすましを抑えるため、異なる要素で本人確認 |
| 対象 | IdPと接続済みのアプリ・利用者。未接続も棚卸しする | ポリシーで対象にした利用者・リソース・認証方式 |
| 方式 | SAML・OIDC等。パスワード再入力を代行するSSOも区別 | パスワードとOTP、利用者確認を伴うパスキー等。耐性は方式による |
| セッション | 既存の認証状態を再利用する。再認証は条件に依存 | 以前の認証が要件を満たせば、追加画面が出ない機能例もある |
| 運用 | 接続、識別子、割り当て、障害・鍵更新の管理 | 方式の登録・適用範囲・紛失時の復旧・不審な要求への対応 |
| 権限と停止 | SSOとは別に、アカウント・役割・外部連携の反映を確認 | 認証が強くても過剰権限は解消しない。既存アクセスも確認 |
| 見積 | 利用者、対象アプリ、SSO対応プラン、接続・移行・運用 | 認証方式、管理機能、予備手段、窓口・復旧支援を含めて比較 |
方式を選んだら、不審な要求への対応も確認
現在の方式が守る範囲と、不審な通知・誤承認時に誰が何を行うかを確認する。判断表で不足した条件を、次の記録へ引き継げます。
無料のMFA方式別確認・初動ガイドへ使い分け
- 複数SaaSの認証を統一したいならSSOを検討し、管理者や重要データに対しては必要なMFA方式と適用条件も決める。SSOの購入だけをMFA設定完了と扱わない。
- MFAを導入済みでもアプリごとの個別ログインが残るなら、接続状況・例外・割り当てを棚卸しし、認証方針が適用される範囲を確認する。
- 身に覚えのないMFA通知や承認があれば、設計の比較を続ける前に正規の窓口へ報告する。番号一致やパスキーの導入計画を、現在の侵害疑いの対応の代わりにしない。
SSOとMFAを併用する条件：対象・入口・例外を分ける
MicrosoftのSSO概要資料は、SAML・OIDCによる連携と、保存した認証情報をアプリへ渡すパスワードベースのSSOを分けて説明している。「SSO対応」という表示だけで、どの方式でどの認証方針が適用されるかを決めない。接続先の公式仕様と実際の構成を確認する。
管理する一覧には、対象アプリ、認証元、従業員・管理者・ゲストの区分、接続方式、必要な認証要素、未接続の個別ログイン、承認された例外の担当・期限を記録する。これは編集部の棚卸し項目であり、SSOを経由しない入口の利用方法や制御を回避する手順ではない。
利用していないアプリを追加したり、管理者を一斉に締め出したりする前に、承認された小さな範囲で確認する。緊急時の正規のアクセス手順も既存規程で別管理し、その利用・監視・事後確認の責任者を決める。記事を根拠に保護を外したり、広い恒久例外を作ったりしない。
MFA画面が毎回出ない理由と、設定の確認方法
Microsoft Entraの認証強度は、対象リソースで許容する認証方式の組み合わせを定める機能例。既に行った認証が条件を満たせば、追加の認証画面なしにアクセスできると公式資料は説明している。画面が出ないという事実だけで、MFAが無効・故障・不要になったとは判断しない。
確認では、対象ユーザー・アプリ・時刻、適用されたポリシー、使用した方式、認証の結果、既存セッションの有無を管理画面とログで照合する。新規サインインの確認を、開いたままのブラウザで業務画面が表示されたことだけで代用しない。認証情報やセッション値をCyberLensへ貼り付けない。
MFAは方式を分けて評価する。OTPや通知の承認をフィッシング耐性と一律に説明せず、要件に応じてパスキー等の利用条件を確認する。パスキーも、利用者確認とサービス側の要件を満たすかを別に確認し、画面が1回だから単一要素だと扱わない。
SSO・SCIM・退職者対応の違い：ログインと権限を分ける
Microsoftのアプリプロビジョニング資料は、利用者・役割の作成、維持、状態変更や削除を扱い、SAML・OIDCとSCIMを組み合わせる構成も説明している。SSOの接続完了は、自動プロビジョニングの設定・反映まで完了したことを意味しない。
入社・異動・退職の確認では、認証元の状態、SaaS側のアカウントと役割、個別アカウント、外部アプリへの付与、残るセッションをサービスごとに確認する。管理画面に変更要求を保存したことと、対象SaaSで変更を確認できたことを区別する。
担当者は変更日時、対象の管理番号、期待結果、反映結果、未確認範囲、次の担当・期限を承認済みの社内記録へ残す。ログインできた利用者でも業務上の権限は最小化し、認証の強化を過剰権限の対策完了と扱わない。
導入・見直しの手順：4状態の確認と費用条件
編集部の受入確認例は4状態。①新しいサインイン、②既存セッションでのアクセス、③想定する利用者・アプリ・入口と対象外の条件、④認証器紛失時の正規の復旧、を許可済みのテストアカウントと環境で確認する。必要な認証・許可・拒否と実際の結果を並べ、本番利用者の設定を試験のために変更しない。
仮の計画で2アプリに4状態を割り当てれば8つの確認になる。これは確認漏れを減らすための設計例で、実施済みの試験数や安全性の保証ではない。対象が増えたら管理者・ゲスト、端末条件、復旧条件の差も追加する。
機能例として、Microsoft EntraのConditional Accessの認証強度にはP1ライセンスの前提がある。SSOやMFA全般を同じ契約条件とは扱わず、利用者・対象アプリ・SSO対応プラン、方式、窓口・移行・復旧支援を同じ条件で見積もる。固定の相場や効果の削減率はここでは示さない。
よくある誤解
- SSOとMFAは利便性か安全性かを選ぶ二者択一ではない。対象をそろえて併用する。
- MFAの登録済み表示と、対象アプリで要件が適用されたことは別。通知回数だけで結果を判断しない。
- SSOだけで退職者のSaaS権限・外部連携・既存セッションがすべて消えると考えず、対象側の反映を確認する。
よくある質問
SSOを導入すればMFAは不要ですか？
不要とは考えません。SSOはログインの共通化、MFAは異なる要素による本人確認を担います。対象アプリ・利用者・例外をそろえて必要なMFA方式を適用し、実際の結果を確認します。
SSO後にMFA画面が出ないと、設定に失敗していますか？
画面だけでは判断できません。Microsoft Entraの認証強度では、既に行った認証が要件を満たすと追加画面なしでアクセスできる機能例があります。対象ポリシー、使用した方式、時刻と結果を管理画面・ログで確認します。
SSOに統合すれば退職者のSaaSアカウントも自動削除されますか？
SSO接続だけで自動削除の完了とは扱いません。プロビジョニングの設定と、対象SaaSのアカウント・役割・外部連携・残るセッションを分けて確認し、反映できていない範囲を記録します。
編集・確認情報
MicrosoftのSSO・認証強度・評価条件・アプリプロビジョニングとNIST SP 800-63B-4の公開資料を照合し、適用範囲・既存認証・権限との違いを改訂しました。実テナントの構成検証・性能測定・個別監修は行っていません。 最終確認日は 2026-10-30 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。