Microsoft Entra ID 2026年7月下旬：SharePoint OTP 淘汰時程更新、Cloud Sync 遷移啟動、Teams Rooms 邁向無密碼

Microsoft Entra ID 在 2026 年 7 月下旬的更新聚焦於轉型——協助組織擺脫舊式的驗證與同步方法，邁向以身份為核心的現代化架構。從 SharePoint 一次性密碼（One-Time Passcode）淘汰時程的調整，到 Entra Connect Sync 移轉至 Cloud Sync 的通知啟動，Microsoft 正有系統地關閉舊有路徑。再加上 Teams Rooms 的無密碼化以及 Purview 與 GSA 網路層的整合，IT 管理員有許多事項需要著手處理。

1. SharePoint 一次性密碼淘汰：更新時程（MC1243549）

公告日期： 2026 年 7 月 17 日（更新版） 來源： M365 Message Center（MC1243549）

變更內容

Microsoft 已更新 SharePoint 一次性密碼（SPO OTP）驗證的淘汰時程——這項舊式方法允許外部使用者無需 Microsoft 帳戶，僅透過一次性電子郵件驗證碼即可存取共用的 SharePoint 與 OneDrive 內容。

修訂後的時程如下：

• 第一階段（已完成）： 新的外部共用邀請現已改用 Microsoft Entra B2B，而非 SPO OTP。此階段已於 2026 年 7 月中旬在正式環境中全面推出。
• 第二階段（已重新排程）： SPO OTP 驗證將於 2026 年 10 月 1 日開始淘汰，預計於 2026 年 10 月 31 日前完成。原先的執行期間較為寬鬆。
• GCC、GCCH 與 DoD 環境： 兩階段皆不適用。這些環境的新時程將透過 Message Center 另行通知。

為何重要

當第二階段啟動後，沒有 Entra B2B 來賓帳戶的外部使用者，在嘗試存取先前已共用但設為「特定人員」的連結時，將會收到「拒絕存取」（Access Denied）錯誤。若要恢復存取，可透過以下任一方式：

• 在 Entra B2B 中為外部使用者建立來賓帳戶，或
• 由授權的內部使用者重新與該外部使用者共用至少一個檔案、資料夾或網站

EnableAzureADB2BIntegration 設定將不再控制外部共用行為，且停用 Entra B2B 整合的選項也將完全移除。

IT 管理員應如何準備

1. 識別受影響的內容： 稽核 SharePoint 與 OneDrive 中目前依賴 OTP 驗證的共用連結
2. 盤點外部使用者： 識別經常協作的外部合作對象，並在 10 月 1 日前為他們建立 Entra B2B 來賓帳戶
3. 更新共用政策： 確保您的 Entra External ID 與 B2B 邀請設定支援大規模來賓上線
4. 與網站擁有者溝通： 告知 SharePoint 網站擁有者 10 月 1 日的轉換期限，以便他們主動與外部使用者重新共用內容
5. 測試來賓存取： 驗證已建立來賓帳戶的外部使用者能否正常存取先前共用的內容

這是一個硬性截止日期——10 月 1 日即將到來，對那些在 SharePoint 中有大量外部協作需求的組織而言，現在就必須開始準備。

2. Entra Connect Sync 移轉至 Cloud Sync 通知正式啟動

公告日期： 2026 年 7 月 來源： M365 Message Center + Entra Connect Health + 目標電子郵件

最新動態

Microsoft 已開始向符合條件的租用戶發送專屬的移轉通知，協助其從 Microsoft Entra Connect Sync 移轉至雲端原生的 Microsoft Entra Cloud Sync。這項行動延續了 2026 年 4 月發布的「規劃變革」（Plan for change）公告，代表了第一批實際移轉窗口的指派。

關鍵細節：

