無密碼驗證可將密碼取代為更強的登入方法，例如 Windows Hello、FIDO2 安全性金鑰、通行金鑰、憑證、Microsoft Authenticator 手機登入和臨時存取密碼，藉此減少網路釣魚和認證竊取。
Microsoft Intune 不會發出無密碼認證。 相反地，它會準備裝置、應用程式和使用者體驗，讓這些無密碼方法大規模可靠地運作。 Microsoft Entra ID 是身分識別授權單位，可驗證認證並強制執行驗證和條件式存取原則，而 Microsoft Intune 則會設定裝置設定、強制執行合規性，並啟用這些方法所依存的平台功能。 Microsoft Entra ID 和 Microsoft Intune 一起提供跨不同平台和板型規格採用無密碼驗證所需的身分識別基礎和裝置整備。
無密碼體驗會因平台而異。 在 Windows 上，它通常同時涵蓋裝置登入和透過 SSO 的應用程式存取。 在 macOS 上，它以平台驗證和 SSO 進入應用程式為中心，而不是深層裝置繫結身分識別。 在 iOS/iPadOS 和 Android 上，它更常著重於應用程式登入、代理驗證和通行金鑰行為，而不是裝置登入。 在評估平台需求和規劃部署時，請牢記這些差異。
本文說明 Microsoft Intune 如何從系統管理員的觀點支援無密碼策略。 如需部署詳細資料，請遵循每個無密碼方法的實作連結。
Microsoft 的無密碼解決方案如何運作
Microsoft 的無密碼解決方案將Microsoft Entra ID用於身分識別和單一登入 (SSO) 與裝置設定和原則強制執行的Microsoft Intune配對。 此組合可讓使用者使用強式認證進行驗證，例如生物識別技術、FIDO2 安全性金鑰或通行金鑰，而不需要輸入密碼。
Microsoft Entra ID 是核心身分識別提供者。 它會驗證無密碼的認證，例如 Windows Hello PIN、FIDO2 金鑰和通行金鑰。 驗證成功之後，Microsoft Entra ID 會 (PRT) 或同等功能發出主要重新整理權杖，讓無縫 SSO Microsoft 365、Azure 和其他受保護的資源。 條件式存取原則會在授與存取權之前評估裝置狀態、驗證強度和風險訊號。
Microsoft Intune 會透過設定設定、強制執行合規性、部署必要的應用程式，以及支援讓無密碼大規模實用的平台體驗，為無密碼登入做好準備。 Microsoft Intune 為系統管理員提供一個適用於 Windows、macOS、iOS/iPadOS 和 Android 的管理平面。
Windows、macOS、iOS 和 Android 上的平台功能提供裝置繫結體驗，包括生物特徵辨識、Windows 上安全硬體 (TPM、macOS) 上的安全隔離區、通行金鑰支援，以及代理單一登入。
這種分離很重要。 Microsoft Entra ID 是身分識別授權單位。 Microsoft Intune 是管理層，可協助使用者順利採用和使用這些方法。
無密碼、MFA 和網路釣魚防護
無密碼驗證無法消除安全性因素。 大部分無密碼方法實際上都符合多重要素驗證 (MFA) 需求。 例如，Windows Hello 使用裝置繫結認證 (擁有) ，搭配生物特徵辨識手勢 (固有) 或 PIN (知識) ，從設計上滿足 MFA。 因此，條件式存取驗證強度原則會將許多無密碼方法分類為 符合 MFA 規範 ，或甚至是 防網路釣魚 MFA。
並非所有無密碼選項都提供相同層級的保護。 瞭解 防網路釣魚 和 非防網路釣魚 方法之間的區別可以幫助您選擇正確的身份驗證強度並設計安全的身份策略。
- 防網路釣魚 方法使用硬體繫結的非對稱式密碼編譯金鑰，即使使用者與惡意或詐騙的提示互動也無法攔截或重播。
- 非防網路釣魚 的方法使用無密碼流程，但仍可能透過社交工程、提示操作或 MFA 疲勞而遭到入侵。
本文稍後將說明的每種方法都包含其抗網路釣魚等級。
深入了解
使用 Microsoft Intune 進行無密碼驗證的優點
當您將 Microsoft Intune、Microsoft Entra ID 和平台功能一起使用時，您的組織將獲得：
- 無縫單一登入：使用者只要登入裝置一次，就能自動存取應用程式、雲端服務，在某些情況下也會自動存取內部部署資源。 密碼重設呼叫和重複的驗證提示已消除。
- 跨裝置的使用者便利性： 使用者在跨裝置獲得原生、一致的體驗。 Windows Hello 使用作業系統登入，macOS 整合 Touch ID 與 Microsoft Entra ID，而行動平台使用 Microsoft Authenticator 和平台通行金鑰。 使用者不需要同時處理每個裝置的個別密碼。
- 更強大的安全性態勢：防網路釣魚方法可防止認證竊取和重播攻擊。 裝置合規性控制可確保即使是有效的認證也只能在運作正常的受管理裝置中運作，這符合零信任原則。
- 降低 IT 支援負載： 更少的密碼重設次數、使用臨時存取密碼更順暢地上線，以及自助復原選項可減少技術服務人員的工作量。
- 面向未來的架構：隨著標準的演進，新的無密碼方法（包括同步的通行金鑰和硬體支援的認證）可以插入相同的 Microsoft Entra ID + Microsoft Intune 架構，而不需要重新設計。
Microsoft Intune 如何推動無密碼採用
Microsoft Intune 可確保裝置和應用程式已正確設定為使用強式新式認證，以啟用無密碼驗證並將其付諸實行。 當 Microsoft Entra ID 控管身分識別和驗證原則時，Microsoft Intune 會準備無密碼方法相依的裝置環境。
主要貢獻包括：
- 裝置整備： 註冊、註冊及設定裝置，讓裝置可以參與無密碼的登入流程。
- 設定部署：提供 Windows Hello 企業版、憑證型驗證、Apple 平台 SSO 和類似平台功能所需的原則。
- 合規性和存取訊號：提供裝置健康情況與合規性資料，條件式存取會在授與存取權之前進行評估。
- 應用程式和代理程式佈建：部署核心應用程式，例如 Microsoft Authenticator 和 Microsoft Intune 公司入口網站，以啟用身分識別代理和無密碼 SSO 案例。
- 統一的跨平台管理：在 Windows、macOS、iOS/iPadOS 和 Android 之間提供一致的策略和管理框架，以簡化企業部署。
使用者可用的無密碼方法取決於裝置平台和 Microsoft Entra ID 中啟用的驗證選項。 Microsoft Intune 可確保每個裝置都已準備就緒、設定好，且能夠提供安全且可靠的無密碼體驗。
Windows Hello
防網路釣魚
Windows Hello 會使用產生並密封至 TPM 的裝置繫結非對稱金鑰來取代密碼。 金鑰的存取權由 PIN 或生物特徵辨識手勢 (指紋或臉部辨識) 控制，將擁有權與固有性結合在單一登入步驟中。 此方法為硬體支援，且適用於 Windows 裝置的防網路釣魚。
Intune 的角色
Microsoft Intune 透過傳遞和強制執行 Windows Hello 企業版原則設定，為 Windows Hello 準備 Windows 裝置。在您需要以下情況時，此方法最為相關：
- 準備雲端優先的 Windows 裝置以進行無密碼登入。
- 在註冊和持續管理期間提供 Windows Hello 企業版原則設定。
- 使 Windows 登入與裝置合規性和新式管理保持一致。
FIDO2 安全性金鑰
FIDO2 安全性金鑰是實體裝置， (USB、NFC 或藍牙) ，可儲存 FIDO 認證並提供防網路釣魚驗證，而不依賴裝置平台。 由於認證已繫結到硬體金鑰，並透過密碼編譯挑戰進行驗證，因此無法攔截或重新執行。 FIDO2 金鑰非常適合共用裝置、高保證環境，或作為平台型認證旁的復原路徑。
Microsoft Intune 可透過管理支援的平台和相關的登入體驗，協助裝置為此方法做好準備。當組織需要以下情況時，此方法通常很適合：
- 適用於共用或專用裝置的可攜式無密碼選項。
- 強大的防網路釣魚選項，不會繫結至單一平台或 Microsoft Authenticator。
- 復原路徑或替代路徑以及平台型認證。
密鑰
通行金鑰是 FIDO 憑證的標準總括，可以繫結裝置或跨裝置同步。 在 Microsoft Entra ID 中，您可以使用：
- 裝置繫結通行金鑰儲存在單一裝置上的安全硬體 (TPM 或 Secure Enclave) 中，例如透過 iOS 17+ 和 Android 14+ 上的 Windows Hello 或 Microsoft Authenticator。
- 由 iCloud 鑰匙圈或 Google 密碼管理器等平台密碼管理器管理的同步通 () 或支援的第三方提供者管理，可實現跨裝置使用。
- Windows 上的 Microsoft Entra 金鑰是 FIDO2 金鑰，使用 Windows Hello 進行生物特徵辨識驗證，但不需要裝置加入或註冊。 使用者可以在相同裝置上為多個 Microsoft Entra 帳戶註冊多個通行金鑰，使其非常適合共用裝置、未受管理的端點，以及未佈建 Windows Hello 企業版的案例。
從 Microsoft Intune 的觀點來看，通行金鑰主要與平台和應用程式整備程度有關—管理裝置和應用程式先決條件，使通行金鑰可跨平台採用。這種依賴性在以下方面尤為重要：
- Windows，其中平台登入和 Windows Hello 可以與更廣泛的無密碼規劃相交。 Windows 上的 Microsoft Entra 通行金鑰可將通行金鑰涵蓋範圍延伸至未註冊或未加入的裝置，以補充受管理裝置上的 Windows Hello 企業版。
- iOS/iPadOS 和 Android，其中通行金鑰可能取決於行動裝置狀態和應用程式代理人行為。
- macOS，其中平台身分整合和使用者登入體驗會影響採用。
Microsoft Authenticator 手機登入
不防網路釣魚
Microsoft Authenticator 手機登入會以推播式核准和使用者信任的行動裝置上的號碼比對取代密碼。 它方便且受到廣泛支援，但仰賴推播通知，而不是硬體繫結的認證，這表示它無法完全防止網路釣魚攻擊，例如 MFA 提示操作。
注意事項
Microsoft Authenticator 也可以 儲存 iOS 17+、Android 14+) (裝置繫結通行金鑰， 這些通行 金鑰具有防網路釣魚功能。 本節專門涵蓋推播式手機登入流程。
Microsoft Intune 透過部署和管理行動裝置應用程式和裝置必要條件來支援此流程。在許多環境中，這項支援包括：
- 將 Microsoft Authenticator 部署到受管理的行動裝置。
- 支援跨 Microsoft 應用程式的代理登入體驗。
- 當行動裝置上的應用程式保護原則考量屬於更廣泛的行動裝置存取設計的一部分時，考慮這些因素。
臨時存取密碼
臨時存取密碼 (TAP) 是系統管理員簽發的限定時間認證，以協助使用者在完成長期無密碼設定之前啟動或復原存取權。 TAP 不是永久的無密碼方法，也不是防網路釣魚，但它通常是成功推出的關鍵部分，因為它無需發行密碼即可解決首次登入問題。
從 Microsoft Intune 的觀點來看，在您想要以下情況下，臨時存取密碼很重要：
- 簡化上線至無密碼方法。
- 在部署期間減少對暫存密碼的依賴。
- 將上線案例連線到受管理的 Windows 裝置設定。
使用 TAP 進行歸零上線
無密碼部署中常見的挑戰是先 有雞還是先有蛋的問題 ：新使用者必須登入才能註冊其無密碼認證，但您不想在第一次登入時發出密碼。 TAP 透過提供用於初始裝置設定和認證註冊的短期認證來解決此問題。
一般的上線流程如下所示：
- 管理員發出 TAP - IT 系統管理員或自動化工作流程會在 Microsoft Entra 系統管理中心或透過 Microsoft 圖形 API 為新使用者產生有時間限制的 TAP。
- 使用者設定其裝置 — 使用者在 Windows Autopilot OOBE、macOS 設定助理或行動裝置註冊期間輸入 TAP。 在 Windows 11 上，網路登入可直接在鎖定畫面上輸入 TAP 項目。
- 使用者註冊無密碼方法 - 使用 TAP 登入後，系統會提示使用者註冊 Windows Hello、FIDO2 安全性金鑰、Microsoft Authenticator 中的通行金鑰或其他無密碼方法。 這是取代 TAP 的永久認證。
- TAP 到期 — TAP 是單次使用或有時間限制 (可設定的) ，因此在使用者註冊其無密碼方法後就無法重複使用。
此流程免除發行然後撤銷暫存密碼的必要，並從第一次登入開始提供 Microsoft Intune 受管理的上線路徑。
憑證型驗證 (CBA)
憑證型驗證 (CBA) 使用數位憑證和非對稱式密碼編譯來驗證身分識別，使其具有防網路釣魚功能並防止憑證重播。 它廣泛應用於受監管的行業和政府環境，通常透過 PIV 和 CAC 等智慧卡。 不同於 Microsoft Intune 主要準備裝置環境的其他無密碼方法，CBA 是 Microsoft Intune 在散發認證本身中直接扮演角色的其中一個領域。
Microsoft Intune 支援兩種基礎結構模型進行憑證傳遞：
- 內部部署 PKI：擁有現有憑證授權單位 (CA) 的組織可以使用適用於 Microsoft Intune 的憑證連接器來橋接其內部部署 PKI 與 Microsoft Intune。 連接器可讓 Microsoft Intune 使用現有的 CA 基礎結構將 SCEP 和 PKCS 憑證設定檔部署到受管理的裝置。 此模型適合已經運營企業 CA 或需要與已建立的 PKI 投資整合的組織。
- Microsoft Cloud PKI：對於想要簡化或消除內部部署憑證基礎結構的組織，Microsoft Cloud PKI 提供雲端式 CA 作為 Microsoft Intune Suite 的一部分。 雲端 PKI 發行並管理憑證，不需要內部部署伺服器、連接器或硬體安全性模組。
無論基礎結構模型為何，Microsoft Intune 都會使用憑證設定檔將憑證傳遞至裝置：
- 受信任的根憑證設定檔會 散發 CA 的根憑證，讓裝置可以建立信任鏈。
- SCEP 憑證設定檔會 從啟用 SCEP 的 CA 要求和部署憑證。
- PKCS 憑證設定檔會 使用 PKCS #12 標準來要求和部署憑證。
- 匯入的 PFX 憑證設定檔會部署預先產生的憑證，這些憑證會匯入到 Microsoft Intune。
這些設定檔可在 Windows、macOS、iOS/iPadOS 和 Android 上使用，讓 Microsoft Intune 成為傳遞機制，將 PKI 基礎結構（無論是內部部署或雲端式）連線至 Microsoft Entra ID 中定義的身分識別方法。
必要條件
在規劃無密碼部署之前，請先確認您的環境符合您打算使用方法的授權與平台需求。 某些無密碼功能需要特定的 Microsoft Entra ID 或 Microsoft Intune 授權層，而且每個方法都有最低作業系統版本需求。
授權需求
視您選擇的無密碼方法而定，您的組織可能需要使用者的 Microsoft Entra ID P1 或 Microsoft Entra ID P2 授權，以及裝置管理和憑證傳遞的特定 Microsoft Intune 授權。 下表摘要說明常見的無密碼功能的授權需求：
| 功能 | 授權需求 |
|---|---|
| Windows Hello | Microsoft Entra ID P1 (條件式存取強制) |
| FIDO2 安全性金鑰 | Microsoft Entra ID P1 |
| 通行金鑰 (裝置繫結和同步) | Microsoft Entra ID P1 |
| Microsoft Authenticator 手機登入 | Microsoft Entra ID P1 |
| 臨時存取密碼 | Microsoft Entra ID P1 |
| 憑證型驗證 (CBA) | Microsoft Entra ID P1 (P2 用於以風險為基礎的條件式存取) |
| 驗證強度原則 | Microsoft Entra ID P1 |
| 以風險為基礎的條件式存取 | Microsoft Entra ID P2 |
| Microsoft 雲端 PKI | Microsoft Intune Suite 或獨立雲端 PKI 授權 |
| 裝置合規性和組態設定檔 | Microsoft Intune 方案 1 |
深入了解
平台需求
本文所述的無密碼方法仰賴僅在特定作業系統版本中提供的特定平台功能。 下表摘要說明每個方法的平台需求：
| 方法 | Windows | macOS | iOS/iPadOS | Android |
|---|---|---|---|---|
| Windows Hello | 所有 支援的 Windows 用戶端 | — | — | — |
| FIDO2 安全性金鑰 | 所有 支援的 Windows 用戶端 | — | — | — |
| 密鑰 | Windows 11 | 所有 支援 的版本 | 所有 支援 的版本 | Android 14+ |
| Microsoft Authenticator 中的裝置繫結通行金鑰 | — | — | 所有 支援 的版本 | Android 14+ |
| 平台 SSO (Secure Enclave) | — | 所有 支援 的版本 | — | — |
| 網路登入 (TAP 在鎖定畫面) | Windows 11 | — | — | — |
| Microsoft Authenticator 手機登入 | — | — | 所有 支援 的版本 | Android 11+ |
注意事項
支援是指 Microsoft Intune 目前針對完整功能、原則部署和管理所支援的作業系統版本。
平台版本需求可能會隨著每個發行週期而變更。 請務必在產品文件中針對您要部署的特定方法確認目前需求。
深入了解
平台考量
無密碼不是一項功能。 這是一組平台特定體驗，依賴 Microsoft Entra ID 進行身分識別，並依賴 Microsoft Intune 進行裝置管理。
Windows
Windows 是裝置註冊、雲端登入、安全性狀態和無密碼使用者體驗如何協同運作的最完整範例。
Microsoft Intune 通常透過下列方式支援 Windows 無密碼案例：
- 準備雲端優先、已加入 Microsoft Entra 的裝置。
- 提供 Windows Hello 企業版設定。
- 支援 FIDO2 安全性金鑰體驗。
- 使裝置整備程度與合規性和現代管理保持一致。
- 支援可連線至 Windows Autopilot 的上線體驗。
當使用者使用 Windows Hello 或 FIDO2 金鑰登入時，Windows 會從 Microsoft Entra ID 取得主要重新整理權杖。 該 PRT 可讓您無縫 SSO 到 Microsoft 365 應用程式、SaaS 應用程式，以及檔案共用等內部部署資源，全部都不需要額外的登入提示。
混合式和舊版考量
本文所述的無密碼體驗採用雲端優先的模式與加入 Microsoft Entra 的裝置。 使用混合式 Microsoft Entra 加入裝置的組織應該注意以下差異：
- 網路登入 (用於 Windows 鎖定畫面上的 TAP) 僅支援加入Microsoft Entra的裝置，而非加入混合Microsoft Entra的裝置。
- Windows Hello 企業版可用於加入 Microsoft Entra 和加入混合式 Microsoft Entra 的裝置，但混合式部署可能需要額外的基礎結構，視信任模型而定。
- 從加入 Microsoft Entra 的裝置存取內部部署資源需要雲端 Kerberos 信任或憑證型信任。 建議使用雲端 Kerberos 信任，因為它不需要部署 Kerberos 驗證的憑證。 如需詳細資訊，請參閱 [雲端 Kerberos 信任部署] (/windows/security/identity-protection/> hello-for-business/deploy/hybrid-cloud-kerberos-trust) 。
- 需要 Active Directory Kerberos 驗證的舊版應用程式仍然可以使用無密碼方法，但需要 NTLM 或直接 LDAP 繫結的應用程式可能需要額外規劃。
如果您的環境是混合式的，請從加入 Microsoft Entra 的裝置開始規劃無密碼推出，並根據您的基礎結構支援擴充為混合式 Microsoft Entra 加入裝置。
macOS
在 macOS 上，無密碼規劃取決於 Microsoft Entra ID 與平台登入和單一登入體驗整合的方式。 Microsoft Intune 提供以 Apple 為中心的身分識別整合所需的裝置設定。
使用 Microsoft 企業 SSO 外掛程式和 Apple 的平台 SSO 架構，Microsoft Intune 可以部署允許使用者使用其 Microsoft Entra ID 認證登入 Mac 的設定。 當使用 [安全隔離區] 金鑰方法進行設定時，可提供類似於 Windows Hello 的防網路釣魚、硬體支援的登入體驗。
在您規劃時，此資訊非常重要：
- 平台 SSO 和相關的登入體驗。
- 在裝置與 Microsoft 應用程式之間進行單一登入。
- 與 Windows 和行動裝置一致的管理模型。
iOS 和 iPadOS
在 iOS 和 iPadOS 上，無密碼規劃更著重於 App 登入、代理驗證和通行金鑰行為，而不是裝置登入。 Microsoft Intune 會部署和管理應用程式和設定，讓使用者獲得一致的體驗。
iOS 上的 Microsoft SSO 擴充功能可以攔截 Microsoft 和第三方應用程式之間的驗證要求，以便在初始裝置設定後實現無縫登入。 Microsoft Authenticator 可作為驗證代理人，也可以在 iOS 17+ 上儲存裝置繫結通行金鑰，以進行防網路釣魚驗證。
Android
在 Android 上，Microsoft Intune 會建立無密碼和代理驗證流程所依存的受管理內容。 當 Microsoft Authenticator 或相關應用程式體驗是行動裝置存取設計的一部分時，此內容特別相關。
公司入口網站和 Microsoft Authenticator 都可以充當 Android 上的驗證代理人。 使用者透過代理人登入後，Microsoft Entra ID 會發出主要重新整理權杖，可在工作設定檔中的所有代理人感知應用程式之間啟用 SSO。 在 Android 14+ 上，Microsoft Authenticator 也可以儲存裝置繫結通行金鑰，以進行防網路釣魚驗證。
無密碼驗證的相依性
零信任架構
無密碼驗證是更廣泛的身分識別和裝置存取策略的一部分。 對於 Microsoft Intune 系統管理員，規劃通常涉及以下層：
- 身分識別： Microsoft Entra ID 中的防網路釣魚驗證方法。
- 裝置信任： Microsoft Intune 註冊、合規性和設定。
- 存取原則：條件式存取和相關的排除規劃。
- 資料保護：Microsoft Purview 功能，可協助在授與存取權後保護內容。
- 調查與回應： 當風險或入侵需要後續追蹤時，Microsoft Defender 訊號和工作流程。
深入了解
條件式存取
條件式存取會在授與存取權之前，評估裝置狀態和驗證強度等訊號。 與無密碼方法結合使用時，條件式存取可以強制執行需要防網路釣魚 MFA 的驗證強度原則，透過封鎖密碼或簡訊代碼等較弱的方法，有效強制執行無密碼。
當您在無密碼旁實作條件式存取時，也請考慮緊急存取規劃，以防止意外鎖定案例。
深入了解
緊急存取和復原
移除密碼時，常見的問題是當使用者遺失唯一的無密碼裝置時會發生什麼情況，- 手機、FIDO2 金鑰，或是裝有 Windows Hello 的膝上型電腦。 如果沒有復原方案，管理員可能會面臨支援升級，使用者可能會被鎖定在關鍵資源之外。
在無密碼部署過程中規劃這些案例：
- 緊急存取帳戶： 維護至少兩個從條件式存取原則和無密碼強制執行中排除的突破性帳戶。 如果設定錯誤或中斷封鎖所有其他存取，這些帳戶會提供後援路徑。 安全地儲存認證並監控這些帳戶的登入活動。
- 使用臨時存取密碼復原：當使用者遺失無密碼裝置時，系統管理員可以發出新的 TAP，以便使用者可以登入並註冊替代認證。 此方法可避免將使用者重設為密碼，並將復原流程保留在無密碼模型內。
- 多個註冊方法： 鼓勵使用者盡可能註冊一個以上的無密碼方法。 例如，在膝上型電腦上使用企業版 Hello 的使用者也可能在其手機上的 Microsoft Authenticator 中註冊通行金鑰。 如果遺失一台裝置，另一種方法仍然有效。
- 自助認證管理：使用者可以在 [我的安全性資訊] 管理其驗證方法。 與 TAP 型復原結合使用時，此方法可減少認證重設的技術服務台相依性。
- 使用驗證識別碼進行全損復原：針對使用者遺失所有已註冊認證和裝置的情況，使用驗證識別碼的 Microsoft Entra 帳戶復原提供不依賴密碼或技術服務中心核發認證的身分識別驗證復原路徑。
在強制執行無密碼之前規劃復原非常重要。 在沒有復原路徑的情況下封鎖密碼的推出會造成鎖定案例，從而削弱管理員和使用者對轉換的信心。
深入了解
合規性和裝置整備
無密碼通常取決於裝置在使用者可以依賴體驗之前是否處於正確狀態。 整備程度通常包括：
驗證和持續作業
若要驗證無密碼部署，常見的檢查點包括：
- Microsoft Entra 登入記錄檔
- Microsoft Intune 裝置和原則報告
- 您部署之無密碼方法的平台特定驗證體驗。
使用者採用和通訊
技術整備只是無密碼推出的一部分。 當登入流程變更時，習慣密碼的使用者可能會感到困惑或抗拒。 規劃使用者通訊和支援可以決定平穩過渡和廣泛的服務台升級。
請考慮下列作法：
- 及早傳達變更： 讓使用者知道他們的登入體驗正在改變、改變的原因以及預期會發生什麼。 著重優點 - 需要記住的密碼更少、登入速度更快，安全性更強。
- 提供平台特定的指引： 無密碼體驗在 Windows (Hello 生物特徵辨識或 PIN) 、macOS (Touch ID 與平台 SSO) 、iOS (Authenticator 或通行金鑰) ，以及 Android (Authenticator 代理程式) 上不同。 根據您的用戶擁有的平台定制通信。
- 識別試驗群組：從一群可以測試體驗並提供意見反應的使用者開始，然後再在整個組織強制使用無密碼。 IT 人員、早期採用者和具有安全性意識的團隊通常是很好的候選人。
- 準備技術支援人員：確保您的支援團隊知道如何發放用於復原的臨時存取通行證、如何引導使用者完成認證註冊，以及在出現問題時在何處檢查登入記錄。
深入了解