小型客戶網站應否提供通行密鑰，又應如何開始？

先判斷服務是否適合

通行密鑰可減少對記憶密碼及容易受釣魚攻擊的登入步驟的依賴，但小企應先看顧客旅程，而非先喊技術口號。登入後，顧客是查訂單、改送貨地址、下載敏感文件，還是批准付款？他們多久登入一次，使用甚麼設備？若網站目前使用密碼加一次性驗證碼，可考慮讓已完成較強驗證的顧客自選登記通行密鑰。FIDO 指引說明，這類憑證與服務綁定，私鑰由用戶裝置或通行密鑰提供者保管，服務端保存公鑰。但網站仍需要安全的登入時段、帳戶資料變更控制，以及照顧暫時無法使用通行密鑰的顧客。

對顧客的承諾應準確而有限：在相容裝置上多一種較方便的登入方式，由作業系統或提供者協助批准使用。不要保證所有通行密鑰都有備份、每部裝置都有生物識別器，亦不要把一次生物識別提示等同法定身份核實。裝置 PIN 碼或密碼也可能用於本機使用者驗證。網站要決定所需驗證程度，並由伺服器核對實際結果。中英文介面都要用容易理解的語句，說明共用裝置上任何能解鎖裝置的人，或可能使用儲存在該裝置的通行密鑰；顧客亦應可拒絕或稍後再登記。

較穩妥的第一步，是讓現有帳戶自願參與小規模測試，而非一夜間強制所有人轉換。測試者要包括經常及偶爾登入的人、不同手機系統使用者、桌面電腦使用者，以及家庭共用電腦的顧客。FIDO 建議分組試行並觀察使用情況，再考慮擴大。公司可自行記錄登記是否完成、登入是否成功、改用其他方法的情況及客服查詢；本文沒有任何假設的成功率，也不聲稱已取得業務測量結果。試行的目的是及早找出難懂提示、不相容組合與支援需求。

把登記視為帳戶權限變更

新增通行密鑰，等於為現有帳戶增加另一條登入途徑。邀請顧客之前應要求近期且足夠強的身份驗證，不能只憑一個長時間未使用的瀏覽器分頁批准。顯示將要更新哪個帳戶，讓顧客確認，再由伺服器把回傳的憑證識別碼與公鑰綁定到該帳戶。passkeys.dev 的啟用指引把自選登記放在較強驗證之後，亦會先檢查裝置支援情況。不同系統的瀏覽器提示各異，網站應解釋目的，而非假裝所有裝置都會出現同一畫面。顧客取消時，原有登入方法應繼續可用，結果訊息也必須如實。

伺服器核實才是保安邊界。WebAuthn 規範要求服務方檢查客戶端資料中的來源網域，並拒絕意料之外的值。實作亦須使用新的挑戰值，把回應連繫至指定操作及帳戶，並按政策驗證憑證及使用者驗證結果。這些檢查應由維護中的認證程式和安全審查處理，不能靠宣傳頁的 JavaScript 或一張「登入成功」截圖。若小企採購身份服務，應要求對方說明相關控制及支援的網域設定。網站縱有中英文前端，帳戶識別及允許的來源仍須一致；翻譯文字不能彌補服務方網域設定錯誤。

登記後，顧客應有容易理解的頁面查看及移除帳戶所關聯的通行密鑰。裝置或提供者名稱有助識別，但名稱不一定能證明同步憑證目前存在哪一部實體裝置。刪除最後一種登入方法等敏感操作，應按風險要求重新驗證，先清楚說明後果。新增或移除通行密鑰時，可透過可靠的帳戶通知途徑提醒顧客，但不要在通知中暴露秘密資料。客服應有處理爭議變更的書面程序，也不應只因來電者知道顧客電郵地址便能代為新增憑證。

測試登入與後備途徑

要測試平常回訪、新瀏覽器、另一部手機，以及手提電腦借用手機通行密鑰登入等情況。有些提供者會跨裝置同步憑證，有些憑證只留在單一裝置，也可能使用跨裝置認證；這些是不同路徑。說明文字應對應顧客真正看得到的選項，不能假設所有憑證都會在所有裝置出現。passkeys.dev 討論跨裝置使用，以及合適時再邀請用戶在本機建立憑證。若顧客關閉系統提示，而帳戶仍有其他登入方法，介面應讓人找到它；後備方法也要可用鍵盤及輔助科技操作。

通行密鑰的可用性與帳戶恢復相關，但並非同一件事。同步型通行密鑰或可經提供者在換機後恢復；只儲於單一裝置的憑證，可能需要備用驗證器或另一條恢復途徑。FIDO 提醒，薄弱的恢復流程會削弱較強的登入保護，建議按風險設計。公司應先決定由誰核實顧客、帳戶敏感程度需要甚麼證據，以及如何確保被取代或有爭議的憑證不再可用。這些政策在強制改用通行密鑰之前便應定好。本文聚焦推出決定；完整的遺失帳戶處理流程需要另外設計及測試。

例如小型預約服務的顧客可能數月才登入一次。網站只在原有方法成功登入後邀請自願建立通行密鑰，清楚顯示所屬預約帳戶，亦容許稍後處理。測試顧客在私人手機登記，之後在工作用手提電腦借手機登入；若提示失敗，仍可選原有方法。服務端核實來源網域及挑戰值，記錄登記與登入結果，並演練手機遺失時的處理。這是設計情景，並非實測成效，也不保證各提供者表現完全相同。業主應根據試行觀察、客服準備及已審視的恢復途徑，才決定是否擴大。

客服需要處理日常失敗的決策流程，不只防備攻擊。例如顧客開始登記後關閉系統視窗，卻以為通行密鑰已建立。帳戶頁只應列出伺服器確認的憑證，完成訊息亦應清楚說明成功與否。另有顧客在一個提供者儲存密鑰，換機後卻選了另一提供者；客服應先引導查看可用登入選項，不宜立刻重設帳戶。員工不應索取裝置 PIN 碼、生物識別資料或秘密恢復材料。需要升級處理時，應根據帳戶風險及有文件記錄的證據，清楚記下誰批准憑證變更，避免客服電話成為接管帳戶的途徑。

推出前應從顧客角度寫驗收情景：不建立通行密鑰能否繼續登入？完成較強驗證後能否新增，中途取消再重試？換裝置、刪舊憑證後又能否繼續進入帳戶？使用鍵盤及讀屏器的顧客能否明白中英文提示？這些使用者檢查應配合伺服器對來源、挑戰值及政策核實的審查。試行時記下裝置及瀏覽器版本，因平台行為會隨時間改變。一位員工在一部手機上成功看到提示，只能證明那個個案可行，不能證明全部顧客可以轉換。使用流程及支援途徑都準備好，才考慮擴大；若發現問題，也應可暫停新登記邀請。