• 通知透過 M365 Message Center、Entra Connect Health 以及目標導向的電子郵件發送
• 每個租用戶會收到專屬的移轉窗口與移轉指引
• 這並非全面性的統一轉換截止日期——而是採用逐步、逐租用戶的方式

重要提醒：功能缺口仍然存在

依賴 Cloud Sync 尚未支援之功能的租用戶，無需強制移轉。Microsoft 的移轉常見問題（FAQ）明確指出，組織可以繼續使用 Connect Sync，同時關注功能比較表，待所需情境在 Cloud Sync 中獲得支援後再行移轉。

然而，大方向已經很明確：Cloud Sync 正逐步成為混合身份同步的首選平台，而 Connect Sync 則會繼續為有未支援相依功能的組織提供服務。

IT 管理員應如何準備

步驟 1：盤點您的 Connect Sync 相依項目 記錄 Connect Sync 目前管理的所有項目——組織單位（OU）、網域、自訂同步規則、屬性對應、密碼回寫設定、裝置同步以及任何延伸安裝。

步驟 2：比對 Cloud Sync 功能 檢視 Microsoft 官方發布的 Connect Sync 與 Cloud Sync 功能比較表。不要只停留在簡單的「支援／不支援」標籤——應建立一份書面清單，詳列各項必要功能及其決策與負責人。

步驟 3：設計測試邊界 如果您的租用戶符合移轉條件，請在影響正式環境之前，先設計以 OU 為基礎的測試邊界。Microsoft 不支援 Connect Sync 與 Cloud Sync 同時管理相同物件——這是一項必須遵守的嚴格技術限制。

步驟 4：先驗證再擴展

• 在 Cloud Sync 接手之前，務必確認 Connect Sync 已不再管理測試物件
• 先在隔離的子集上驗證 Cloud Sync，再擴展至其他 OU
• 在轉換期間，記錄每個正式環境 OU 由哪個同步工具負責管理

步驟 5：記錄阻礙因素 如果您有未獲支援的功能，請清楚記錄下來。保留相關證據，並在繼續使用 Connect Sync 的同時，持續關注 Microsoft 功能比較表的更新。

重點總結

這是目前為止最明確的信號：Cloud Sync 的時代已經到來，但 Microsoft 明智地為暫時無法移轉的組織保留了退路。最有價值的準備工作，不是急著移轉——而是建立一份清晰的決策記錄，列出您目前的相依項目、界定哪些 OU 屬於移轉範圍，並確認 Cloud Sync 是否支援所有必要情境。

3. Teams Rooms 無密碼資源帳戶支援（RM558853）

公告日期： 2026 年 7 月 來源： M365 Roadmap（RM558853）

最新功能

Windows 裝置上的 Microsoft Teams Rooms 現在支援透過 Microsoft Entra ID 對資源帳戶進行無密碼驗證。這使得 Teams Rooms 能夠使用現代化、抗釣魚攻擊的憑證進行驗證，不再依賴傳統的使用者名稱／密碼組合來存取共用會議室帳戶。

為何重要

長期以來，會議室資源帳戶一直是 IT 團隊的痛點：

• 密碼輪換負擔： 資源帳戶密碼需要定期輪換，對於大規模的會議室群組而言，營運成本相當高昂
• 憑證暴露風險： 會議室裝置中的共用憑證本質上存在弱點——任何能實體接觸裝置的人都有可能將其擷取
• Conditional Access 挑戰： 以密碼為基礎的帳戶難以納入嚴格的驗證政策

Teams Rooms 的無密碼驗證一次解決了上述三個問題，使會議室裝置與 Microsoft 更廣泛的 Zero Trust 及抗釣魚驗證策略保持一致。

IT 管理員應如何準備

