Microsoft Entra ID 2026年8月8日: パスキーの最初のMFA方式としての登録、MCPファイアウォールのプレビュー、Webアプリ向けToken Protection

Entra IDのニュースサイクルが9月1日のパスキー既定化(パスキーをデフォルト方式とする展開)の前に落ち着くかと思いきや、Microsoftはまた新たなアップデートのバッチを投入しました。今回の焦点は、フィッシング耐性のある認証から摩擦を取り除くこと、Zero TrustをAIエージェントトラフィックに拡張すること、そして管理者にSSPR適用までの猶予をもう少し与えることです。2026年8月8日までの1週間に変わった内容は以下のとおりです。

1. パスキーを最初のMFA方式として登録できるように(MC1450133)

これは「えっ、今までそうじゃなかったの?」と思わず言いたくなるような変更のひとつです。これまでMicrosoft Entra IDでは、パスキーを登録する前に、SMSや音声、Temporary Access Passなどの弱い認証方式を先に登録することが必須でした。これは鶏と卵の問題でした。つまり、初日からパスワードレスに移行したい組織は、まず廃止しようとしている方式を導入しなければならなかったのです。

その要件は撤廃されました。 ユーザーは今後、前提となる弱い方式を一切登録することなく、パスキーまたはパスワードレスサインイン方式を最初のMFA要素として登録できます。

なぜ重要か

この変更は、9月1日に予定されているパスキー既定化の展開を直接サポートします。組織に新しく加わったユーザーは、最初のサインイン体験でいきなりパスキー登録に進むことができます。「とりあえず始めるためにSMSを登録して、あとでパスキーに移行する」という手順はもう不要です。摩擦はなくなりました。

新規にEntra IDテナントを構築する組織や、新しいユーザーを一括オンボーディングする組織にとっては、認証設定のフローが劇的に簡素化されます。また、フィッシング耐性のある認証を「アップグレード」ではなく「標準」とする業界全体の流れにも合致します。

主な詳細

• 展開スケジュール: 2026年1月から2027年11月まで段階的に展開
• 管理者の対応: 構成変更は不要ですが、認証方法ポリシーと登録キャンペーン設定を見直し、この新機能を反映していることを確認してください
• メッセージセンター: MC1450133

2. Windows Hello for BusinessとmacOS Platform SSOが単独のMFA要素に(MC1450134)

2026年10月以降、Microsoft Entra IDはWindows Hello for BusinessとmacOS Platform SSOを単独のMFA要素として認定します。つまり、管理対象のWindowsおよびmacOSデバイスを使用するユーザーは、デバイスに組み込まれた生体認証やPINによってMFA要件を満たすことができ、別途パスキーや他のMFA方式を登録する必要がなくなります。

なぜ重要か

組織が管理対象デバイスにWindows Hello for BusinessまたはmacOS Platform SSOをすでに展開している場合、実質的にはこれまでもずっとMFA対応の認証を利用していました。しかし、Entra IDはすべてのConditional Accessシナリオにおいてそれを完全には認定していませんでした。それが10月に変わります。

管理者にとっては、次のような意味があります:

• 管理対象デバイスのユーザー向けオンボーディングフローがよりシンプルに
• 管理・監査すべき登録方式の数が減少
• MFAを要求するConditional Accessポリシーを、プラットフォームの資格情報自体で満たせる
• Windows HelloまたはmacOS Platform SSOをすでに持つユーザーへの追加のパスキー登録が不要に

主な詳細

• スケジュール: 2026年10月開始
• 管理者の対応: 構成変更は不要ですが、オンボーディングのドキュメントを更新し、Conditional Accessの認証強度ポリシーを見直して、意図した場所でこれらの方式が受け入れられることを確認してください
• メッセージセンター: MC1450134

3. Global Secure Access MCPファイアウォール — AIエージェントトラフィックのZero Trust(プレビュー)

AIエージェントがエンタープライズ環境に急速に普及するにつれ、新たな攻撃対象領域が出現しました。それは、AIエージェントとリモートMCPサーバー間を流れるModel Context Protocol(MCP)トラフィックです。Microsoftはこれに対する答えとして、Global Secure Access MCPファイアウォールをプレビュー公開しました。

機能の概要

MCPファイアウォールは、ネットワークベースかつID中心のセキュリティ制御であり、MCPトラフィック(ストリーミング可能なHTTPおよびServer-Sent Events上のJSON-RPC 2.0)を検査し、Global Secure Accessエッジで許可(Allow)またはブロック(Block)の判断を適用します。MCPクライアント、ホスト、サーバーを変更することなく、Zero TrustをMCPプロトコル層にまで拡張します。

