Passkey 與 Security Key：差異與如何選擇

什麼是 Passkey 和 Security Key？

2021 年，Colonial Pipeline 將一起勒索軟體事件追溯至遭入侵的 VPN 密碼，且該公司支付了約 440 萬美元贖金，根據 DOJ 發布的資訊。這就是以憑證為基礎的初始存取在營運上的現實：當攻擊者可以進行網路釣魚、重複使用，或執行 憑證填充 來攻擊以密碼為基礎的驗證時，他們不需要零時差漏洞。

Passkey 和實體 security key 都是為了彌補這個缺口而存在。它們使用相同的密碼學基礎，但在保護企業時，憑證的儲存與管理方式差異至關重要。

A Passkey 是一種 FIDO 驗證憑證，以密碼學金鑰對取代密碼。根據 FIDO Alliance，Passkey 讓使用者能以解鎖裝置時相同的流程登入應用程式與網站：生物辨識、PIN 碼或圖形。Passkey 有兩種形式：

• 同步 Passkey 將憑證儲存在雲端支援的憑證管理器中，並在您的裝置之間同步。
• 裝置綁定 Passkey 將私密金鑰鎖定在單一裝置上。它絕不會離開該硬體。

在實務上，儲存模型正是驅動大多數企業權衡取捨的因素。

硬體 security key（也稱為漫遊驗證器）是一種外部硬體裝置，使用 FIDO2 CTAP（Client-to-Authenticator Protocol）透過 USB、NFC 或 Bluetooth 與瀏覽器和作業系統通訊。像是 YubiKeys、智慧卡及類似權杖。依定義，這些都是裝置綁定：私密金鑰儲存在硬體安全模組中，且無法匯出或複製。

這兩種技術共享相同的密碼學基礎。每個憑證都是唯一的、綁定至特定服務網域，並建立在標準公開金鑰密碼學之上。生物辨識資料絕不會離開您的裝置。伺服器只會儲存公開金鑰。正是這種共同設計，使這兩種選項都與相同的核心安全問題相關。

Passkey 和 Security Key 與網路安全的關聯

The 2025 Verizon DBIR 指出，憑證濫用是初始存取的重要來源：22% 的資料外洩事件 涉及將憑證濫用作為初始存取方法，根據 Verizon DBIR。這與您在實務現場所見一致：一旦攻擊者擁有有效憑證，您對抗的就是自己的存取路徑。

PasskeyPasskey 和 security key 在設計上都具備抗網路釣魚能力。正如 WebAuthn spec 所定義，每個驗證聲明都限定於特定網站網域，因此位於不同網域的憑證釣魚網站無法取得有效聲明。這可在通訊協定層級阻止憑證釣魚、憑證填充及對手中間人攻擊，這也是為何您會看到各機構與受監管產業推動 抗網路釣魚 MFA。

這就是為什麼 OMB M-22-09 現在要求聯邦機構僅使用抗網路釣魚驗證。對您的組織而言，問題不在於是否採用 FIDO2 驗證，而是哪一種實作模型符合您的風險概況。下表將關鍵差異並列比較。

Passkey 與 Security Key 概覽

每個選項背後的通訊協定堆疊、儲存模型與證明支援，會形塑您的保證等級。以下說明這些元件如何拆解。

FIDO2 驗證在底層如何運作

Passkey 和安全金鑰都依賴相同的 FIDO2 通訊協定堆疊，但它們在儲存、保護及管理底層密碼編譯材料的方式上有所不同。了解這些元件有助於您將正確的憑證類型對應到正確的風險等級。

FIDO2 通訊協定堆疊

FIDO2 由 FIDO 規範定義的兩個核心元件組成：

1. W3C Web Authentication（WebAuthn）： 可讓網站與應用程式啟用 FIDO 驗證的瀏覽器 API。
2. Client-to-Authenticator Protocol（CTAP）：允許外部驗證器與支援 FIDO2 的瀏覽器及作業系統通訊的通訊協定。

這兩層提供了來源繫結與密碼編譯證明，使強式且可抵禦網路釣魚的登入成為可能。

憑證儲存架構

儲存模型是 passkey 與安全金鑰之間的決定性差異。每種方法對私密金鑰的處理方式不同：

• 硬體安全金鑰 將私密金鑰儲存在專用的硬體安全模組（HSM）中，通常使用 Trusted Platform Module（TPM）晶片。根據 Microsoft Entra 文件，金鑰材料不可匯出。您無法複製、備份或同步它。
• 同步 passkey 使用作業系統或第三方同步架構，在裝置之間複寫密碼編譯金鑰。FIDO Alliance 的 企業部署指南 指出，這會對 passkey 提供者的同步架構及其安全控制產生依賴。

這種儲存差異會推動後續所有與證明、合規及復原相關的決策。

證明

