「とりあえずMFAを有効化したけれど、ライセンスはこれで合っているのか」「スマホが使えないユーザーを一時的にMFAから外したい」。Microsoft Entra ID（旧Azure AD）を本格運用し始めると、必ずぶつかるのがこの2つの悩みです。本記事では、必要な契約と具体的な設定パターンを“最小構成”から丁寧に整理します。
Microsoft Entra IDでMFAをポリシー管理するためのライセンス整理
まずは「どの契約があれば、どこまでできるのか」を整理します。MFAを“ポリシー（条件付きアクセス）”で制御したいかどうかが分かれ目です。
無料で使える基本保護：Security Defaults
Microsoft Entra ID Free でも、Security Defaults（セキュリティの既定値）を有効化することで、以下のような基本的なセキュリティ対策を一括で有効化できます。
- すべてのユーザーに対して多要素認証（MFA）の登録と利用を要求
- レガシ認証（古いプロトコル）をブロック
- 管理者ロールへのより強い保護の適用
ただし、Security Defaults には明確な制約があります。
- 「このユーザーだけMFAを緩く」「このアプリだけMFA必須」のような細かな条件設定ができない
- 「この例外グループだけMFAから除外」のような除外設定ができない
- 高度なレポート（Usage & insights や Authentication Methods Activity）も利用できない
小規模・単純な構成ならSecurity Defaultsでも十分ですが、「MFAをポリシーでコントロールしたい」「一部ユーザーだけ一時的に例外を設けたい」場合は限界があります。
条件付きアクセスを使うための最低要件：Entra ID P1
MFAを「ユーザー」「アプリ」「場所」「デバイス状態」などの条件ごとに制御したい場合は、条件付きアクセス（Conditional Access）が必須です。そしてこの機能はMicrosoft Entra ID P1ライセンスが前提です。
- 条件付きアクセス自体の利用には Entra ID P1 が必要
- Entra ID P1 は以下のようなサブスクリプションに含まれる
- Microsoft 365 Business Premium
- Microsoft 365 E3
- Entra ID P1 単体ライセンス など
また、リスクベースの条件付きアクセス（サインインリスクやユーザーリスクに応じてMFA要求やパスワード変更を強制する機能）を使いたい場合は、Entra ID P2（Identity Protection）が必要です。
エディション別：MFA関連機能のざっくり比較
| エディション | 代表的なライセンス | MFA関連の主な機能 | 向いているケース |
|---|---|---|---|
| Entra ID Free | Microsoft 365 Business Basic など | Security Defaultsによる一括MFA Per-user MFA（旧来方式）※非推奨 | 小規模／シンプル構成で「全員同じルールで良い」組織 |
| Entra ID P1 | M365 Business Premium / E3, Entra ID P1単体 | 条件付きアクセスで柔軟にMFA要求 Authentication methods policy の利用 Usage & insights / Authentication Methods Activity レポート | ある程度の規模で、アプリやユーザー属性ごとにMFA条件を変えたい組織 |
| Entra ID P2 | M365 E5, Entra ID P2単体 | リスクベースの条件付きアクセス（Identity Protection） 高度なレポート・検知機能 | ゼロトラストやリスクベースMFAを含め、より強固なセキュリティを求める組織 |
ライセンス枚数の考え方
条件付きアクセスは、テナントに1つでもP1/P2ライセンスがあると機能自体は有効になりますが、利用するユーザー数分のライセンスを保有している必要があるとマイクロソフトは案内しています。
- 例：条件付きアクセスで保護されるアプリを 990ユーザーが利用 → 990ユーザー分のP1ライセンスが必要
- 条件付きアクセスで保護されたアプリを一切利用しないユーザーにはP1は不要
| ケース | P1/P2ライセンス必要数（目安） |
|---|---|
| 全ユーザーがM365とEntra IDアプリを利用 | ユーザー数と同数 |
| 一部のサービスアカウントは条件付きアクセス対象外 | 条件付きアクセスで保護されるアプリを使うユーザー数のみ |
Security Defaults と条件付きアクセスの違いと選び方
「一時的にMFAを外したい」など、柔軟な運用を考える時に必ず出てくるのが「Security Defaults のままで良いか？条件付きアクセスに切り替えるべきか？」という問題です。
2つは基本的に排他運用
Security Defaults と条件付きアクセスは、基本的にどちらか一方を使う運用が前提です。
- Security Defaults が有効なテナントでは、条件付きアクセス ポリシーを作成することはできても有効化はできない
- 細かいMFA制御をしたい場合は、まず Security Defaults を無効化し、代わりに条件付きアクセスで同等以上の保護ポリシーを作る
Security Defaults と 条件付きアクセスの比較表
| 項目 | Security Defaults | 条件付きアクセス |
|---|---|---|
| 料金 | Entra ID Free でも利用可 | Entra ID P1 / P2 が必要 |
| MFAの対象指定 | 全ユーザー一律（例外なし） | ユーザー／グループ／ロール単位で柔軟に指定 |
| アプリ・リソース別制御 | 不可 | クラウドアプリ／アクションごとにポリシー分割可能 |
| 場所・デバイス条件 | 一部は自動で考慮されるが明示的な条件指定は不可 | 信頼済みネットワーク、デバイス準拠状態などを条件にできる |
| 例外ユーザーの扱い | 除外設定はできない | 緊急（ブレークグラス）アカウントや一時除外グループを明示的に設定可能 |
| レポート・可視化 | 簡易なサインインログのみ | Usage & insights / Authentication Methods Activity など高度な分析が可能 |
| 推奨シナリオ | 非常に小規模で、ポリシーを細かく分ける必要がない環境 | ほとんどの企業テナント（アプリやユーザーの種類が多い環境） |
「一時的にMFAを回避したい」「一部のユーザーだけ異なる扱いにしたい」といった要件が出ている時点で、Security Defaults から条件付きアクセス（＝Entra ID P1以上）への移行を前提に設計したほうが良いと考えられます。
今後の標準：Authentication methods policy による統合管理
これまで Microsoft Entra ID（Azure AD）では、
- Per-user MFA 設定画面
- 古い MFA サービス設定画面
- SSPR（セルフサービスパスワードリセット）の専用ポリシー
など、複数の画面・ポリシーで認証方法を管理していましたが、今後はすべて「Authentication methods policy（認証方法ポリシー）」に集約されます。
マイクロソフトは、2025年9月30日以降、レガシーなMFA/SSPRポリシーでは認証方法を管理できなくなると告知しています。
- 期日以降は、旧ポリシー側の設定がグレーアウトされ、Authentication methods policy 側の設定のみ有効
- 移行ウィザードや手動マイグレーションで、早めに新ポリシーへ切り替えておくことが推奨
| 旧方式 | 新方式（Authentication methods policy） | ポイント |
|---|---|---|
| Per-user MFA 設定画面 | 認証方法ポリシー ＋ 条件付きアクセス | ユーザー単位で「常にMFA」ではなく、「条件に応じてMFA」が推奨 |
| SSPR専用ポリシー | 認証方法ポリシー内のSSPR関連設定 | 登録・利用に使う認証方法を一カ所で定義 |
| 古いMFAサービス設定 | 認証方法ポリシー＋Authentication Methods Activity レポート | どの認証方法がどれだけ使われているかを可視化 |
「一時的にMFAを回避したい」を安全に叶える Temporary Access Pass (TAP)
ここからが本題です。
- スマートフォンを紛失した
- ガラケーしか持っておらず、Authenticator アプリが使えない
- 出張中に端末を再セットアップしている …など
こうしたユーザーが「しばらくMFAが使えない」状況になると、「この人だけ CA から除外してパスワードだけでログインさせよう」と考えがちですが、これはセキュリティ的に大きなリスクです。MFAポリシーは維持したまま、一時的に安全にサインインさせる手段として用意されているのがTemporary Access Pass（TAP：一時アクセス パス）です。
Temporary Access Pass とは？
Temporary Access Pass は、管理者がユーザーごとに発行する時間制限付きのパスコードです。特徴は次のとおりです。
- 時間制限付き（有効期間は 10分〜30日までポリシーで定義可能）
- 1ユーザーにつき同時に1つのTAPのみ保有可能
- 「1回だけ使用（ワンタイム）」か「有効期間内は複数回使用可」かを選択できる
- Authentication methods policy の一部として有効化・制御する
- パスワードレス認証（FIDO2、パスキー、Authenticatorによる電話サインイン）の初期登録や復旧時のブートストラップ手段として設計されており、強力な認証要件を満たすクレデンシャルとして扱われる
- TAPでサインインして取得したトークン（セッショントークン、リフレッシュトークンなど）は、TAPの有効期間に縛られる。TAPが失効するとトークンも失効する
- NPS拡張機能（RADIUS連携）や AD FS アダプターとは併用できない
つまり TAP は、「普通の二要素認証が使えない一時的な状況で、強い認証を壊さずにオンボーディングや復旧を行うための安全な裏口」という位置づけです。
TAPがフィットする代表的なシナリオ
- 新入社員が初日にまだAuthenticatorやFIDO2キーを持っていない
- 初回サインインだけTAPを使い、その場でパスキーやFIDO2キーを登録させる
- ユーザーがスマホを紛失し、MFAが利用できない
- 本人確認後、短時間有効のワンタイムTAPを発行 → サインイン後に新しい端末へAuthenticatorを登録
- スマホ持ち込み禁止エリア向けの一時的アクセス
- 専用端末から短時間だけサインインするためにTAPを利用し、その後は通常の強力な認証方法を使用
「MFAを無効化する」のではなく「別の強力な認証方法を使う」発想
重要なのは、TAPを使うためにMFAや条件付きアクセスを無効化する必要はまったくないという点です。
- 条件付きアクセスのポリシーでは「強力な認証が必要」や「MFAが必要」と定義しておく
- ユーザーの認証方法の1つとして TAP を許可し、通常のAuthenticatorやFIDO2と同列に「強力な認証」として扱う
- ユーザーは、通常はAuthenticatorやFIDO2でMFAを満たし、どうしても使用できない期間だけ TAP でサインインする
一方、「このユーザーだけ条件付きアクセスのMFA要求から完全除外しておく」といった運用は、Azureポータルなどでの今後の必須MFA化（Mandatory MFA）を見据えると危険な構成です。
TAPポリシーの推奨設定例
実運用でよく使われる「最低限安全な設定例」を整理すると、次のようになります。数値はテナントのポリシー範囲（10分〜30日）内で調整してください。
| 項目 | 推奨値（例） | 理由・補足 |
|---|---|---|
| 利用回数 | ワンタイム（1回のみ） | 複数回使用可能なTAPは、漏えい時に悪用されるリスクが高いため、可能な限り1回きりにする |
| 有効期間 | 60分前後 | 認証方法登録や端末の復旧作業が終わる時間を見込んで短めに設定（ポリシーの許容範囲：10分〜30日） |
| コード長 | 8桁以上 | 長いほど安全だが、ユーザーが手入力しやすい範囲でバランスを取る |
| 対象ユーザー | 「TAP利用可能」専用グループのみ | 全ユーザーに開放せず、人事・ヘルプデスクなどが管理しやすい限定グループに絞る |
TAP運用時のセキュリティ注意点
- 配布チャネル
- メールやチャットなど、盗聴されやすい経路でTAPを送る場合は、必ず社内規程を決めておく
- できれば、TAPを表示した画面を端末越しに見せる／電話口で読み上げるなど、第三者に残りにくい方法を選ぶ
- 多回使用TAPは避ける
- マイクロソフトのゼロトラスト推奨事項でも、TAPは単回利用が推奨されている
- 期限＝トークン寿命
- TAPで取得したトークンの寿命はTAPの寿命に縛られるため、短期間で切れるように設計する
- NPS拡張・AD FSとは非連携
- VPNなどRADIUS経由でMFAを使う NPS 拡張や、AD FS アダプター経由のシナリオでは TAP を使えない点に注意
最小構成で進めるための具体的ステップ
ここまでの内容を踏まえて、「とりあえずこれさえやっておけば安全に運用開始できる」という最小構成の道筋をステップ形式でまとめます。
ステップ1：ライセンス状況の確認と整備
- Microsoft Entra 管理センターで
- 「課金 & ライセンス」や Microsoft 365 管理センターから、保有しているサブスクリプションを確認
- 次のいずれかを満たすようにライセンスを準備
- Microsoft 365 Business Premium（Entra ID P1 含む）
- Microsoft 365 E3（Entra ID P1 含む）
- Entra ID P1 単体ライセンスを必要ユーザー数分
- Business Basic / Standard のみでは条件付きアクセスが使えない点に注意
| プラン | Entraエディション | 条件付きアクセス | 備考 |
|---|---|---|---|
| Microsoft 365 Business Basic | Entra ID Free | ×（利用不可） | Security Defaults のみ |
| Microsoft 365 Business Premium | Entra ID P1 | ○ | 中小企業での標準構成に最適 |
| Microsoft 365 E3 | Entra ID P1 | ○ | 大企業向けの一般的構成 |
| Microsoft 365 E5 | Entra ID P2 | ○ | Identity Protection 等を活用可能 |
ステップ2：Security Defaults から条件付きアクセスへの移行方針を決める
「一時的なMFA回避」を含めた柔軟なポリシー運用をする場合、Security Defaults は無効化し、条件付きアクセスへ移行するのが基本です。
- 現状 Security Defaults が有効かどうかを確認
- 有効な場合：
- まず条件付きアクセスのテンプレートを用いて「Require MFA for all users」など推奨ポリシーを作成し、Report-only モードで影響を確認
- 問題がないことを確認した上で Security Defaults を無効化し、条件付きアクセス ポリシーを本番適用
ステップ3：MFA要求の基本ポリシーを条件付きアクセスで作る
まずは「すべてのユーザーに強力な認証を要求する」ベースラインポリシーを作成します。
- Entra 管理センターで
- Entra ID > 条件付きアクセス > ポリシー に移動
- 「新しいポリシー」またはテンプレートから「Require MFA for all users」をベースにポリシーを作成
- ユーザー
- 「すべてのユーザー」を含める
- 除外として「緊急用（ブレークグラス）アカウント」だけを指定
- クラウドアプリ
- 当面は「すべてのクラウドアプリ」で問題ないケースが多い
- 検証フェーズでは代表的なアプリ（Microsoft 365など）に絞ってもよい
- アクセス制御（Grant）
- 「アクセスを許可」＋「多要素認証を要求」または「認証強度：多要素認証」を選択
- 最初は「Report-only」で影響を確認し、問題なければ「オン」に切り替える
ステップ4：Authentication methods policy の整備（旧ポリシーからの移行）
- Entra 管理センターで
- Entra ID > 認証方法 > ポリシー に移動
- 利用したい認証方法（例：Microsoft Authenticator、FIDO2 セキュリティキー、パスキー、SMS／音声など）を有効化し、対象ユーザー／グループを定義
- 可能な場合、旧MFA/SSPRポリシーからの移行ウィザードを用い、2025年9月30日までに移行を完了させる
ステップ5：Temporary Access Pass ポリシーを有効化
- Entra 管理センターで
- Entra ID > 認証方法 > ポリシー > Temporary Access Pass を選択
- ポリシーを 有効 にし、対象ユーザー／グループとして「TAP利用者グループ」を指定
- 前述の推奨設定に合わせて
- 有効期間（例：60分）
- ワンタイム利用を許可
- 最小／最大の許容範囲
- コード長（例：8桁）
ステップ6：TAP発行フロー（ヘルプデスク手順）を標準化
ユーザーから「スマホが使えない」「MFAで詰まった」と問い合わせが来たとき、毎回担当者が悩まなくて済むよう、TAP発行の標準手順書を作っておくと運用負荷が下がります。
- 本人確認
- 社内規程に基づき、電話口での質問や上長確認などで本人確認を実施
- 管理者がTAPを発行
- Entra ID > ユーザー > 対象ユーザー > 認証方法 を開く
- 「認証方法の追加」から「Temporary Access Pass」を選択し、ワンタイムTAPを生成
- 有効期限とコードをユーザーに伝達
- ユーザー側の操作
- ブラウザでサインイン画面を開き、ユーザーIDとパスワードを入力
- MFAが求められる場面で「別の方法でサインイン」などを選択し、TAPを使用
- サインイン後にすぐ恒久的な認証手段を登録
- FIDO2 セキュリティキーやパスキー、Authenticator アプリなど
ステップ7：TAP利用後はフィッシング耐性の高い認証へ切り替え
TAPはあくまで「ブートストラップ用」の一時クレデンシャルです。サインイン後は、できるだけフィッシング耐性の高い認証方法へ切り替えることが重要です。
- 推奨される優先順位の一例
- FIDO2 セキュリティキー / パスキー（プラットフォーム／クロスプラットフォーム）
- Windows Hello for Business（対応デバイス）
- Microsoft Authenticator アプリ（番号マッチング＋プッシュ通知）
- SMS / 音声通話（どうしても必要な場合のみ）
条件付きアクセスの「認証強度」ポリシーを活用し、「管理者はフィッシング耐性のあるMFAのみ許可」といった制御も可能です。
ステップ8：可視化と継続的な見直し
運用が回り始めたら、次のようなレポートで「どの認証方法がどれだけ使われているか」「TAPがどのくらい発行されているか」を定期的に確認すると、ポリシー改善のヒントが得られます。
- Authentication Methods Activity
- どの認証方法がどれくらい登録／利用されているか
- MFA・パスワードレス・SSPRの登録状況
- サインインログ
- MFAが要求された／成功したイベント
- どの認証方法（TAP含む）が使われたか
- Usage & insights
- アプリ別のサインイン状況や失敗率
- 認証方法別の利用傾向
これらの詳細なレポートを見るには Entra ID P1 または P2 ライセンスが必要です。
よくあるつまずきとアンチパターン
Per-user MFA を条件付きアクセスと併用してしまう
Entra ID Free 時代からの名残で、Per-user MFA が有効になったまま条件付きアクセスでMFAを要求しているケースは非常に多く、トラブルの元です。
- ユーザーによって挙動が変わり、「同じポリシーのはずなのに、この人だけ毎回MFAを聞かれる」といった混乱を招く
- ポリシーの影響範囲が読みにくく、トラブルシュートも難しい
方針：
- 条件付きアクセスでMFAを運用する場合は、Per-user MFAは「無効」に戻す
- Authentication methods policy に一本化し、MFA要求は条件付きアクセスで制御
Security Defaults と条件付きアクセスを併用しようとする
「Security Defaults でMFAを担保しつつ、一部だけ条件付きアクセスで特別扱いしたい」という発想は一見合理的ですが、仕組み上うまくいきません。
- Security Defaults が有効なテナントでは、条件付きアクセス ポリシーをオンにできない
- 例外を作りたい場合は、Security Defaults を無効化し、条件付きアクセス側で
- 「すべてのユーザーへのMFA必須」
- 「一部ユーザーは一時的に除外」
「TAPを長期間・何度も使えるようにする」
運用を楽にするために、「TAPの期間を30日にして、複数回利用可にしよう」とすると、それはほぼ「弱いパスワードを1つ追加した」のと変わらない状態になります。
- 漏えい時に攻撃者が何度でもログインできる
- 攻撃者がTAPを使って他の強力な認証方法を登録し、しれっと常駐するリスク
そのため、TAPは短期間＋ワンタイム利用を基本とし、管理者も「発行しっぱなし」にならないようログを定期的にチェックすることが推奨されます。
2025年9月30日ギリギリまで旧MFA/SSPRポリシーのまま放置
レガシーなMFA/SSPRポリシーで認証方法を管理する機能は、2025年9月30日で無効化される予定です。
- 期日を過ぎると、旧ポリシー側の設定はグレーアウトされ、Authentication methods policy 側だけが有効になる
- 期日ギリギリで移行すると、「誰がどの方法でMFAできるのか」が読めず、障害につながる可能性がある
早めにテスト用グループから Authentication methods policy への移行を進め、本番でも余裕を持って切り替えることをおすすめします。
まとめ：必要な契約と一時的MFA回避のベストプラクティス
最後に、本記事で扱ったポイントを整理します。
- どの契約が必要か？
- MFAを条件付きアクセスで柔軟に制御したいなら、Microsoft Entra ID P1が最低ライン
- P1は Microsoft 365 E3 / Business Premium などに含まれており、多くの企業テナントの現実的な選択肢
- リスクベースMFAなど高度な保護を行いたい場合は Entra ID P2 を検討
- ポリシーの置き場所は？
- 2025年9月30日以降は、MFA/SSPRの管理をレガシーポリシーで行えなくなる
- Authentication methods policy ＋ 条件付きアクセスが今後の標準構成
- 「一時的にMFAを回避したい」時の正しいアプローチは？
- MFAや条件付きアクセスを無効化／除外するのではなく、Temporary Access Pass（TAP）を使う
- TAPは「時間制限付き・強力なクレデンシャル」であり、パスワードレスやMFAの安全な初期登録・復旧手段として設計されている
- ワンタイム利用＋短い寿命＋限定グループを基本として設計する
- 運用のゴール
- 全ユーザーが少なくとも強力な認証方法を1つ以上登録している状態を作る
- 最終的には FIDO2 セキュリティキー／パスキー／Windows Hello for Business などのフィッシング耐性の高い方式を標準にする
- TAPは「どうしても必要な時にだけ使う非常口」として位置づける
この方針に沿って構成しておけば、「どのライセンスが必要かわからない」「スマホが使えないユーザーのためにMFAを切らざるを得ない」といった悩みから解放され、Microsoft Entra ID を前提としたゼロトラスト時代の認証基盤にスムーズに移行できます。
社内標準として落とし込みたい場合は、本記事のステップをベースに「自組織向けチェックリスト」や「ヘルプデスク用 TAP 発行手順書」を作成しておくと、運用チームにとってもユーザーにとっても負担の少ない仕組みになります。
コメント