主な機能は次のとおりです:

• テナント全体でMCPトラフィックをすべてブロック — 信頼できるサーバーを審査・承認する間、一時的に全面ブロック
• URLパターンによるMCPサーバーの許可/ブロック — 許可リストと拒否リストの作成が可能
• 選択的なプリミティブ制御 — サーバー単位でTools、Resources、Promptテンプレートの許可/ブロックが可能
• メソッドとプロトコルバージョンの強制 — 暗号化されていないHTTP接続をブロックし、古いMCPバージョンのブロックによりプロトコルの衛生状態を強制

前提条件

これは特定の要件を伴うプレビュー機能です:

• Internet Accessライセンスを持つMicrosoft Entraテナント
• Global Secure Access AdministratorロールとConditional Access Administratorロール
• Global Secure AccessクライアントがインストールされたEntra参加デバイス
• TLS検査の有効化(MCPメッセージは暗号化ペイロード内を移動するため必須)

構成フロー

1. Entra管理センターのGlobal Secure Access > Secure > MCP policies(プレビュー)でMCPポリシーを作成
2. MCPポリシーをセキュリティプロファイルにリンク
3. セキュリティプロファイルを強制するConditional Accessポリシーを構成

なぜ重要か

組織がAIエージェントを使用している場合 — そして現在ではその多くが使用しています — MCPトラフィックはセキュリティスタックにおける盲点です。エージェントは外部ツールを呼び出し、リソースにアクセスし、リモートサーバー上でプロンプトを実行できますが、従来のネットワーク制御には何が起きているかの可視性がありません。MCPファイアウォールは、人間のIDに適用してきたのと同じZero Trustの原則をAIエージェントの通信に適用することで、そのギャップを埋めます。

CiscoのSecure Accessチームは今年初めに同様のMCPセマンティック検査機能を発表しており、これはSSEベンダー間で競争が激化している領域であることを示しています。Microsoftのアプローチが注目に値するのは、Conditional AccessおよびEntra IDのIDシグナルとの深い統合です。

4. Webアプリ向けToken Protection — 新しい展開ガイド(プレビュー)

Microsoftは、Azure Resource Managerにアクセスするブラウザベースのアプリケーションに対してConditional AccessでToken Protectionを適用するための新しい展開ガイドを公開しました。これにより、トークン再生防止がブラウザセッションに拡張されます。トークン窃取の防止が歴史的に難しいとされてきた領域です。

ガイドの対象

このガイドでは、Azure Resource Managerにアクセスするサポート対象のブラウザベースアプリケーションに対するToken Protectionの構成手順を解説しています。主な特徴は次のとおりです:

• 対象範囲: 明示的に列挙されたアプリ、プラットフォーム、ブラウザ、デバイス構成に限定
• 要件: Entra ID P1に加え、追加のWindowsまたはmacOSデバイス設定が必要
• 推奨事項: まずレポート専用モードで開始し、パイロットを実施してから強制適用
• ステータス: プレビュー — ブラウザベースのアプリケーションサポートは明示的にまだGAではありません

なぜ重要か

トークン窃取と再生攻撃は依然として重大な脅威ベクトルです。Token Protectionはサインインセッショントークンを発行元デバイスにバインドするため、窃取されたトークンは別のマシンから再生されても無効になります。これまでこの保護は主にネイティブクライアントアプリケーションで利用可能でした。これをブラウザベースのアプリに拡張することは — たとえプレビューであっても — 適用モデルにおける重要なギャップを埋めるものです。

ブラウザポータルを通じてAzure Resource Managerを多用している組織にとっては、パイロット規模での評価に値する変更です。レポート専用モードの推奨は理にかなっています。ブラウザアプリの互換性はプラットフォームや構成によって大きく異なるためです。

5. SSPR適用日が延期 — ユーザー登録にもう少し時間

明示的に登録された認証方法を必須とするSSPR変更を追跡しているなら、今回は猶予が得られました。Microsoftは主要なマイルストーンを以下のように再スケジュールしました:

なぜ重要か

2026年11月9日以降、SSPRはパスワードリセットの検証に、ディレクトリ由来の連絡先情報(ユーザーオブジェクトのプロパティとして保存された電話番号やメールアドレス)を利用できなくなります。明示的に登録された認証方法のみが機能します。適用に先立つ登録キャンペーンは、影響を受けるユーザーに対し、サインイン後に認証方法の登録を促します。

