2025年9月30日の「レガシーMFA／SSPR（セルフサービス パスワード リセット）ポリシー」廃止と、同年10月以降に段階適用される「必須MFA（Mandatory MFA）」は、サインイン設計と運用プロセスに直撃します。とくに共有ID（共通業務アカウント）やADAL／WAMを無効化して旧来の挙動に寄せている端末は、切り替え直後に業務停止を招きかねません。本記事では、廃止対象の正体、猶予の有無、共有IDの扱い、レジストリ小細工の末路、そして確実に乗り切るための移行手順を、実務目線でまとめました。
レガシーMFA／SSPRポリシー廃止と共有IDの扱い
まず押さえるべき要点は、「廃止されるのは“サインインそのもの”ではなく、認証方法の管理ポリシー（旧MFA／SSPRの管理面）」だという点です。2025年9月30日以降、レガシー画面からの登録・変更はできず、管理はAuthentication Methods Policy（AMP）へ一本化されます。移行しないままでは、端末交換時や方法再登録時に詰みます。
| 要点 | 解説・対策 |
|---|---|
| 廃止対象は「認証方法の管理ポリシー」 | 9/30 以降、旧MFA／SSPRの管理UIでは登録・変更が不可。管理はAMPに統合される。認証フローが即停止するわけではないが、再登録や新規の手当てができなくなり運用が行き詰まる。 対応：Entra 管理センターの移行ウィザード（Manage migration）で段階移行。 |
| 共有ID（パスワード共用アカウント）は高リスク | 個別追跡性がなく、MFA強制や監査の観点で不適。やむを得ず残す場合でも、FIDO2 セキュリティキーやTAP等の個別要素を紐づけられないと運用不能に陥る。可能ならワークロードID（サービス プリンシパル／マネージドID）へ置換。 |
| 延長・猶予の扱い | レガシーMFA／SSPRの管理機能廃止について、現時点でMicrosoftの公的な延長アナウンスはありません。猶予を前提にせず、期日までにAMPへ移行する計画を。 |
| ADAL／WAM無効化のレジストリ小細工 | DisableADALatopWAMOverride や DisableAADWAM などで旧挙動に寄せる運用は非推奨・非サポート。加えて、10月以降の必須MFAはクライアント側の旧式フローで迂回できない（ARM層で検査）。 |
| 移行手順の入口 | Entra 管理センター → Authentication methods → Policies → Manage migration。移行ウィザードで旧設定を棚卸しし、AMPへ統合。 |
よくある質問と回答
- MFAを構成していない共有IDはサインインできなくなるのか？
「共有IDという形態」自体は直ちに無効化されませんが、2025年10月以降はAzureの作成／更新／削除操作にはMFAが必須。共有IDに方法が1つも登録されていないと業務が止まります。設計としては、共有IDを使わず個人ID＋権限委任またはワークロードIDに転換するのが安全です。 - Exchange Online Basic Auth 廃止のときのような一時延長はある？
レガシーMFA／SSPRの管理廃止に関しては公的な延長案内なし。一方で、10月以降の必須MFA（Phase 2）については、Azureポータルからテナント単位で施行日を後ろ倒しできる「ポストポーン（postpone）」の選択肢が案内されています（影響精査と準備時間の確保が目的）。 - レジストリでADAL／WAMを無効化して旧認証を維持している端末はどうなる？
WAMやADALの無効化はサポート外で、将来の認証イノベーションはWAM経由で実装されます。加えて、必須MFAはAzure Resource Manager層での検査となるため、端末側の回避で免れることはできません。速やかに既定のモダン認証＋AMPへの登録に戻しましょう。
期限までに移行しなかった場合の具体的な影響
| 影響 | 詳細 | 想定発生タイミング | 即時対策 |
|---|---|---|---|
| 旧UIが管理不能 | MFA／SSPR旧画面は事実上Read-Onlyに。新規登録・削除・再登録が不可。端末交換や電話番号変更時に手当てできずサインイン不能に。 | 2025/9/30 以降 | AMP側で必要メソッド（Authenticator、FIDO2、TAPなど）を事前登録／許可。移行ウィザードで設定の読み替え。 |
| 方法未登録ユーザーはロックアウト | パスワード忘却や端末紛失時に復旧できず。管理者も旧UIから追加不可。 | 2025/9/30 以降（復旧イベント時） | TAP（Temporary Access Pass）を有効化して安全な代替サインイン経路を用意。 |
| 必須MFAフェーズで業務停止 | Azure CLI／PowerShell／REST等で作成・更新・削除を実行する全アカウントにMFAを要求。登録がなければ失敗。読み取りは対象外。 | 2025/10/1 以降（段階ロールアウト） | 準備が間に合わない場合はポータルで施行日を一時延期。ただし恒久策ではない。 |
必須MFA（Mandatory MFA）強制フェーズの正確な理解
Microsoftは2025年3月にAzureポータル等へのMFA強制（Phase 1）を完了し、2025年10月からPhase 2としてARM（Azure Resource Manager）層での強制へ移行しています。これにより、ポータル外のCLI／PowerShell／IaC／SDK／RESTも作成・更新・削除時にMFAを要求されます（読み取りは要求なし）。管理者ロールか否かは問いません。
| フェーズ | 対象と要件 | 開始 | 補足 |
|---|---|---|---|
| Phase 1 | Azure ポータル／Entra／Intune 等へのサインインでMFA必須 | 〜2025年3月に100%展開 | ロールに依存せず適用。 |
| Phase 2 | CLI・PowerShell・IaC・REST 等でCUD操作時にMFA必須（Readは除外） | 2025/10/1 から段階適用 | Azure Policyを通じて順次展開。必要に応じ施行日を延期可能。 |
重要なのは、ワークロードID（サービス プリンシパル／マネージドID）は必須MFAの対象外という点です。自動化やバッチはユーザーIDをやめ、証明書やシークレットによるアプリケーション認証へ移行しましょう。
また、緊急（ブレークグラス）アカウントも施行後はMFAが必要になります。FIDO2（パスキー）や証明書ベース認証を有効化し、MFA要件を満たせるよう事前に整備しましょう。
実務に効く移行ロードマップ（90日プラン）
準備：現状可視化（Day 0–7）
- Graph レポートで未登録ユーザーを抽出（
userRegistrationDetails）。 - 共有ID・自動化スクリプト・定期バッチでユーザーIDを使っている箇所を棚卸し（ワークロードIDへ移行候補）。
- ADAL／WAM無効化レジストリの配布有無を棚卸し（速やかに撤去計画）。
# 例：PowerShell（Microsoft Graph）
Install-Module Microsoft.Graph.Reports -Scope CurrentUser
Connect-MgGraph -Scopes "Reports.Read.All"
# MFA未登録者の洗い出し
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { $_.IsMfaRegistered -eq $false } |
Select-Object UserPrincipalName, IsMfaRegistered, DefaultMfaMethod |
Export-Csv .\MfaNotRegistered.csv -NoTypeInformation
※ 環境によってはベータ版の Get-MgBetaReportCredentialUserRegistrationDetail を使う場合があります。
設計：認証方法の標準（Day 8–21）
- 推奨セット：Microsoft Authenticator（通知／パスキー）＋FIDO2 セキュリティキー＋TAP（緊急・初期登録用）を少なくとも2要素。
- AMPで対象グループを定義し、方法ごとの許可・ブロックを設計。SMS／音声は撤退方針を検討。
- 共有IDは原則廃止。メール用途は共有メールボックス＋Send As/On Behalfで代替、スクリプトはワークロードIDへ。
実装：ウィザードで移行（Day 22–45）
- Entra 管理センター → Authentication methods → Manage migration を開始。旧設定を読み取り、AMPへ中間移行（Migration in progress）。
- パイロット グループで登録体験を検証：Authenticator のプッシュ、FIDO2 キー登録、TAP配布フロー。
- ADAL／WAM無効化レジストリを削除し、端末を標準構成へ復帰。
展開：本番切り替え（Day 46–75）
- AMPの対象を「全ユーザー」に拡大し、旧ポリシー側は無効化。
- Azure管理に関与するユーザーへ、MFA必須化の影響（CLIやIaCのCUD時）を周知。
- 自動化はユーザーID→ワークロードIDへ移行（証明書／マネージドID）し、人の対話が必要な操作のみMFAに。
安定化：施行直前の最終チェック（Day 76–90）
| チェック項目 | 合格基準 |
|---|---|
| 全ユーザーに2要素以上が登録済み | AMP レポートで 98%以上（残りはTAPで当日対応） |
| ブレークグラスのMFA準備 | FIDO2 または証明書でMFA満たす設定に。排他CAは可だがMFA自体の準備は必須。 |
| CLI／PowerShell／IaCの改修 | 対話操作→MFA、人手不要→ワークロードID。テスト記録あり。 |
| やむを得ない場合の施行延期 | Azureポータルでpostpone設定を確認し、期限と影響を周知。 |
共有ID（共通業務アカウント）をどう減らすか：安全な置き換えパターン
| 現状（よくある使い方） | 置き換え先 | ポイント |
|---|---|---|
| 自動スクリプト／ジョブ実行用の共有ID | ワークロードID（サービス プリンシパル／マネージドID） | ARMやGraphへのCUDもMFA対象外。権限は最小化し、証明書管理を徹底。 |
| チーム共通メール受信・送信 | 共有メールボックス＋個人IDに権限委任 | 監査性とトレーサビリティを担保。個人IDはAMPでMFA登録。 |
| 一時作業のための「全員が知るID」 | Privileged Access Group（PIM）＋個人ID昇格 | 昇格時にMFA。ログと承認の証跡が残る。 |
ADAL／WAM 無効化の“後始末”
過去のトラブル回避で DisableADALatopWAMOverride や DisableAADWAM を配っている環境は少なくありません。しかし、MicrosoftはADALやWAMの無効化をサポートしておらず、将来の認証機能はWAM経由で提供されます。必須MFAの適用対象はARM層であり、端末側のレジストリ設定でMFA要件を回避することはできません。ドキュメント化して撤去し、標準構成へ戻しましょう。
ユーザー登録体験を壊さない実装Tips
- TAPの常設：端末紛失や機種変更に備え、ヘルプデスクで発行できるTAPを常時有効化。一時的にサインインしてAuthenticator／FIDO2の再登録を促せます。
- FIDO2（パスキー）を第一候補に：個人用は「Authenticatorのパスキー」、共用端末前提は「セキュリティキー」を推奨。
- 登録方法の段階公開：AMPの対象グループを活用し、部門ごとにロールアウト。旧UIを参照していたガイドは刷新。
監査とモニタリング：やっておくべき可視化
# 1) MFA未登録・登録方法の集計
Connect-MgGraph -Scopes "Reports.Read.All"
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$report | Group-Object DefaultMfaMethod | Select Name, Count | Format-Table
# 2) 未登録ユーザー一覧を通知
$notRegistered = $report | Where-Object { -not $_.IsMfaRegistered } | Select UserPrincipalName
$notRegistered | Export-Csv .\alert-unregistered.csv -NoTypeInformation
上記は代表例です。運用では「未登録者の自動通知」「TAP発行手順のSOP化」「登録方法の偏り（SMS依存など）の是正」を定期ジョブ化しましょう。
失敗パターンと回避策
| ありがちな失敗 | 回避策 |
|---|---|
| 共有IDに誰もMFAを登録しておらず、CLI実行が止まる | 共有ID自体を廃止し、ワークロードIDへ移行。どうしても残すならFIDO2キーの物理保管と貸与簿を整備。 |
| ブレークグラスがMFA非対応で、トラブル時に管理センターへ入れない | FIDO2またはCBAでMFAを満たすよう事前登録。「CAからの除外」だけでは不十分。 |
| レジストリでWAMを止めた端末がサインイン不能 | 非サポート設定は撤去。標準のWAMベースに戻し、AMPで方法を配備。 |
まとめ：この5点だけは必ず実行
- 期日厳守：9/30 以降はレガシーMFA／SSPRの管理ができません。AMPへ統合。
- 共有IDの廃止・変換：ワークロードIDや共有メールボックス／権限委任に置き換え。
- 全ユーザーに強固な方法を2つ以上：Authenticator（パスキー）＋FIDO2＋TAP。
- レジストリ小細工の撤去：ADAL／WAM無効化はサポート外。
- 10月以降の必須MFAに備える：CLI・IaCのCUD操作はMFA前提。間に合わなければ「postpone」で時間を稼ぎつつ、恒久対策はワークロードIDへ。
この記事の内容は2025年11月時点の情報に基づくもので、今後のアナウンスで変更される可能性があります。公開情報とテナント内の通知（メッセージ センター）を定期確認し、計画を随時アップデートしてください。
コメント