Microsoft Entra ID 2026 年 8 月 8 日：Passkey 成為首要 MFA、MCP Firewall 預覽版，以及 Web 應用程式 Token Protection

正當你以為在 9 月 1 日 passkey 預設啟用之前，Entra ID 的新聞節奏總算會慢下來時，Microsoft 又丟出了一批更新。這次的焦點在於：消除防釣魚式驗證（phishing-resistant authentication）的摩擦、將 Zero Trust 延伸至 AI 代理程式流量，以及給管理員在 SSPR 強制執行上多一點喘息空間。以下是截至 2026 年 8 月 8 日那一週的變化重點。

1. Passkey 現在可以註冊為你的第一個 MFA 方法（MC1450133）

這是那種會讓你忍不住問「等等，以前不是這樣嗎？」的變更之一。到目前為止，Microsoft Entra ID 都要求使用者先註冊一個較弱的驗證方法——例如 SMS、語音或 Temporary Access Pass——之後才能註冊 passkey。這是個雞生蛋、蛋生雞的問題：想要從第一天就邁向無密碼（passwordless）的組織，必須先佈建一個他們其實正積極想淘汰的方法。

這項要求已經取消。 使用者現在可以直接將 passkey 或無密碼登入方法註冊為他們的第一個 MFA 因素，不再需要任何先決的較弱方法。

為什麼這很重要

這項變更直接支援即將於 9 月 1 日推出的 passkey 預設啟用。加入組織的新使用者可以在初始登入體驗中直接進行 passkey 註冊。不再需要為了「先起步」而註冊 SMS，之後再遷移到 passkey。摩擦消失了。

對於正在建立全新 Entra ID 租用戶，或正在導入新一批使用者的組織來說，這大幅簡化了驗證設定的流程。這也與整個產業將防釣魚式驗證視為基準（而非升級選項）的趨勢一致。

重點細節

• 推出時程： 自 2026 年 1 月起分階段推出，至 2027 年 11 月完成
• 管理員行動： 無需變更任何設定——但請檢視你的驗證方法原則與註冊活動（registration campaign）設定，確認它們已反映這項新能力
• Message Center： 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 需求——不需要另外註冊 passkey 或其他 MFA 方法。

為什麼這很重要

如果你的組織已經在受管理裝置上部署了 Windows Hello for Business 或 macOS Platform SSO，那麼你其實一直以來都擁有具備 MFA 能力的驗證——只是 Entra ID 並未在所有 Conditional Access 情境中完全將它認可為 MFA。這項改變將在 10 月發生。

對管理員而言，這代表：

• 受管理裝置使用者的導入流程更簡單
• 需要管理與稽核的已註冊方法更少
• 要求 MFA 的 Conditional Access 原則可以直接由平台認證本身滿足
• 已擁有 Windows Hello 或 macOS Platform SSO 的使用者，無需再額外註冊 passkey

重點細節

• 時程： 自 2026 年 10 月開始
• 管理員行動： 無需變更設定，但請更新導入文件，並檢視你的 Conditional Access 驗證強度原則（authentication strength policies），確認這些方法在預期的位置被接受
• Message Center： MC1450134

3. Global Secure Access MCP Firewall——AI 代理程式流量的 Zero Trust（預覽版）

隨著 AI 代理程式在企業環境中大量普及，一個新的攻擊面應運而生：AI 代理程式與遠端 MCP 伺服器之間流動的 Model Context Protocol（MCP）流量。Microsoft 的解答是 Global Secure Access MCP 防火牆，目前正處於預覽階段。

它的功能

MCP 防火牆是一項以網路為基礎、以身分為核心的安全控制，它會檢查 MCP 流量（透過可串流 HTTP 與 Server-Sent Events 傳輸的 JSON-RPC 2.0），並在 Global Secure Access 邊緣強制執行允許（Allow）或封鎖（Block）決策。它將 Zero Trust 延伸到 MCP 協定層——無需變更 MCP 用戶端、主機或伺服器。

主要功能包括：

• 租用戶層級封鎖所有 MCP 流量，讓你在審查並核准受信任伺服器期間先行封鎖
• 依 URL 模式允許/封鎖 MCP 伺服器——建立允許清單與拒絕清單
• 選擇性原語控制（selective primitive control）——以個別伺服器為單位允許或封鎖 Tools、Resources 或 Prompt 範本
• 方法與協定版本強制——封鎖未加密的 HTTP 連線，並透過封鎖過時的 MCP 版本來強制協定衛生（protocol hygiene）

先決條件

這是具備特定需求的預覽功能：

• 具備 Internet Access 授權的 Microsoft Entra 租用戶
• Global Secure Access Administrator 與 Conditional Access Administrator 角色
• 已加入 Entra 且安裝 Global Secure Access 用戶端的裝置
• 啟用 TLS 檢查（TLS inspection）（必要，因為 MCP 訊息是透過加密的承載傳輸）

設定流程

1. 建立 MCP 原則：在 Entra 系統管理中心，路徑為 Global Secure Access > Secure > MCP policies（預覽版）
2. 將 MCP 原則連結到安全設定檔（security profile）
3. 設定 Conditional Access 原則，以強制執行該安全設定檔