猶予ができたのは歓迎ですが、無駄にしないでください。11月9日の適用日まで、あと3か月しかありません。組織は以下を行うべきです:

1. SSPRにディレクトリ由来の連絡先情報を頼っているユーザーを特定する
2. 10月5日に開始される登録キャンペーンを実行する
3. 変更についてユーザーに事前に十分周知する
4. 11月9日までに全ユーザーが少なくとも1つの登録済み認証方法を持つようにする

6. Conditional Access for AgentsにおけるAgent 365ライセンス要件が明確化

Microsoftは、Conditional Access for agentsのドキュメントを更新し、Microsoft Agent 365ライセンスが必要であることを明示しました。これにより、従来の「Starting soon(まもなく開始)」という表現が、直接的な要件の記述に置き換わりました。

ライセンスの詳細

Agent 365は:

• Microsoft 365 E7に含まれる
• Microsoft E5、A5、Business Premium、またはDefender Suite + Purview Suiteへのアドオンとして利用可能

なぜ重要か

Entra Agent IDをConditional Accessポリシーと組み合わせて使用中、または使用予定の組織は、ライセンスを確認する必要があります。ドキュメントの更新では、Entra Conditional Access for AgentsとEntra ID Protection for Agentsの両方にAgent 365ライセンスが必要であることも明確化されています。これは新製品の発表ではなく、ガイダンスの明確化です — 要件自体は以前から予告されていましたが、「Starting soon」という表現はなくなりました。

7. SCIMプロビジョニングのドキュメントがナビゲーションを大幅刷新

複数のSCIMプロビジョニングのドキュメントページが、現在のEntra管理センターの操作性に合わせて、新しいナビゲーションラベルとワークフローで更新されました:

• 「Show advanced options」は、Advanced Optionsドロップダウンになりました
• 「Edit attribute list for ScimOnPremises」は、Edit target User attributes / Edit schemaになりました
• Expression Builderは、Attribute Mapping > Advanced Optionsではなく、左側のナビゲーションメニューからアクセスするようになりました
• Scoping filtersウィザードが、従来のMappingsベースの手順に代わり、割り当てベースおよび属性ベースのフィルタリングに使用されます
• ページの日付が2025年3月から2026年8月6日に更新されました
• プロビジョニングログのドキュメントには、委任された権限による自然言語での読み取り専用分析のためのMicrosoft MCP Server for Enterprise統合が含まれるようになりました

なぜ重要か

古いドキュメントに従ってSCIMプロビジョニングを構成している場合は、ナビゲーションパスが変わっていることに気づくでしょう。この更新により、ドキュメントは現在のポータルの操作性に合わせて調整されています。プロビジョニングジョブを頻繁に構成する管理者は、更新されたページをブックマークしておくべきです。

主要日程のまとめ

管理者向けアクション項目

1. オンボーディングのドキュメントを更新 — パスキーが最初のMFA方式として登録できるようになったことを反映し、「先に弱い方式の登録が必要」とする記述を削除する
2. Conditional Accessの認証強度ポリシーを見直す — 2026年10月の単独MFA要素としての認定に先立ち、Windows HelloとmacOS Platform SSOを確認する
3. MCPファイアウォールを評価する — 組織がMCPを使用するAIエージェントを導入している場合、前提条件(Internet Accessライセンス、GSAクライアント、TLS検査)を満たしているか確認する
4. Webアプリ向けToken Protectionをパイロットする — ブラウザポータル経由でAzure Resource Managerを使用している場合、レポート専用モードで試す
5. SSPR展開計画を修正する — 更新された10月5日と11月9日の日程に合わせる
6. Agent 365ライセンスを確認する — Conditional Access for agentsを使用中または使用予定の場合
7. 更新されたSCIMプロビジョニングのドキュメントをブックマークする — ナビゲーションパスが変更されています

最新情報の入手方法

9月1日のパスキー既定化のマイルストーンが近づくにつれ、Entra IDの変更のペースは加速し続けています。認証の進化、AIエージェントのセキュリティ、ドキュメントの刷新と、追跡すべきことはたくさんあります。新しい発表が出るたびに、実践的な分析を引き続き提供していきます。

リアルタイムの更新と分析は、X(旧Twitter)の https://x.com/kkaminsk で会話に参加してください。

Big Hat Group Inc.は、組織のIDおよびセキュリティ変革を支援してきた20年以上の経験を持つMicrosoftパートナーです。これらの変更がお客様の環境にどのような影響を与えるか、また移行計画をどのように支援できるかについて、お気軽にお問い合わせください。