1. 識別符合條件的裝置： 確認您的 Teams Rooms on Windows 裝置中，哪些使用了已加入 Entra ID 的資源帳戶
2. 檢視驗證方法政策： 確保您的 Entra ID 驗證方法政策允許包含 Teams Rooms 帳戶的安全性群組使用無密碼憑證
3. 先從單一會議室測試： 在全面部署前，先在受控環境中測試無密碼流程
4. 檢查 Conditional Access： 檢視任何可能封鎖或挑戰會議室裝置登入的 CA 政策——確保您的合規性與裝置狀態條件能適用於會議室裝置
5. 更新佈建文件： 如果您有自動化的 Teams Rooms 部署指令碼，請更新使其在初始設定時即配置無密碼驗證

4. Microsoft Purview 與 Entra GSA Internet Access 整合（RM522096）

公告日期： 2026 年 7 月 來源： M365 Roadmap（RM522096）

最新功能

Microsoft 宣布 Microsoft Purview 與 Entra Global Secure Access（GSA）Internet Access 整合，以實現網路層的敏感檔案過濾功能。這項功能擴展了 2026 年 7 月 1 日宣布的 Purview + Entra 整合（原涵蓋 SaaS 與 AI 應用程式資料保護），現在進一步包含了網路層的執行機制。

運作方式

此整合讓組織能夠將 Purview 敏感度標籤與資料外洩防護（DLP）政策應用於 Entra GSA Internet Access 所檢查的網路流量。這意味著：

• 透過 GSA Internet Access 上傳或下載的檔案可被檢查其敏感度標籤
• DLP 政策可以在網路層級封鎖或監控敏感檔案的傳輸——在資料到達非受管目的地之前即進行攔截
• 強制執行發生在更早的資料流階段，補強了應用程式層級的控制

為何重要

傳統 DLP 在應用程式或服務層級運作——它只能在有人試圖透過特定應用程式分享敏感資料時將其攔截。但那些繞過應用程式層級控制的網路路徑呢？網路層的敏感檔案過濾正好填補了這個缺口：

• 攔截影子 IT 傳輸： 透過非受管應用程式或直接網路傳輸移動的檔案
• 增加縱深防禦： 即使應用程式層級的 DLP 被繞過，網路層過濾仍能提供一道安全網
• 實現一致的政策： 同一套 Purview 標籤與政策可在應用程式與網路執行點同時生效

IT 管理員應如何準備

1. 跨團隊協調： 此整合涉及身份（Entra）、安全性（Purview/DLP）與網路（GSA）——確保所有相關團隊都參與規劃
2. 盤點敏感標籤： 檢視您現有的 Purview 敏感度標籤與 DLP 政策，判斷哪些應在網路層實施強制執行
3. 規劃受控測試： 網路層過濾可能影響合法流量——請先在受控環境中針對少量使用者進行測試，再大規模推行
4. 繪製流量路徑： 了解組織中哪些網路路徑承載敏感資料，以及 GSA Internet Access 如何定位以檢查這些流量
5. 監控誤判情況： 在網路速度下進行檔案類型與內容過濾可能會產生誤判——在啟用強制模式前，應建立調校流程

宏觀趨勢：身份驗證正在取代舊式存取

綜觀這四項更新，一個明確的主題浮現了：Microsoft 正在有系統地以明確、基於身份的驗證方式，取代隱含式與舊式的存取方法。

每一項轉換都在數月或數年前就已預告，而 Microsoft 現在正從公告階段進入執行階段。能夠順利應對這些變化的組織，是那些早已開始盤點舊有相依項目並規劃移轉的組織——而非等到最後一刻才倉促應對的組織。

對於 SharePoint OTP 的淘汰，10 月 1 日是明確的截止日期。對於 Cloud Sync 移轉，您的租用戶專屬窗口隨時可能到來。至於 Teams Rooms 與 Purview-GSA，則是可以依自身步調逐步採用的新功能——但發展方向已然明確。

行動摘要

更多 Entra ID 最新資訊，請追蹤 @kkaminsk on X 並定期造訪本站。Big Hat Group Inc. 提供微軟顧問服務，專注於 AI 與身份識別技術。