為什麼這很重要

如果你的組織正在使用 AI 代理程式——而且越來越多的組織確實如此——MCP 流量就是你家安全架構中的一個盲點。代理程式可以呼叫外部工具、存取資源、在遠端伺服器上執行 prompt，而傳統網路控制對這些行為完全沒有可視性。MCP 防火牆正是透過將我們套用於人類身分的 Zero Trust 原則，延伸到 AI 代理程式通訊，來填補這個缺口。

Cisco 的 Secure Access 團隊今年稍早已宣布類似的 MCP 語意檢查能力，顯示這正成為各家 SSE 廠商之間的競爭領域。Microsoft 的做法之所以值得注意，在於它與 Conditional Access 及 Entra ID 身分訊號的深度整合。

4. Web 應用程式 Token Protection——新版部署指南（預覽版）

Microsoft 已發布一份新的部署指南，說明如何針對存取 Azure Resource Manager 的瀏覽器型應用程式，透過 Conditional Access 強制執行 Token Protection。這將權杖重播防護（token replay protection）延伸到瀏覽器工作階段——而這個領域正是權杖竊取一直以來較難防範的地方。

涵蓋內容

該指南逐步說明如何為受支援的瀏覽器型應用程式（存取 Azure Resource Manager）設定 Token Protection。主要特性：

• 適用範圍： 僅限於明確列出的應用程式、平台、瀏覽器與裝置設定
• 需求： Entra ID P1，加上額外的 Windows 或 macOS 裝置設定
• 建議： 先從僅報告模式（report-only mode）開始，執行試驗，然後再強制執行
• 狀態： 預覽版——瀏覽器型應用程式的支援明確尚未正式推出（GA）

為什麼這很重要

權杖竊取與重播攻擊仍然是重大的威脅途徑。Token Protection 會將登入工作階段權杖綁定到原始裝置，使竊取的權杖在從其他機器重播時失效。在此之前，這項保護主要僅適用於原生用戶端應用程式。將它延伸到瀏覽器型應用程式——即使只是預覽版——填補了強制執行模型中的一個重要缺口。

對於大量透過瀏覽器入口網站使用 Azure Resource Manager 的組織來說，這值得以試驗（pilot）的規模進行評估。僅報告模式的建議相當合理：瀏覽器應用程式的相容性在不同平台與設定之間差異顯著。

5. SSPR 強制執行日期延後——有更多時間讓使用者完成註冊

如果你一直在追蹤那項要求「明確註冊驗證方法」的 SSPR 變更，那麼現在你有更多時間了。Microsoft 已重新安排關鍵里程碑：

為什麼這很重要

2026 年 11 月 9 日之後，SSPR 將不再接受目錄來源的聯絡資訊（儲存為使用者物件屬性的電話號碼、電子郵件地址）作為密碼重設驗證。只有明確註冊的驗證方法才有效。強制執行前的註冊活動，會在使用者登入後提示受影響的使用者註冊方法。

多出來的時間固然歡迎，但別浪費它。11 月 9 日的強制執行日期現在只剩三個月。組織應該：

1. 找出依賴目錄來源聯絡資訊進行 SSPR 的使用者
2. 執行註冊活動，在 10 月 5 日開始時立即啟動
3. 提前傳達這項變更給使用者
4. 確保每位使用者在 11 月 9 日前至少註冊一個驗證方法

6. Agent 365 授權需求釐清：Conditional Access for Agents 必須具備授權

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 授權。這是指導文件的釐清，而非新產品發布——這項需求先前已有所預告——但「即將推出」的措辭現在已經消失了。

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 wizard 取代了原本以 Mappings 為基礎的指派型與屬性型篩選步驟
• 頁面日期從 2025 年 3 月更新為 2026 年 8 月 6 日
• 佈建記錄（provisioning logs）文件現在納入 Microsoft MCP Server for Enterprise 整合，可透過委派的權限進行自然語言、唯讀分析

為什麼這很重要

如果你正依照舊版文件設定 SCIM 佈建，你會發現導覽路徑已經改變。這次更新讓文件與目前的入口網站體驗保持一致。經常設定佈建工作的管理員，應該將更新後的頁面加入書籤。

重點日期總覽

管理員行動清單

1. 更新導入文件，反映 passkey 現在可以成為第一個 MFA 方法——移除任何「使用者需要先註冊較弱方法」的指引
2. 檢視 Conditional Access 驗證強度原則，為 2026 年 10 月 Windows Hello 與 macOS Platform SSO 被認可為獨立 MFA 預做準備
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 日 passkey 預設啟用的里程碑逼近，Entra ID 變更的節奏持續加快。從驗證演進、AI 代理程式安全，到文件大改版，有太多東西需要追蹤。我們會在新公告發布時，持續提供可執行的分析。

在 X 上追蹤 https://x.com/kkaminsk 以獲得即時更新與分析。

Big Hat Group Inc. 是 Microsoft 合作夥伴，擁有超過 20 年協助組織進行身分與安全轉型的經驗。歡迎聯絡我們，討論這些變更如何影響你的環境，以及我們如何協助你規劃遷移。