Microsoft Entra IDでは、2026年9月1日からSMSまたは音声認証が有効なユーザーに対し、パスキーの自動有効化とRegistration Campaignによる登録案内が始まります。端末準備や利用者周知が間に合わない場合は、Microsoft Graph betaでpasskeyDynamicMigrationをtrueに設定すると、自動移行を一時停止できます。
ただし、この設定で得られるのは移行準備のための猶予です。2027年2月1日のMicrosoft提供SMS／音声認証の終了や、パスキー登録を求めるブロッキング動作は回避できません。設定後は安心して放置するのではなく、猶予期間中にパスキーなどへの移行を完了させる必要があります。(Microsoft Learn)
passkeyDynamicMigrationで一時停止できる範囲
Microsoft公式が案内している一時停止設定は、Microsoft Entra IDのauthentication methods policyにある次のプロパティです。
optOutSettings.passkeyDynamicMigration値をtrueにすると、テナントは一時的に次の自動処理から除外されます。
- SMSまたは音声認証が有効なユーザーに対するパスキーの自動有効化
- Microsoft管理によるRegistration Campaignへの自動追加
- MFA完了後に表示されるパスキー登録案内の自動展開
trueは「自動移行を有効にする」という意味ではありません。optOutSettingsの中にあるため、trueが自動移行からの除外を意味する点に注意してください。(Microsoft Learn)
Microsoft公式の時系列と、この設定が有効な範囲は次のとおりです。(Microsoft Learn)
| 時期 | Microsoft Entra IDの動作 | passkeyDynamicMigration: trueの効果 |
|---|---|---|
| 2026年9月1日より前 | 自動移行開始前の準備期間 | 事前に設定して自動展開を回避できる |
| 2026年9月1日から2027年1月31日まで | SMS／音声対象ユーザーのパスキー自動有効化とRegistration Campaign展開 | 自動有効化と自動キャンペーン展開からテナントを除外 |
| 2027年2月1日 | Microsoft提供のSMS／音声認証が終了 | 効果なし |
| 2027年2月1日以降 | SMS／音声しか利用できないユーザーにブロッキング登録を要求 | 回避不可 |
このPATCHは、あくまでMicrosoftによる自動ロールアウトから除外する設定です。既に登録されているパスキーを削除したり、利用者によるパスキー登録そのものを禁止したりする設定ではありません。
また、組織が独自に有効化したRegistration Campaignの対象範囲を自動的に元へ戻すとは説明されていません。既に手動設定している場合は、Registration Campaignの状態と対象グループも別途確認してください。
自動パスキー移行の対象になるユーザー
2026年9月1日の自動変更では、authentication methods policyまたは従来のMFA設定で、SMSか音声認証が有効になっているユーザーが対象になります。
対象ユーザーはパスキーを利用できる認証方法ポリシーへ追加され、Registration CampaignもMicrosoft管理の状態でパスキーを対象とするよう更新されます。対象ユーザーが次にサインインしてMFAを完了すると、パスキー登録を促す画面が表示されます。2027年2月1日より前の登録案内は、既定では繰り返し延期できます。(Microsoft Learn)
特に次の組織では、事前確認が必要です。
- SMSや音声認証を利用しているユーザーが残っている
- 許可するパスキーの種類を組織側で制御したい
- 共用端末や未管理端末が多い
- 利用者向けマニュアルや問い合わせ窓口を準備できていない
- 独自のRegistration Campaignを運用している
- SMS／音声認証を業務上継続する必要がある
なお、この移行時期はMicrosoft Entra IDのパブリッククラウドを対象としたものです。Azure AD B2Cは今回の対象外であり、Microsoft Entra External IDやその他のクラウド環境については別の案内を確認する必要があります。(Microsoft Learn)
Graph設定を実行する前に必要な権限
authentication methods policyを更新するには、Microsoft Graphの権限だけでなく、サインインするユーザー側のMicrosoft Entraロールも必要です。
| 確認項目 | 必要な内容 |
|---|---|
| Microsoft Graph API | Microsoft Graph beta |
| 委任されたアクセス許可 | Policy.ReadWrite.AuthenticationMethod |
| アプリケーションのアクセス許可 | Policy.ReadWrite.AuthenticationMethod |
| 最小権限のMicrosoft Entraロール | 認証ポリシー管理者 |
| HTTPメソッド | PATCH |
| Content-Type | application/json |
| 成功時のステータス | 200 OK |
認証ポリシー管理者は、この更新操作でサポートされる最小権限の組み込みロールです。グローバル管理者を常用するのではなく、可能な限り必要最小限のロールで実施してください。(Microsoft Learn)
今回の設定ではMicrosoft公式がbetaエンドポイントを指定しています。一方、Microsoft Graphのbeta APIは仕様変更の可能性があり、一般的な本番アプリケーションへの組み込みは推奨されていません。実行直前に公式情報を再確認し、変更前後のJSONと応答内容を保存しておくことが重要です。(Microsoft Learn)
Graph Explorerで自動パスキー移行を一時停止する方法
変更前のポリシーを取得する
最初に、対象テナントへサインインしていることを確認します。複数テナントを管理している場合は、Graph Explorer上に表示されるテナントを必ず確認してください。
HTTPメソッドをGETにして、次の要求を実行します。
GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicy返却されたJSONは、変更前の記録として保存します。特に次の項目を控えておくと、変更履歴を確認しやすくなります。
lastModifiedDateTimeregistrationEnforcementauthenticationMethodConfigurationsoptOutSettings- 実行した日時
- 実行者
- 対象テナントID
Graph Explorerで組織アカウントを使用してPATCHなどの書き込み要求を実行すると、実際のテナント設定が変更されます。検証用テナントがある場合は、先に同じ要求を試しておくと安全です。(Microsoft Learn)
passkeyDynamicMigrationをtrueに設定する
HTTPメソッドをPATCHへ変更し、次の要求を実行します。
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}要求本文には、変更するoptOutSettingsだけを含めます。GETで取得したポリシー全体をそのままPATCH本文へ貼り付ける必要はありません。
Graph Explorerで権限不足が表示された場合は、［Modify permissions］またはアクセス許可への同意画面から、次の権限へ同意します。
Policy.ReadWrite.AuthenticationMethod権限への同意だけではなく、サインインしているユーザーに認証ポリシー管理者などの対応ロールが割り当てられていることも必要です。(Microsoft Learn)
200 OKと設定値を確認する
要求が正常に処理されると、200 OKが返されます。応答JSONや応答ヘッダーも変更記録として保存してください。(Microsoft Learn)
続けて、もう一度GET要求を実行します。
GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicy返却JSONにoptOutSettingsが含まれる場合は、次の状態になっていることを確認します。
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}200 OKだけを画面上で確認して終了するのではなく、実行日時、対象テナント、要求本文、応答、変更管理番号をまとめて保存しておくと、後から設定経緯を追跡できます。
PowerShellでpasskeyDynamicMigrationを設定する方法
Microsoft Graph PowerShell SDKを利用している場合は、Invoke-MgGraphRequestから同じPATCH要求を送信できます。Invoke-MgGraphRequestは、専用コマンドレットが用意されていないGraph APIに対しても、GETやPATCHなどのREST要求を実行できます。(Microsoft Learn)
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$uri = "https://graph.microsoft.com/beta/policies/authenticationmethodspolicy"
$body = @{
optOutSettings = @{
passkeyDynamicMigration = $true
}
}
$response = Invoke-MgGraphRequest `
-Method PATCH `
-Uri $uri `
-Body $body `
-ContentType "application/json" `
-StatusCodeVariable statusCode
Write-Host "HTTP status: $statusCode"
$response | ConvertTo-Json -Depth 10実行後はGET要求でポリシーを再取得します。
$policy = Invoke-MgGraphRequest `
-Method GET `
-Uri $uri
$policy | ConvertTo-Json -Depth 10該当プロパティが返却される場合は、次のコマンドでも確認できます。
$policy.optOutSettings.passkeyDynamicMigration結果がTrueになっていることを確認します。
PowerShellで別のMicrosoft Graph権限を使って接続済みの場合は、必要なスコープがアクセストークンに含まれていないことがあります。その場合は一度接続を解除し、必要なスコープを指定して再接続します。
この設定で止まるものと止まらないもの
passkeyDynamicMigrationを設定する際に最も重要なのは、効果の範囲を誤解しないことです。(Microsoft Learn)
| 項目 | 一時停止できるか | 補足 |
|---|---|---|
| SMS／音声対象ユーザーへのパスキー自動有効化 | できる | オプトアウト期間中の自動展開から除外 |
| Registration Campaignへの自動追加 | できる | Microsoftによる自動ロールアウトを停止 |
| 既存パスキーの利用 | 停止しない | 登録済みパスキーを削除する設定ではない |
| 手動で設定したRegistration Campaign | 別途確認 | 自組織の既存設定を巻き戻すとは限らない |
| Microsoft提供SMS／音声認証の終了 | できない | 2027年2月1日に終了 |
| SSPRにおけるMicrosoft提供SMS／音声の終了 | できない | SMS／音声終了はEntra全体に影響 |
| 2027年2月1日以降のブロッキング登録 | できない | 全テナントに適用され、オプトアウト不可 |
| 顧客管理の通信事業者への移行 | 別の対応 | SMS／音声を継続する場合の別ルート |
2027年2月1日時点でMicrosoft管理のSMSまたは音声認証しか利用できず、顧客管理の通信事業者も設定していないユーザーは、従来どおりSMSや音声でMFAを完了できなくなります。
利用可能なMFA方法がSMSまたは音声だけの場合は、サインインを継続するためにパスキー登録を求められます。この画面はブロッキング形式で、登録を延期して先へ進むことはできません。(Microsoft Learn)
設定時に失敗しやすいポイント
v1.0ではなくbetaを使用する
今回の公式手順で指定されているエンドポイントは、次のbeta APIです。
https://graph.microsoft.com/beta/policies/authenticationmethodspolicyv1.0へ置き換えて実行すると、optOutSettingsやpasskeyDynamicMigrationが認識されない可能性があります。今回の一時オプトアウトでは、Microsoft公式に記載されたbetaエンドポイントを使用してください。(Microsoft Learn)
Graph権限とEntraロールを混同しない
403 Forbiddenが返る場合は、次の両方を確認します。
- Graph Explorerやアプリに
Policy.ReadWrite.AuthenticationMethodが付与されているか - 実行ユーザーに認証ポリシー管理者などの対応ロールがあるか
Graph APIのアクセス許可だけを付与しても、実行ユーザー側のディレクトリロールが不足していれば更新できません。(Microsoft Learn)
対象テナントを取り違えない
Graph Explorerでは、現在サインインしているアカウントとテナントを確認できます。委託先や複数組織のテナントを管理している場合は、PATCH実行前にテナントIDまで記録してください。(Microsoft Learn)
9月1日以降に設定しても元へ戻るとは限らない
Microsoft公式は、この設定を自動ロールアウトからの除外方法として説明していますが、既に適用されたパスキー有効化やRegistration Campaignの変更を自動的に巻き戻すとは説明していません。
一時停止が必要と判断した場合は、2026年9月1日より前に設定するのが安全です。既に自動変更が始まっている場合は、パスキーの対象ポリシーとRegistration Campaignの現在値を個別に確認してください。
一時停止を移行中止として扱わない
この設定の効果は2027年2月1日以降の強制動作には及びません。途中で自動移行を再開するために値をfalseへ戻す運用についても、実施時点のMicrosoft公式仕様を確認してから行う必要があります。
猶予期間中に完了させるべき移行作業
自動移行を一時停止した場合は、2027年2月1日を最終期限として扱うのではなく、組織内でそれより早い完了日を設定します。
SMS／音声対象ユーザーを把握する
authentication methods policyと従来のMFA設定を調査し、SMSまたは音声認証が有効なユーザーを一覧化します。
対象者を一括で扱うのではなく、次のように分類すると移行計画を作りやすくなります。
- 組織管理のWindows端末を利用しているユーザー
- iPhoneやAndroidを業務利用しているユーザー
- 共用端末を利用しているユーザー
- スマートフォンを所持していないユーザー
- 外部委託先やゲストユーザー
- SMS／音声を業務上残す必要があるユーザー
移行先の認証方法を決める
Microsoftは、パスキー、Windows Hello for Business、FIDO2など、フィッシング耐性のある認証方法への移行を案内しています。SMSや音声が業務上必要な場合は、顧客管理の通信事業者を利用する方法を別途検討します。(Microsoft Learn)
端末条件や業務形態によって適切な方法は異なります。全員を同じ方法へ移行させるのではなく、端末と利用場面ごとに標準方式と例外方式を決めておくと運用しやすくなります。
小規模グループで登録を検証する
最初から全ユーザーを対象にせず、情報システム部門や協力部署で次の項目を確認します。
- パスキーを正常に登録できるか
- 登録後に主要な業務サービスへサインインできるか
- 機種変更や端末故障時の復旧手順が明確か
- ヘルプデスクが登録画面を案内できるか
- 共用端末や未管理端末で問題がないか
利用者への案内と問い合わせ対応を準備する
パスキー登録画面が突然表示されると、利用者はフィッシング画面や端末故障と誤解する可能性があります。
周知文には、少なくとも次の内容を入れます。
- 変更理由
- 登録開始日
- 対象者
- 登録する認証方法
- 画面を延期できる期間
- 問い合わせ先
- 登録に失敗した場合の対応
2027年2月1日より前にSMS／音声依存を解消する
最終確認では、ポリシー上で有効かどうかだけでなく、ユーザーが実際に代替手段を登録し、利用できているかを確認します。
「パスキーを有効にした」だけでは、移行完了とはいえません。登録状況と利用状況を確認し、SMSまたは音声しか使えないユーザーを期限前にゼロにすることが重要です。
自動移行を止める場合も移行計画は止めない
Entraのパスキー自動移行を一時停止するには、Microsoft Graph betaでauthentication methods policyをPATCHし、optOutSettings.passkeyDynamicMigrationをtrueに設定します。
{
"optOutSettings": {
"passkeyDynamicMigration": true
}
}これにより、2026年9月1日から始まるパスキーの自動有効化とRegistration Campaignの自動展開を一時的に回避できます。
一方、2027年2月1日のMicrosoft提供SMS／音声認証終了と、SMS／音声しか利用できないユーザーへのブロッキング登録は回避できません。設定前のポリシーを保存したうえで早めにPATCHを実行し、猶予期間中に対象者の洗い出し、パスキーの試行、利用者周知、登録完了の確認まで終わらせてください。
コメント