2026年4月30日にMicrosoftDocs/entra-docsで反映された「accepting all copilot suggestions per the author」は、Microsoft Entraそのものに新機能が追加されたというより、Combined Registrationのセッション制御に関する公式説明が整理された更新です。確認すべき結論は、パスキー（FIDO2）登録時の「直近5分以内の強い認証」、My Sign-insや資格情報管理時の「直近10分以内のMFA」、そしてConditional AccessのAuthentication Strengthsが衝突していないかです。(GitHub)
特に、security admins、compliance teams、enterprise IT readersにとって重要なのは、「Copilot」というコミット名そのものではありません。実務上は、ユーザーがセキュリティ情報を登録・変更できない、パスキー展開で想定外のエラーが出る、監査上の認証強度要件とユーザー体験が噛み合わない、といった運用影響を事前に見つけることが重要です。
Microsoft Entraの公式ドキュメント更新で何が変わったか
今回のコミットは、MicrosoftDocs/entra-docsリポジトリ内の docs/identity/authentication/concept-registration-mfa-sspr-combined.md を対象にした更新です。GitHub上の差分では、1ファイルに対して7行追加・3行削除が行われ、対象箇所は「Session controls for Combined Registration」です。(GitHub)
重要なのは、更新内容が「Microsoft Entraの新しい設定画面が追加された」「Copilot機能がEntraに統合された」という話ではない点です。コミットメッセージにはCopilotの共同作成者表記がありますが、差分の中身はCombined Registration、MFA、FIDO2、Authentication Strengths、Conditional Accessの説明整理です。(GitHub)
| 確認ポイント | 更新の意味 | 実務上の重要度 |
|---|---|---|
MFA capable が MFA-capable に変更 | 表記の修正 | 低い |
sign-in が sign in に変更 | 英文表現の修正 | 低い |
| Authentication Strengthsとの競合説明が整理 | 5分・10分の認証鮮度要件と、セキュリティ情報登録ポリシーの関係が読みやすくなった | 高い |
| 対応策がテナントレベル・ユーザーレベルに分けられた | 管理者がどこを変更すべきか判断しやすくなった | 高い |
つまり、この更新は仕様変更の発表というより、既存仕様を運用担当者が誤解しにくい形に整理した公式ドキュメント更新として読むのが適切です。
確認すべき中心はCombined Registrationのセッション制御
Microsoft EntraのCombined Registrationは、MFAとSSPRのセキュリティ情報登録をまとめて扱う仕組みです。Microsoft Learnでは、ユーザーが一度の登録でMFAとSSPRの両方に必要な情報を登録できると説明されています。(Microsoft Learn)
今回の更新箇所で特に見るべきなのは、次の3つです。
- Combined Registrationでは、MFAに対応したユーザーがセキュリティ情報を登録・管理する前に強い認証を求められる
- パスキー（FIDO2）を追加・変更する場合、直近5分以内に強い認証が完了している必要がある
- 2025年8月25日以降、資格情報の管理やMy Sign-insへのアクセス時に、現在のセッションで直近10分以内にMFAを完了していない場合はMFAが必要になる
これらの要件に加えて、Conditional Accessで「Register security info」ユーザーアクションにAuthentication Strengthsを適用していると、ユーザーが求められた認証方法を満たせず、セキュリティ情報の登録や変更で詰まる可能性があります。(Microsoft Learn)
「5分」と「10分」を混同しない
運用で失敗しやすいのは、「MFA済みだから大丈夫」と一括りに判断してしまうことです。
FIDO2パスキーの追加・変更では、直近5分以内の強い認証が求められます。一方、My Sign-insや資格情報管理では、直近10分以内にMFAを完了しているかが関係します。どちらも「最近MFAしたか」という話に見えますが、対象操作と時間条件が異なります。(Microsoft Learn)
| 条件 | 対象操作 | 管理者が見るべき点 |
|---|---|---|
| 直近5分以内の強い認証 | パスキー（FIDO2）の追加・変更 | FIDO2展開時のユーザー手順、TAP利用、Windows Hello for Business登録フロー |
| 直近10分以内のMFA | 資格情報管理、My Sign-insアクセス | セッション継続時間、サインイン頻度、ユーザーへの再認証案内 |
| Authentication Strengths | Register security infoへのConditional Access適用 | ユーザーが要求された認証方法を実際に持っているか |
セキュリティを強めるほど安全になる、という単純な話ではありません。ユーザーがまだフィッシング耐性のある方法を登録していない段階で、その方法を登録に必須化すると、登録前に登録済みの強い方法を求める「入口の詰まり」が起こります。
影響を受けやすいテナント
今回のMicrosoft Entra公式ドキュメント更新で特に確認したいのは、次のようなテナントです。
| テナントの状態 | 起こりやすい問題 | 確認すべき設定 |
|---|---|---|
| パスキー（FIDO2）やWindows Hello for Businessを展開中 | ユーザーが登録途中で再認証を求められる | Authentication methods policy、TAP、登録手順 |
| Register security infoにConditional Accessを適用している | セキュリティ情報登録時に認証強度を満たせない | Target resourcesのUser actions、Grant controls |
| Authentication Strengthsを厳格に使っている | 既存のMFA方法では登録画面に進めない | built-in/custom authentication strengthの対象方法 |
| グローバル企業でユーザー環境が分散している | 地域・端末・ネットワークごとに再現性が異なる | trusted locations、デバイス準拠、例外グループ |
| 監査対応でMFA証跡を厳密に見ている | 「MFA済み」の定義が運用手順とずれる | サインインログ、Report-only結果、手順書 |
Microsoft Learnでは、セキュリティ情報登録をConditional Accessで保護する場合、Target resourcesのUser actionsで「Register security information」を対象にできると説明されています。また、ポリシー作成時にはReport-onlyで確認してから有効化する流れが示されています。(Microsoft Learn)
Authentication Strengthsを使っている場合の確認ポイント
Authentication Strengthsは、Conditional Accessで「どの認証方法の組み合わせならアクセスを許可するか」を制御するための仕組みです。Microsoft Learnでは、組み込みの認証強度としてMFA strength、Passwordless MFA strength、Phishing-resistant MFA strengthなどが説明されています。(Microsoft Learn)
たとえば、Phishing-resistant MFA strengthでは、Windows Hello for Business、FIDO2セキュリティキー、証明書ベース認証などが該当します。(Microsoft Learn)
ここで注意したいのは、セキュリティ情報登録を守るためにフィッシング耐性のある認証を必須化した結果、まだその方法を持っていないユーザーが登録画面に到達できなくなるケースです。
典型的な失敗例
新入社員にFIDO2セキュリティキーを配布し、初回サインイン後にSecurity infoから登録してもらう運用を考えます。
このとき、Register security infoに対するConditional AccessでPhishing-resistant MFA strengthを要求していると、ユーザーはFIDO2を登録する前にフィッシング耐性のある認証を求められる可能性があります。結果として、本人は正しい手順で登録しようとしているのに、登録前の段階で認証要件を満たせません。
この状況では、次のような対応を検討します。
- 初回登録用にTemporary Access Passを使う
- パイロットグループから段階的に適用する
- Register security infoのポリシーをReport-onlyで検証する
- ユーザーが持っている認証方法とAuthentication Strengthsの要件を突き合わせる
- Windows Hello for BusinessやFIDO2の登録済みユーザーと未登録ユーザーを分けて制御する
Temporary Access Passは、パスワードレス認証方法をオンボードするための時間制限付きパスコードとして説明されており、セキュリティ情報登録時のMFA要件を満たす用途でも使われます。(Microsoft Learn)
テナントレベルで確認する設定
今回の更新では、対応策がテナントレベルとユーザーレベルに整理されています。テナントレベルでは、Register security infoに対して「Sign-in frequency: Every time」を強制する、またはWindows Hello for Businessユーザー向けにパスキーを有効化する、といった方向性が示されています。(Microsoft Learn)
ただし、Sign-in frequencyをEvery timeにする場合は慎重に扱う必要があります。Microsoft Learnでは、Every timeが選択された場合でも5分の許容が考慮されること、過度な再認証プロンプトは生産性低下やユーザーが意図しないMFA承認を行うリスクにつながるため、特定の業務要件がある場合に使うべきだと説明されています。(Microsoft Learn)
| 確認項目 | 推奨される見方 |
|---|---|
| Register security infoを対象にしたConditional Access | 対象ユーザー、除外ユーザー、Grant control、Session controlを確認 |
| Authentication Strengths | 要求している認証方法をユーザーが登録済みか確認 |
| Sign-in frequency | Every timeを使う必要が本当にあるか確認 |
| Authentication methods policy | FIDO2、Windows Hello for Business、TAPの対象グループを確認 |
| trusted locations | 社内ネットワーク前提の登録手順になっていないか確認 |
| emergency access accounts | ロックアウト防止の除外があるか確認 |
Conditional Accessは柔軟な一方で、設計を誤ると意図しない結果を招きます。Microsoft Learnでも、ポリシーの影響を理解するためにReport-only modeを使い、緊急アクセスアカウントを除外することが推奨されています。(Microsoft Learn)
ユーザーレベルで確認する設定
ユーザーレベルでは、対象ユーザーが「直近10分以内のセッション」を持っているか、または強制されているAuthentication Strengthsに含まれる認証方法の組み合わせで認証できるかを確認します。(Microsoft Learn)
管理者が見るべきポイントは、単に「MFAが有効か」ではありません。次のように、ユーザーの状態を分けて確認します。
| ユーザー状態 | 確認すべきこと | 対応例 |
|---|---|---|
| 既にFIDO2やWindows Hello for Businessを登録済み | 要求されるAuthentication Strengthsを満たせるか | 対象ポリシーに含める |
| MFAはあるがフィッシング耐性のある方法が未登録 | 登録前に強い認証を要求していないか | TAPや段階適用を使う |
| 新入社員・端末交換ユーザー | 初回登録フローが10分を超えないか | 手順短縮、TAPの有効期間設計 |
| リモートユーザー | trusted location前提の登録になっていないか | 場所条件の見直し |
| B2B/ゲストユーザー | 登録制御がゲストの実態に合うか | 外部ユーザー用ポリシーを分離 |
特にパスワードレス展開では、登録手順そのものが長くなりがちです。Temporary Access Passを使ったデバイス登録やWindows Hello for Business登録では、単回使用TAPと10分要件の関係も確認が必要です。Microsoft Learnでは、単回使用TAPでパスワードレス方法を登録する場合、サインインから10分以内に登録を完了する必要があると説明されています。(Microsoft Learn)
監査・コンプライアンス担当が見るべき点
compliance teamsが今回の更新を見る場合、技術設定そのものよりも、認証要件の説明責任を確認するのが実務的です。
具体的には、次の3点をドキュメント化しておくと、監査対応で説明しやすくなります。
| 観点 | 記録しておく内容 |
|---|---|
| 認証強度の根拠 | どのAuthentication Strengthsを、どのユーザー・操作に適用しているか |
| 例外の根拠 | emergency access accounts、ゲスト、新入社員、移行対象ユーザーの扱い |
| ユーザー影響の管理 | Report-only結果、サインインログ、ヘルプデスク問い合わせ、段階展開の記録 |
「強い認証を要求している」と言うだけでは不十分です。どの操作で、どの認証方法を、どのタイミングで要求しているかを説明できる状態にしておくことが大切です。
たとえば、Register security infoにPhishing-resistant MFA strengthを適用している場合、未登録ユーザーがどうやって最初の強い認証方法を登録するのかを示す必要があります。TAPを使うなら、発行権限、有効期間、単回使用か複数回使用か、配布手順、失効手順まで運用文書に含めるべきです。
移行準備として確認したいAuthentication methods policy
今回の更新をきっかけに、Authentication methods policyへの集約状況も確認しておくと安全です。Microsoft Learnでは、Authentication methods policyがパスワードレス認証を含む認証方法管理の推奨先とされており、従来のMFA/SSPRポリシーでの認証方法管理については、2025年9月30日以降の変更が案内されています。(Microsoft Learn)
確認すべきことは、次の4つです。
- FIDO2、Windows Hello for Business、Microsoft Authenticator、TAPの対象ユーザーが明確か
- 旧MFA/SSPRポリシーとAuthentication methods policyで矛盾した許可が残っていないか
- Register security infoのConditional Accessと認証方法ポリシーの対象グループが一致しているか
- ユーザーが登録できる方法と、Authentication Strengthsで要求する方法が噛み合っているか
特に大規模環境では、「認証方法を有効にしたチーム」と「Conditional Accessを設計したチーム」が分かれていることがあります。この場合、片方ではFIDO2を一部グループに限定しているのに、もう片方では広いユーザーにPhishing-resistant MFA strengthを要求している、といったズレが起こりやすくなります。
管理者向けの実務チェックリスト
今回のMicrosoft Entra公式ドキュメント更新を受けて、まずは次の順番で確認すると効率的です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | Register security infoを対象にしたConditional Accessポリシーを一覧化する | 影響範囲を把握する |
| 2 | Grant controlsでAuthentication Strengthsを使っているか確認する | 登録時の認証要件を把握する |
| 3 | Session controlsでSign-in frequencyを設定しているか確認する | 5分・10分要件との衝突を確認する |
| 4 | FIDO2、Windows Hello for Business、TAPの対象グループを確認する | ユーザーが要件を満たせるか確認する |
| 5 | 新入社員、端末交換、資格情報紛失時の手順をテストする | 初回登録・復旧フローの詰まりを見つける |
| 6 | Report-onlyとサインインログで結果を確認する | 本番影響を出す前に検証する |
| 7 | ヘルプデスク向けの案内文を更新する | エラー発生時の切り分けを早める |
ヘルプデスクには、次のような切り分け観点を共有しておくと実用的です。
- ユーザーはどの操作をしていたか
例：Security infoの表示、FIDO2追加、既存方法の削除、My Sign-insアクセス - 直近でMFAを完了していたか
例：5分以内か、10分以内か - どの認証方法でサインインしていたか
例：パスワード＋SMS、Authenticator、FIDO2、Windows Hello for Business - 対象ユーザーはどのConditional Accessポリシーに該当したか
- Authentication Strengthsで要求される方法をユーザーが登録済みか
この情報が揃うと、「端末の問題」「FIDO2キーの不良」「ユーザー操作ミス」と誤判定する前に、Conditional Accessと認証強度の問題として調査できます。
ユーザー案内で伝えるべきこと
ユーザー向けの案内では、細かいポリシー名よりも「いつ再認証が必要になるか」を具体的に伝えることが大切です。
たとえば、次のように書くと混乱を減らせます。
セキュリティ情報の追加・変更時には、再度サインインやMFAが求められる場合があります。特にパスキーを追加・変更する場合は、直前にMFAを完了している必要があります。画面に別のサインイン方法を求めるメッセージが表示された場合は、ブラウザーを閉じる前に社内ヘルプデスクへ連絡してください。
避けたいのは、「MFAを済ませていれば登録できます」とだけ案内することです。今回の更新箇所が示すように、操作内容によって5分・10分の条件があり、さらにAuthentication Strengthsの組み合わせも関係します。
今回の更新をどう扱うべきか
今回の「accepting all copilot suggestions per the author」は、名前だけを見るとCopilot関連の大きな変更に見えるかもしれません。しかし、実際に確認すべきなのは、Microsoft EntraのCombined Registrationにおけるセッション制御とConditional Access設計です。
特に、パスキー（FIDO2）やWindows Hello for Businessを展開している組織、Register security infoをConditional Accessで保護している組織、Authentication Strengthsを厳格に運用している組織は、今回の公式ドキュメント更新をきっかけに設定を棚卸しすべきです。
最初に取るべき行動は、Register security infoを対象にしたConditional Accessポリシーを確認し、Authentication Strengths、Sign-in frequency、Authentication methods policyの対象ユーザーが矛盾していないかを見ることです。そのうえで、新入社員・端末交換・資格情報紛失・FIDO2追加という実際の利用シナリオでテストしてください。
セキュリティ情報登録は、ユーザーが強い認証へ移行するための入口です。その入口を強く守ることは重要ですが、強くしすぎて正当なユーザーが登録できない状態にすると、結果としてヘルプデスク負荷、例外運用、監査説明の難しさが増えます。今回の更新は、そのバランスを見直すための実務的なチェックポイントとして扱うのが最も有効です。
コメント