裝置證明是內建於 FIDO 與 WebAuthn 通訊協定中的一項技術，可讓驗證器以密碼編譯方式驗證來自裝置製造商的信任鏈。根據 FIDO Alliance 的 證明白皮書，這需要在驗證器的安全元件中內嵌硬體製造商憑證。

同步 passkey 無法提供裝置來源證明，因為雲端同步會破壞這條密碼編譯信任鏈。如果您在身分識別平台中強制執行證明，則只有裝置繫結憑證符合資格。

合規對齊

NIST SP 800-63B-4 劃出明確界線。AAL2 要求可抵禦網路釣魚的驗證，而同步 passkey 與安全金鑰都可能符合資格。AAL3 要求不可匯出的驗證金鑰，這會完全排除同步 passkey。

這些元件會直接對應到登入期間發生的情況，以及兩種憑證類型在哪些方面表現不同。

註冊、驗證，以及兩者分歧之處

Passkey 與安全金鑰的驗證流程遵循相同的 FIDO2 模式。差異在於各自如何在幕後處理憑證儲存、可攜性與復原。

註冊（兩種方法）

在註冊期間，驗證器會產生一組與服務網域綁定的唯一公開金鑰/私密金鑰配對。私密金鑰會保留在驗證器上，而伺服器僅儲存公開金鑰。

驗證（兩種方法）

1. 伺服器會傳送一項加密挑戰。
2. 您執行本機驗證：指紋掃描、臉部解鎖、PIN 碼，或按下實體按鈕。
3. 驗證器會使用私密金鑰對挑戰進行簽署。
4. 伺服器會使用儲存的公開金鑰驗證簽章。

這種共通流程就是為什麼這兩種方法都能在通訊協定層級阻斷網路釣魚攻擊。

可攜性

使用實體安全金鑰時，您可攜帶一個權杖，在不限數量的裝置上進行驗證。將其插入任何相容 FIDO2 的瀏覽器，或透過 NFC 感應，您即可登入。

使用同步的 passkey 時，您的憑證會在供應商生態系內的裝置之間自動複寫：Apple、Google 或第三方管理工具。您可在筆記型電腦上進行驗證，而相同的 passkey 也能在手機上使用，無需額外攜帶任何物品。不過，跨生態系的可攜性仍不一致。在 Chrome/Windows 上可運作的流程，在 Safari/macOS 上可能表現不同，而瀏覽器層級的 UX 落差仍是企業部署中持續存在的摩擦點。

安全邊界

對於裝置綁定憑證，攻擊者需要您的憑證、對硬體權杖的實體存取權，以及繞過本機驗證的能力。

對於同步憑證，安全邊界會轉移到您的雲端供應商。如果攻擊者透過社交工程或操弄供應商重設流程而入侵雲端帳戶，他們就能將憑證同步到攻擊者控制的裝置。

這種邊界轉移正是營運規劃發揮作用之處。在企業強制推行之前，這兩種憑證類型各自都有您需要納入考量的取捨，而這些取捨只有在您所依賴的平台、瀏覽器與身分識別供應商實際支援您選擇的憑證類型時才有意義。

目前 Passkey 與安全金鑰的支援情況

截至 2025 年，passkey 與安全金鑰在消費者與企業生態系中的採用已達到實務上的臨界點。

• 作業系統與瀏覽器。 Apple（iOS 16+、macOS Ventura+）、Google（Android 9+）與 Microsoft（透過 Windows Hello 的 Windows 10/11）皆原生支援 passkey 建立與驗證。包括 Chrome、Safari、Edge 與 Firefox 在內的所有主要瀏覽器都支援 WebAuthn。根據 FIDO Alliance，目前超過 95% 的 iOS 與 Android 裝置已可使用 passkey，且已有超過十億名使用者啟用至少一個 passkey。
• 身分識別供應商。企業 IdP 已全面加入 FIDO2 支援。Microsoft Entra ID支援在 FIDO2 安全金鑰與 Microsoft Authenticator 中使用裝置綁定 passkey，並提供預覽版的同步 passkey 支援。Okta 同時支援 passkey 與 FIDO2 安全金鑰作為抗網路釣魚的驗證器，並具備憑證證明強制執行與基於 AAGUID 的原則控制。Cisco Duo、Ping Identity 與其他主要 IdP 也支援這兩種憑證類型的 FIDO2 註冊。這表示您的 IdP 不太可能成為阻礙因素。
• 硬體安全金鑰可透過 USB、NFC 或 Bluetooth 在所有相容 FIDO2 的平台上通用。Yubico 等領先製造商提供多通訊協定金鑰（YubiKey 5 Series），支援 FIDO2、PIV/Smart Card 與 OTP，可用單一權杖涵蓋現代與傳統驗證需求。
• 跨平台可攜性落差. 同步的通行金鑰在跨生態系統移轉時仍然面臨阻礙。在 Apple Keychain 中建立的通行金鑰，無法原生同步到 Google Password Manager 或 Windows 裝置。FIDO Alliance 正透過 Credential Exchange Protocol (CXP) 解決此問題；這是一項由 Apple、Google、Microsoft、1Password、Bitwarden 和 Dashlane 制定的規格草案，旨在標準化供應商之間安全且加密的通行金鑰傳輸。預計 CXP 將於 2026 年進入公開審查草案階段。在此之前，1Password 和 Bitwarden 等第三方密碼管理器可提供最一致的跨平台通行金鑰體驗。

