每隔幾個月，總有企業客戶在電話那頭問同一個問題：「微軟又寄信來說要強制 MFA，這次是真的會被卡住嗎？我們的自動化腳本會不會掛掉？」
答案是：這次是真的，而且時鐘正在倒數。 2026 年 7 月，有三件 Microsoft Entra ID 的變更同時落地，其中最關鍵的一件，是強制 MFA 第二階段的延期上限到期。對於大量仍用「使用者帳號加密碼」跑排程、跑 CI/CD、跑 IaC 部署的企業來說，這不只是一封提醒信，而是一個會讓既有流程突然失敗的硬期限。
這篇文章不重複官方文件的逐字翻譯，而是站在台灣企業 IT 主管的立場，把「Microsoft Entra ID 條件式存取與強制 MFA」這件事拆成可執行的準備清單、授權選擇與分階段導入路線圖——讓你在 7 月那幾個生效日之前，把該處理的帳號先處理掉。
為什麼身分，已經是資安的第一道防線
過去談企業資安，預算多半投在防火牆、EDR、入侵偵測上——防的是「外面打進來」。但攻擊的重心早已轉移到身分：拿到一組合法憑證，攻擊者就能大方走正門進來，不會觸發任何入侵警報。
這不是聳動的說法，而是有數字支撐的趨勢：
- Microsoft 每秒攔截約 7,000 次密碼攻擊。
- 超過 97% 的身分攻擊屬於密碼攻擊（含密碼噴灑）；2025 上半年身分型攻擊較前期成長 32%。
- Microsoft Entra 每天偵測逾 6 億次身分型攻擊（MDDR 2024 數字，2025 報告續引）。
而防守端的投資報酬率同樣明確：MFA 可阻擋逾 99.2% 的帳號入侵攻擊，防網釣 MFA（phishing-resistant MFA）更可阻擋逾 99% 的身分型攻擊；歷史數據顯示，超過 99.9% 被入侵的帳號當初並未啟用 MFA。
換句話說，把 MFA 與條件式存取做扎實，是企業資安裡少數「成本低、效果立竿見影」的動作。這也是為什麼 Microsoft 會用強制的方式，把全體租戶往這個方向推。身分治理同時也是零信任架構的核心——條件式存取正是 Microsoft 用來實作零信任的政策引擎。
2026 年 7 月：三個生效日，一次看懂
很多企業的焦慮來自「資訊太碎」——微軟的提醒信一封一封來，卻沒人幫你把時間軸串起來。以下是 7 月前後最關鍵的幾個轉折，建議直接抄進你的維運行事曆：
| 日期 | 變更內容 | 受影響對象 |
|---|---|---|
| 2025-03（已發生） | 強制 MFA 第一階段（Azure portal／Entra 系統管理中心／Intune 入口的 CRUD 操作）已推送至 100% Azure 租戶 | 所有用入口網站管理 Azure 的系統管理員 |
| 2025-10-01 起（進行中） | 強制 MFA 第二階段逐步強制：Azure CLI／PowerShell／行動 App／IaC 工具／REST API 控制平面的建立、更新、刪除操作（讀取不需 MFA） | 自動化腳本、IaC 部署、CLI 操作 |
| 2026-07-01 | 第二階段延期上限到期——已申請延期的租戶屆時自動強制 | 仍在用延期視窗的租戶 |
| 2026-07-06 | 「註冊安全資訊」條件式存取原則開始套用至 Windows Hello for Business 與 macOS Platform SSO 註冊（rollout 至 07-13 完成） | 註冊 WHfB／Platform SSO 的端點 |
| 2026-07-06 | Entra ID SSPR（自助密碼重設）註冊行動開跑 | 尚未註冊驗證方法的使用者 |
| 2026-09-07 | SSPR 不再接受目錄屬性帶入的電話／Email，僅接受使用者明確註冊的方法 | 仰賴 mobilePhone／businessPhone／otherMails 帶入聯絡資訊的租戶 |
最容易踩雷的一條：自動化腳本。 第二階段強制的是「控制平面的建立／更新／刪除」操作。如果你有用使用者名稱加密碼登入的排程腳本、CI/CD pipeline 或 IaC 部署，這些流程會在強制後失敗——而且失敗的時間點，可能就是某次半夜的自動部署。OAuth 2.0 的 ROPC（使用者名稱加密碼）流程與強制 MFA 不相容，多個 MSAL 與 Azure Identity SDK 也已標記 deprecated。請務必在 7 月前盤點完畢。
條件式存取與強制 MFA，到底是什麼關係
這兩個詞常被混為一談，先把界線劃清楚：
強制 MFA 是 Microsoft 對全體租戶的「地板」——不管你有沒有買進階授權，管理 Azure／Entra 的關鍵操作都會被要求 MFA。它是 Microsoft 替你打底，沒得商量。
條件式存取（Conditional Access） 則是你自己建立的政策引擎。Microsoft 把它定位為零信任的政策引擎：依使用者、位置、裝置、應用程式、風險等多重訊號，動態決定「准、不准、或要求額外驗證（典型為 MFA）」。強制 MFA 是底線，條件式存取則讓你在底線之上，依企業實際風險做更細緻的治理——例如「從非信任位置登入財務系統時，一律要求 MFA 且裝置須合規」。
兩者並不互斥，而是層層疊加：強制 MFA 確保最關鍵的管理操作有基本保護，條件式存取則把保護延伸到所有應用程式與情境。
條件式存取在身分治理框架中的位置
條件式存取不是孤立的功能，它與其他身分治理元件協同運作，共同落實最小權限：
- 條件式存取負責「驗證」——在存取發生的當下，依訊號要求適當的驗證強度。
- **PIM（特權身分管理）**負責特權帳號的 just-in-time 提權與審核，屬於特權存取管理（PAM）的範疇。
- **生命週期工作流（JML — Joiner／Mover／Leaver）**自動化帳號的入職、異動、離職權限授予與回收。這正是我們在IT 帳號生命週期（JML）管理指南中詳談的主題——條件式存取管「怎麼驗證」，JML 管「該不該還有帳號」，兩者缺一不可。
把這三者串起來，才構成一套完整的身分治理：人員狀態決定帳號是否存在、PIM 決定特權能不能臨時拿、條件式存取決定每次存取要怎麼驗。
P1 還是 P2？授權別買貴也別買不夠
導入條件式存取，第一個現實問題是授權。這裡最常見的誤區，是以為「要做條件式存取就得買最貴的 P2」——其實不一定。
| 能力 | 所需授權 | 說明 |
|---|---|---|
| 基本 MFA | 免費 | 所有 Microsoft 365／Entra 使用者皆可用 |
| security defaults（安全預設值） | 免費 | 無法用條件式存取時的替代方案，一刀切套用 |
| 條件式存取（含用 CA 要求 MFA） | Entra ID P1 或 P2 | per-user 授權，受原則治理的使用者都要有 P1 以上 |
| 條件式存取 | 含於 Microsoft 365 Business Premium | 中小企業常已具備，不必另購 |
| 風險導向條件式存取（登入風險／使用者風險） | Entra ID P2（Entra ID Protection） | 依即時風險動態調整存取決策 |
選授權的判斷準則：如果你要的是「依位置、裝置、應用程式做存取控制」，P1 就夠了——而且若公司已有 Microsoft 365 Business Premium，條件式存取其實已經在你手上。只有當你需要「依登入風險／使用者風險動態決策」（例如自動阻擋不可能的旅行登入），才需要升級到 P2。記住：條件式存取是 per-user 授權，受原則治理的每個使用者都要有 P1 以上，請依「實際納管人數」估算，不要全公司一律買頂規。
關於 Microsoft 365 的整體規劃與在地導入，可進一步參考我們的Microsoft 365 與 Google Workspace 比較，以及台中 Microsoft 365 導入服務。
分階段導入路線圖：別一次全開
導入身分治理最常見的災難，就是「一次把原則全部開到生產環境」，結果把正常員工鎖在門外、客服電話被打爆。Microsoft 官方建議的做法，是先 pilot、再分波次——在支援能力範圍內逐步擴大。完整的零信任藍圖大致是：
MFA → 條件式存取 → SSO → Internet Access → Private Access
前三步是身分核心；後兩步則進入 Entra Suite 與 Global Secure Access 的範疇（Security Service Edge，SSE），可對所有私有 App 套用條件式存取控制（MFA、位置、分段、最小權限），並對 web 與非 web App 啟用 SSO，逐步邁向完整零信任。這條路線與我們在資安網路解決方案中提供的 ZTNA／SASE 服務一脈相承。
導入前的檢核清單
在你按下「啟用原則」之前，請逐項確認以下事項——這份清單是把官方文件翻譯成「實際該做的動作」：
- 盤點會被卡住的帳號：列出所有用使用者帳號跑自動化的服務帳號、CI/CD pipeline、IaC 部署腳本，逐一改用 managed identity 或 service principal。
- 處理 break-glass 帳號：確認緊急帳號能以 passkey（FIDO2）或憑證式驗證滿足 MFA，並納入排除與監控設計，避免被自己的原則鎖死。
- 升級工具版本：CLI 升至 2.76 以上、Azure PowerShell 升至 14.3 以上，確保相容性。
- 先用 report-only 模式測試：以「僅報告」模式套用原則，觀察會影響哪些登入、是否誤鎖正常使用者，確認無誤再正式啟用。
- 對小群 pilot 使用者先行：選一小群使用者套用原則，驗證實際體驗後再分波次擴大。
- 規劃 SSPR 配套：提醒使用者在 2026-07-06 註冊行動開跑後完成驗證方法註冊，避免 2026-09-07 後因目錄屬性失效而無法自助重設密碼。
- 設定維護提醒：把 2026-07-01、07-06、09-07 三個日期標進維運行事曆，過了就回頭把相關原則的狀態確認為「已生效」。
沒有專職人力，怎麼辦？
讀到這裡你大概會發現：條件式存取的「設定」不難，難的是長期的測試、調校與維運。原則要先 report-only 跑一段時間、要分波次 rollout、每次微軟改規則都要回頭檢視——這些都不是「設定一次就完工」的事，而是需要持續照看的運維工作。
這正是官方文件不會替你做的部分。Microsoft Learn 會告訴你「建議用 report-only 模式測試」，但不會替你跑測試、不會替你在每個生效日前盤點受影響的帳號、更不會在你休假時幫你盯著告警。
對於沒有專職 in-house IT 人力的企業，與其在 7 月期限前手忙腳亂，不如把這件事託管出去。凱茂資訊提供以年度維運 SLA 代管條件式存取的設計、report-only 測試與長期調校，把 Entra ID 的身分治理納入我們既有的零信任服務組合——從 MFA 與條件式存取，延伸到 ZTNA／SASE、EDR／XDR、SIEM／SOC 與 PAM，形成一致的縱深防禦。需要時，我們也能協助客戶導入 ISO 27001／42001 的管理制度（為協助客戶導入，非凱茂自身持有認證），讓身分治理有制度可循、可被稽核。
結語：在期限到來之前，先把帳號處理好
2026 年 7 月的三個生效日不會等人。強制 MFA 第二階段在 7 月 1 日延期到期、條件式存取與 SSPR 規則在 7 月 6 日陸續套用——這些都是已排定的時間，不是「可能會發生」。對企業而言，現在最該做的不是焦慮，而是動手盤點：哪些自動化腳本會被卡、break-glass 帳號能不能通過 MFA、授權買 P1 還是 P2、原則有沒有先用 report-only 測過。
身分治理不需要一步到位，但需要一個架構先行、可被治理的起點。如果你不確定公司現在的 Entra ID 設定夠不夠扎實、或擔心 7 月生效後某個流程突然掛掉，歡迎與凱茂資訊聊聊——我們在台中、服務全台，可以從一次身分治理盤點開始，幫你在期限到來之前把該處理的都處理好。歡迎來電 04-2375-8388 或來信 service@kmau.com.tw 安排諮詢。