在 Microsoft，我們致力於為客戶提供最高層級的安全性。 其中一個最有效的安全措施是多重要素驗證 (MFA)。 Microsoft 的研究顯示，MFA 可封鎖超過 99.2% 的帳戶入侵攻擊。
這就是為什麼從 2024 年開始，我們會對所有 Azure 登入嘗試強制執行強制 MFA。 如需此需求的詳細資訊，請參閱我們的 部落格文章。 本主題涵蓋哪些應用程式和帳戶受到影響、如何將強制執行推出至租使用者，以及其他常見問題和解答。
這很重要
如果使用者無法在推出強制 MFA 之後登入 Azure 和其他系統管理入口網站，全域管理員可以執行腳本來延後 MFA 需求，並允許使用者登入。 如需詳細資訊，請參閱 在推出強制多重要素驗證（MFA）需求之後，如果使用者無法登入 Azure 入口網站、Microsoft Entra 系統管理中心或 Microsoft Intune 系統管理中心，如何延後租用戶的強制執行。
如果您的組織已經為使用者強制執行 MFA，或者他們以更安全的方法登入，例如無密碼或使用通行密鑰（FIDO2），則使用者不會有任何變更。 若要確認 MFA 已啟用，請參閱 如何確認使用者已針對強制 MFA 進行設定。
強制執行範圍
強制執行範圍包括何時計劃強制執行、哪些應用程式計劃強制執行 MFA、範圍不足的應用程式，以及哪些帳戶具有強制 MFA 需求。
強制執行階段
備註
第 2 階段的強制執行日期已變更為 2025 年 9 月 1 日。
針對應用程式的 MFA 強制執行會在兩個階段中推出。
在階段 1 中強制執行 MFA 的應用程式
從 2024 年 10 月開始，登入 Azure 入口網站、Microsoft Entra 系統管理中心和 Microsoft Intune 系統管理中心的帳戶都需要 MFA，才能執行任何建立、讀取、更新或刪除 （CRUD） 作業。 該強制執行措施將逐步推廣至全球所有租用戶。 從 2025 年 2 月開始，會逐步強制執行登入至 Microsoft 365 系統管理中心的多重因素驗證。 階段 1 不會影響其他 Azure 用戶端，例如 Azure CLI、Azure PowerShell、Azure 行動應用程式或 IaC 工具。
在階段 2 中強制執行 MFA 的應用程式
從 2025 年 9 月 1 日起，MFA 強制執行將會逐漸開始，讓登入 Azure CLI、Azure PowerShell、Azure 行動應用程式、IaC 工具和 REST API 端點的帳戶開始執行任何建立、更新或刪除作業。 讀取作業不需要 MFA。
某些客戶可能會使用 Microsoft Entra ID 中的使用者帳戶作為服務帳戶。 建議將這些使用者型服務帳戶移轉到具有工作負載身分識別的安全雲端式服務帳戶。
應用程式
下表列出 Azure 受影響的應用程式、應用程式識別碼和 URL。
| 應用程式名稱 | App ID | 執法開始 |
|---|---|---|
| Azure 入口網站 | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年下半年 |
| Microsoft Entra 系統管理中心 | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年下半年 |
| Microsoft Intune 系統管理中心 | c44b4083-3bb0-49c1-b47d-974e53cbdf3c | 2024 年下半年 |
| Azure 命令列介面 (Azure CLI) | 04b07795-8ddb-461a-bbee-02f9e1bf7b46 | 2025 年 9 月 1 日 |
| Azure PowerShell | 1950a258-227b-4e31-a9cf-717495945fc2 | 2025 年 9 月 1 日 |
| Azure 行動應用程式 | 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa | 2025 年 9 月 1 日 |
| 基礎結構即程式碼 (IaC) 工具 | 使用 Azure CLI 或 Azure PowerShell ID | 2025 年 9 月 1 日 |
| REST API （控制平面） | N/A | 2025 年 9 月 1 日 |
| Azure SDK | N/A | 2025 年 9 月 1 日 |
下表列出Microsoft 365 受影響的應用程式和URL。
| 應用程式名稱 | URL | 執法開始 |
|---|---|---|
| Microsoft 365 系統管理中心 | https://portal.office.com/adminportal/home |
2025年2月 |
| Microsoft 365 系統管理中心 | https://admin.cloud.microsoft |
2025年2月 |
| Microsoft 365 系統管理中心 | https://admin.microsoft.com |
2025年2月 |
帳戶
登入以執行 應用程式一節 中所引用作業的所有帳戶，都必須在強制執行開始時完成 MFA。 如果使用者存取 Azure 上裝載的其他應用程式、網站或服務，則不需要使用 MFA。 稍早列出的每個應用程式、網站或服務擁有者都會控制用戶的驗證需求。
強制執行開始後，應急或緊急存取帳戶也必須使用 MFA 登入。 建議您更新這些帳戶以使用 通行金鑰 （FIDO2） 或設定 作為多重身份驗證 (MFA) 手段的憑證式驗證。 這兩種方法都滿足 MFA 需求。
工作負載身分識別，例如受控識別和服務主體，不會受到 此 MFA 強制執行的任一階段 所影響。 如果使用者身分識別用於以服務帳戶身分登入來執行自動化 (包括指令碼或其他自動化工作)，這些使用者身分識別必須在強制執行開始後使用 MFA 登入。 不建議自動化使用者身分識別。 您應將這些使用者身分識別移轉至工作負載身分識別。
用戶端程式庫
OAuth 2.0 資源擁有者密碼認證 （ROPC） 令牌授與流程與 MFA 不相容。 在您的 Microsoft Entra 租使用者中啟用 MFA 之後，應用程式中使用的 ROPC 型 API 會引發例外狀況。 如需如何在 Microsoft 驗證連結庫 （MSAL） 中從 ROPC 型 API 移轉的詳細資訊，請參閱 如何從 ROPC 移轉。 如需特定語言的 MSAL 指引，請參閱下列索引標籤。
如果您使用 Microsoft .Identity.Client 套件和應用程式中的下列其中一個 API，則需要變更：
相同的一般 MSAL 指引適用於 Azure 身分識別程式庫。 這些程式庫中提供的 UsernamePasswordCredential 類別使用 MSAL ROPC 型 API。 如需特定語言的指引，請參閱下列索引標籤。
如果您使用 Azure.Identity 套件，並在應用程式中執行下列其中一項動作，則需要變更：
- 使用 DefaultAzureCredential 或 EnvironmentCredential，並設定下列兩個環境變數：
AZURE_USERNAMEAZURE_PASSWORD
- 使用
UsernamePasswordCredential（從 版本1.14.0-beta.2已被取代為）
將使用者基礎服務帳戶遷移至工作負載身份識別
我們建議客戶辨識那些被當作服務帳戶使用的用戶帳戶，並開始將它們遷移至工作負載身分識別。 移轉通常需要更新腳本和自動化程式，才能使用工作負載身分識別。
檢查 如何確認用戶已設定為強制 MFA，以識別所有登入應用程式的用戶帳戶，包括用來作為服務帳戶的用戶帳戶。
如需如何從使用者型服務帳戶移轉至工作負載身分識別以使用這些應用程式進行驗證的詳細資訊，請參閱：
- 使用 Azure CLI 透過受控識別登入 Azure
- 使用 Azure CLI 透過服務主體登入 Azure
- 以非互動方式登入 Azure PowerShell 以進行自動化場景，並提供託管身分識別和服務主體使用案例指引。
有些客戶會將條件式存取原則套用至使用者型服務帳戶。 您可以回收使用者型授權，並新增 工作負載身分 識別授權，以套用 工作負載身分識別的條件式存取。
實施
此登入時需要 MFA 驗證的要求已經在系統管理入口網站和其他 應用程式中實施，。 Microsoft Entra ID 登入記錄檔顯示其作為 MFA 需求的來源。
強制 MFA 無法設定。 它與租用戶中所設定的任何存取原則分開進行實作。
例如，如果您的組織選擇保留Microsoft 安全性預設值，且您目前已啟用安全性預設值，您的使用者就不會看到任何變更，因為 Azure 管理已經需要 MFA。 如果您的租用戶在 Microsoft Entra 中使用條件式存取原則，而且您已經擁有一個讓使用者通過 MFA 經 Azure 登入的條件式存取原則，那麼使用者就不會注意到任何變更。 同樣，任何針對 Azure 且需要更強的身分驗證的條件式存取原則，例如具備防網路釣魚功能的多因素驗證 (MFA)，都會繼續強制執行。 使用者不會看到任何變更。
通知通道
Microsoft 會透過下列通道，通知所有 Microsoft Entra 全域系統管理員：
電子郵件：已設定電子郵件地址的全域管理員將會收到關於即將實施的 MFA 強制措施以及需要採取的準備行動的通知。
服務健康情況 通知：全域管理員會透過 Azure 入口網站 接收服務健康情況通知，且追蹤標識碼為 4V20-VX0。 此通知包含與電子郵件相同的資訊。 全域系統管理員還可訂閱透過電子郵件接收服務健康情況通知。
入口網站通知：登入時，Azure 入口網站、Microsoft Entra 系統管理中心和 Microsoft Intune 系統管理中心會出現通知。 入口網站通知會鏈接到此主題，以便瞭解 MFA 強制執行的更多資訊。
Microsoft 365 訊息中心：訊息出現在訊息標識碼為MC862873的 Microsoft 365 訊息中心。 此訊息與電子郵件和服務健康情況通知具有相同的資訊。
強制執行之後， Azure 入口網站中會出現橫幅：
外部驗證方法和識別提供者
支援外部 MFA 解決方案目前處於預覽階段，可搭配外部驗證方法以滿足 MFA 需求。 舊版條件式存取自定義控件預覽不符合 MFA 需求。 您應移轉至外部驗證方法預覽版，以使用具有 Microsoft Entra ID 的外部解決方案。
如果您使用同盟識別提供者 (IdP)，例如 Active Directory 同盟服務，且您的 MFA 提供者直接與此同盟 IdP 整合，必須設定同盟 IdP 設定以傳送 MFA 宣告。 如需詳細資訊，請參閱 Microsoft Entra MFA 的預期輸入聲明。
要求更多時間來準備第1階段的多因素驗證執行。
我們了解某些客戶可能需要更多時間來準備此 MFA 需求。 Microsoft可讓具有複雜環境或技術障礙的客戶將第 1 階段的強制執行延後到 2025 年 9 月 30 日。
對於想要延後強制執行開始日期的每個租使用者，全域管理員可以移至 https://aka.ms/managemfaforazure 以選取開始日期。
謹慎
延後強制執行的開始日期，您將承擔額外的風險，因為存取 Azure 入口網站等 Microsoft 服務的帳戶對於威脅行為者而言是非常有價值的目標。 建議所有租用戶現在都設定 MFA 來保護雲端資源。
如果您先前從未使用 MFA 登入 Azure 入口網站，系統會提示您完成 MFA 登入，或延後 MFA 強制執行。 此畫面只會顯示一次。 如需如何設定 MFA 的詳細資訊，請參閱 如何確認使用者已針對強制 MFA 進行設定。
如果您選取 [延後 MFA]，MFA 強制執行的日期將會是未來一個月，或 2025 年 9 月 30 日，以稍早為準。 登入後，您可以在 https://aka.ms/managemfaforazure 變更日期。 若要確認您想要繼續進行延後要求，請按兩下 [確認延後]。 全域管理員必須 提高存取權 ，以延後 MFA 強制執行的開始日期。
要求更多時間來準備第二階段 MFA 的執行
Microsoft 允許在具有複雜環境或技術障礙的情況下，客戶可以將其租戶的第 2 階段強制執行延後到 2026 年 7 月 1 日。 您可以要求更多時間來準備 MFA 第 2 階段的強制執行，請在 https://aka.ms/postponePhase2MFA。 選擇另一個開始日期，然後按兩下 [ 套用]。
備註
如果您延後階段 1 的開頭，階段 2 的開始也會延後至相同的日期。 您可以選擇階段 2 的稍後開始日期。
常見問題集
問題：如果租用戶僅用於測試，是否需要多重身份驗證（MFA）？
答：是，每個 Azure 租使用者都需要 MFA，但測試環境沒有任何例外。
問題：此需求如何影響 Microsoft 365 系統管理中心？
回答：強制 MFA 將於 2025 年 2 月開始推出至 Microsoft 365 系統管理中心。 在部落格文章
問題：所有使用者還是僅系統管理員需要 MFA？
答：所有登入 先前所列應用程式 的用戶都必須完成 MFA，而不論任何已啟用或符合其資格的系統管理員角色，或為其啟用的任何 使用者排除 。
問題：如果我選擇 [保持登入] 選項，是否需要完成 MFA？
答：是，即使您選擇 [ 保持登入]，您必須先完成 MFA，才能登入這些 應用程式。
問題：強制執行是否適用於 B2B 來賓帳戶？
回答：是的，如果已正確設定，MFA 必須從合作夥伴資源租用戶或使用者的主租用戶遵守，並透過跨租用戶存取來將 MFA 聲明傳送給資源租用戶。
問題：規範是否適用於美國政府專用 Azure 或 Azure 主權雲端？
答：Microsoft只在公用 Azure 雲端中強制執行強制 MFA。 Microsoft目前不會針對美國政府或其他 Azure 主權雲端在 Azure 中強制執行 MFA。
問題：如果我們使用另一個身份提供者或 MFA 解決方案來執行 MFA，而不是使用 Microsoft Entra MFA，我們如何確保合規？
回應：第三方 MFA 可以直接與 Microsoft Entra 身分識別整合。 如需其他資訊，請參閱《Microsoft Entra 多重要素驗證外部方法供應商參考》。 Microsoft可以使用同盟識別提供者選擇性地設定 Entra 識別碼。 如果是，則必須正確設定識別提供者解決方案，以將多重驗證宣告傳送至Microsoft Entra ID。 如需詳細資訊，請參閱 使用來自同盟 IdP 的 MFA 聲明滿足 Microsoft Entra ID 多重要素驗證 (MFA) 控制要求。
問題：強制 MFA 會影響我與 Microsoft Entra Connect 或 Microsoft Entra Cloud Sync 同步處理的能力嗎？
回答：否。 同步處理服務帳戶不受強制 MFA 需求影響。 只有 稍早列出的應用程式 需要 MFA 才能登入。
問題：是否可以選擇退出？
回答：沒有辦法退出。此安全措施對於 Azure 平臺的安全性和保護至關重要，而且會在雲端廠商之間採用。 例如，請參閱透過設計確保安全：AWS 於 2024 年增強 MFA 需求。
客戶可選擇延後強制開始日期。 全域管理員可以前往 Azure 入口網站 延後其租用戶的強制執行開始日期。 全域管理員必須先提高 存取 權，才能延後此頁面上 MFA 強制執行的開始日期。 他們必須針對需要延後的每個租用戶執行此動作。
問題：在 Azure 強制執行原則以確保沒有任何中斷之前，是否可以測試 MFA？
回答：是，您可透過手動設定 MFA 程序來測試其 MFA。 我們鼓勵您設定並進行測試。 如果您使用條件式存取來強制執行 MFA，您可以使用條件式存取範本來測試您的原則。 如需其他資訊，請參閱《管理員需要多重要素驗證才能存取 Microsoft 系統管理入口網站》。 如果您執行免費版本的 Microsoft Entra ID，您可以啟用安全性預設值。
問題：如果我已啟用 MFA，接下來會發生什麼情況？
答：已要求 MFA 的客戶，其使用者若存取先前列出的應用程式，則看不到任何變更。 如果您只需要使用者子集的 MFA，則任何尚未使用 MFA 的使用者，現在都必須在登入應用程式時使用 MFA。
請問：如何在 Microsoft Entra ID 中檢閱 MFA 活動？
回應：若要檢閱使用者何時提示使用 MFA 登入的詳細數據，請使用 Microsoft Entra 登入記錄。 如需其他資訊，請參閱《Microsoft Entra 多重要素驗證之登入事件詳細資料》。
問題：如果我遇到「破玻璃情況」，該怎麼辦？
回答：建議更新這些帳戶，以使用密鑰 (FIDO2) 或設定 MFA 的憑證式驗證。 這兩種方法都滿足 MFA 需求。
問題：如果我在強制執行 MFA 之前未收到有關啟用 MFA 的電子郵件，然後我遭到鎖定，該怎麼辦。如何加以解決？
答：使用者不應該被鎖定，但當對其租戶開始強制執行 MFA 時，他們可能會收到提示啟用 MFA 的訊息。 如果使用者遭到鎖定，可能會有其他問題。 如需詳細資訊，請參閱帳戶已鎖定。
相關內容
請檢閱下列主題，以深入了解如何設定及部署 MFA：