對企業規劃而言，關鍵重點是平台支援已不再是採用障礙。剩餘的摩擦點在於同步 passkey 的跨生態系可攜性，以及組織在註冊、復原與原則強制執行方面的準備程度。這些營運挑戰值得進一步檢視。

需要規劃的挑戰與限制

沒有任何驗證方法能消除所有風險。當您大規模部署 passkey 或安全金鑰時，將會遇到一小組反覆出現的挑戰：

• 復原工作流程會成為第一線控制措施。 如果攻擊者能影響您的服務台或供應商重設流程，他們就能繞過您最強的登入流程。
• 金鑰遺失會成為可用性問題。遺失權杖可能導致使用者被鎖定在外，除非您預先準備好備援與管理員工作流程。
• 平台差異會造成摩擦。瀏覽器與作業系統的碎片化可能導致 WebAuthn UX 不一致，並增加支援負載。
• 生命週期管理負擔是真實存在的。 發放、更換與撤銷都會增加工作量，尤其是在您將權杖涵蓋範圍擴展到特權使用者以外時。

這些並非理論情境。根據 MGM Resorts 在 2023 年揭露的一起由社交工程驅動的網路事件，其負面影響估計達 1 億美元，詳見 MGM filing。強大的登入因子確實有幫助，但您仍必須強化身分識別營運，包括服務台與備援流程。好消息是，這些限制條件中的每一項都對應到特定的部署實務，您可在強制推行前先行建立。

Passkey 與安全金鑰部署最佳實務

無論您是要部署 passkey、安全金鑰，或兩者並行，這些實務都能協助您讓部署符合風險、可用性與營運現實：

1. 依風險與保證等級進行區隔. 為特權管理員、高階主管及受監管角色發放 硬體安全金鑰，適用於重視 AAL3 或高保證證明的情境。對於更廣泛的員工族群，若 AAL2 符合您的需求，請使用同步 Passkey。
2. 讓註冊與備援成為例行作業。在裝置上線期間要求設定 Passkey，並為每位使用者註冊 多個驗證器，以便您擁有備援，而不會迫使使用者退回到容易遭網路釣魚的驗證因素。
3. 強化帳戶復原與備援機制。將帳戶復原視為一項控制措施：加強服務台重設的身分驗證、限制備援方法，並監控異常的備援使用情況。
4. 分階段推行並持續監控。先在高風險群組中試行，分波擴展，然後在使用者支援與重設流程證明可行後再強制執行。持續維持對異常旅行、風險性裝置變更及可疑重新註冊的可視性。

如果您落實這四項做法，就能減少鎖定事件並縮小攻擊者的選項，同時不會拖慢使用者。接著，您可以建立清楚的區隔模型，以決定應在何處指派哪種類型的憑證。

如何在 Passkey 與 Security Key 之間做選擇

在 Passkey 與 Security Key 之間做選擇，不應是非此即彼。大多數企業最終都會採用混合模型，因為不同族群需要不同的保證等級與復原路徑。

使用以下區隔讓選擇更清楚：

• 硬體安全金鑰：當您需要 AAL3、不可匯出的金鑰，以及用於特權存取的強式裝置證明時使用。
• 同步 Passkey: 當 AAL2 已足夠，且您希望為廣泛員工存取降低 IT 管理負擔時使用。
• 混合式政策：對管理員與受監管角色使用 Security Key，對其餘使用者使用同步 Passkey。
• 以復原為優先的設計：將重設與備援路徑視為您控制集合的一部分，而非事後補救，因為它們可能會抵銷 抗網路釣魚 MFA。

一旦完成該區隔，下一步就是確保您在登入後仍能發現並阻止由身分驅動的活動。

Singularity™ Identity

Detect and respond to attacks in real-time with holistic solutions for Active Directory and Entra ID.

Get a Demo

重點整理

Passkey 與實體安全金鑰都透過 FIDO2 密碼學 提供抗網路釣魚驗證，但它們服務於不同的企業需求。同步 Passkey 優先考量使用者體驗，並可在 AAL2 下擴展至一般員工。 

裝置綁定的安全金鑰可為特權使用者與受監管環境提供不可匯出的憑證、硬體支援的證明能力，以及與 AAL3 的一致性。對大多數企業而言，您會在風險導向模型中同時部署兩者，然後在其上疊加身分威脅可視性，以捕捉僅靠驗證控制無法發現的問題。