FIDO 聯盟統計，全球目前已有 50 億組 passkey 正在被使用，消費者對這個名詞的認知度也從去年的 75% 一口氣衝上 90%。但多數網站的會員登入頁，可能還停在帳號密碼配一組簡訊驗證碼的組合，覺得這樣的兩階段驗證已經算是有把關。Passkey 登入不是密碼的加強版，而是用一組公私鑰（key pair）取代「輸入一串秘密字元」這件事本身，註冊時裝置產生一把只留在本機的私鑰，登入時靠它對一次性挑戰做簽章，伺服器只需要驗證簽章對不對，完全不經手任何可以被偷走、被猜中的秘密。這個差異看起來只是技術細節，對防釣魚的效果卻是本質上的不同，不是「多一道關卡」那種程度差異。少了這一步，你導入的多半只是看起來比較安全，實際上還是擋不住針對性攻擊。
Passkey 登入是什麼？公私鑰取代密碼的驗證方式
passkey 建立在兩個標準之上，W3C 制定的 WebAuthn 是瀏覽器端的驗證流程規範，FIDO2 則是背後的憑證交換協定，兩者合起來讓瀏覽器、作業系統與網站三方，不需要交換任何密碼就能完成身分驗證。FIDO 聯盟與 W3C 官方的定義很直接，passkey 是一種可以取代密碼、用來向網站或應用程式證明身分的數位憑證，由作業系統或瀏覽器統一管理，可以透過雲端在你自己的多台裝置之間同步，也可以只存放在單一實體安全金鑰這類硬體裝置裡，兩種存放方式都合法，只是適用情境不同。
這套標準並不是新東西，但直到 2026 年 8 月才真正定案。W3C 在當月把 WebAuthn Level 3 列為正式的 Recommendation，把 passkey 需要的幾項關鍵技術特性（像是同一組 passkey 能跨越多個相關網域使用、能在使用者填密碼的過程中順便完成註冊、能讓裝置端與伺服器端的憑證清單保持同步）第一次收斂進同一份標準規格，不再是各家瀏覽器各自實作的草案功能。資安圈普遍把這一版視為 passkey 技術規格的正式底定版，對網站經營者而言，這代表現在導入不是在賭一個還沒定型的技術，而是站在一套已經拍板的基礎建設上。
註冊與登入兩階段的公私鑰簽章流程
整套機制拆開來看，分成註冊與登入兩個階段，運作邏輯都圍繞著同一把私鑰打轉。註冊階段，使用者的裝置（FIDO 的用語稱為驗證器）會替這個網站現場產生一組全新的公私鑰對，私鑰留在驗證器內部，設計上就不會、也無法被讀出或傳輸到任何地方；公鑰則連同這台裝置的憑證資訊一起送到網站（也就是所謂的依賴方，relying party），網站把這把公鑰跟這個使用者的帳號綁在一起存起來。這個步驟只做一次，之後每次登入都重複使用同一組公私鑰，不會每次都重新產生。
登入階段換成網站主動出招，網站先送出一個一次性的挑戰值（challenge），使用者用指紋、臉部辨識或裝置 PIN 解鎖驗證器後，驗證器拿註冊時留下的那把私鑰，對這個挑戰值做數位簽名，產生一份簽章結果（WebAuthn 規格裡稱為 Assertion），再把簽章送回網站。網站這時只做一件事，用先前存好的公鑰，驗證這份簽章是不是真的由對應的私鑰產生。驗證相符才放行登入，而且每一次登入用的挑戰值都不一樣，就算某次的簽章被攔截下來，也沒辦法拿去下一次登入重放使用。
私鑰不出裝置，是防釣魚的關鍵設計
passkey 常被說成「防釣魚」，這不是行銷詞彙，而是上面那套簽章流程，從結構上就讓釣魚攻擊沒有著力點。私鑰從產生到使用，全程只留在裝置內部，不曾經過網路傳輸，也不會被使用者手動輸入或複製貼上，沒有一個「秘密字串」可以被騙走。就算網站的資料庫真的外洩，攻擊者拿到的頂多是一批公鑰，而公鑰原本就設計成可以公開，對攻擊者毫無用處，這跟密碼外洩後可以直接拿去登入完全是兩回事。
更關鍵的是，美國網路安全暨基礎設施安全局（CISA）官方文件對「防釣魚」身分驗證的認定，直接點出這套加密簽章流程會綁定依賴方的來源網域。換句話說，使用者的裝置在簽章之前，會先確認自己正在跟哪一個網域對話，如果攻擊者架了一個長得很像的假網站，誘騙使用者操作，裝置產生的簽章綁的是假網站那個網域，拿去真正的網站驗證，兩邊對不上就直接被拒絕。密碼與大多數簡訊驗證碼沒有這層網域綁定，使用者自己都分辨不出網址是不是被掉包了，才會全程被蒙在鼓裡，毫無防備。
W3C 標準底定，2026 是 Passkey 普及轉捩點
passkey 這個名詞不是這一兩年才出現，真正把它從「早期採用者的玩具」推向「網站應該認真評估導入」的關鍵，是兩件事同時在 2026 年成立，技術規格終於定案，使用端的普及數字也在同一年跨過門檻。FIDO 聯盟《State of Passkeys 2026》這份調查（由 Sapio Research 於 2026 年 4 月執行，橫跨美國、英國、法國、德國、澳洲、新加坡、日本、韓國、中國與印度 10 個市場，訪問 11,000 名消費者與 1,400 名企業決策者）給出的數字相當具體：全球已經有 50 億組 passkey 在使用中，消費者對這個名詞的認知度從前一年的 75% 拉高到 90%，已經有 75% 的消費者至少在一個帳戶上啟用過 passkey，49% 的人只要平台支援就會優先用它登入。
企業端的動作也在加速。同一份調查裡，68% 的組織回報自己已經部署、試行，或正在推動員工登入 passkey 化；82% 的企業把「完全無密碼」列為終極目標，其中 28% 表示已經達成。FIDO 聯盟的 Passkey Pledge（一份公開承諾採用 passkey 的組織清單）也已經累積超過 200 個組織簽署。這些數字放在一起看，傳達的訊息很一致，passkey 已經不是少數科技公司的實驗性功能，而是逐漸變成企業身分驗證的預設選項。
會走到這一步，跟密碼本身造成的實際損失脫不了關係。同一份調查顯示，過去一年有 33% 的消費者遇過帳戶被盜用，或收到帳戶資料外洩的通知；47% 的消費者會因為忘記密碼而放棄一次購買或登入，其中 17% 表示自己「非常可能」直接放棄。對任何一個靠會員或電商轉換率過日子的網站來說，這代表密碼登入本身，就是一道會流失顧客的關卡，不只是資安問題，也是轉換率問題。
Passkey 取代了密碼和兩階段驗證的第一道防線
很多網站經營者已經在密碼之外加了一層兩階段驗證，覺得這樣應該夠安全，但 passkey 要換掉的不是「密碼」這一個環節，而是整個「防不防得了釣魚」的判斷基準。差別不是多一道關卡跟多兩道關卡的程度落差，而是這件事做不做得到的本質落差。CISA 官方對「防釣魚」怎麼認定，決定了這件事有沒有真的做到位；維運成本省在哪裡，則是實際導入後才看得出來的效益。
CISA 對「防釣魚」的認定，排除簡訊與推播驗證
CISA 官方文件把「防釣魚」訂出一個明確、可查核的門檻，而不是一句「更安全」的模糊形容。文件裡列出唯一符合這個門檻的方法，只有 FIDO2/WebAuthn（也就是 passkey 與硬體安全金鑰）以及美國政府機關常用的 PIV/CAC 智慧卡。除此之外，像是簡訊一次性驗證碼、語音來電驗證碼、email 一次性登入連結，以及使用者只需要在手機上按「核准」或「拒絕」的推播通知，這幾種目前最常見的兩階段驗證形式，全部被明確排除在「防釣魚」等級之外。
排除的理由很具體，這些驗證資訊仍然可能被中間人攻擊或釣魚頁面攔截後冒用。使用者在假網站上輸入的簡訊驗證碼，攻擊者可以在幾秒鐘內原封不動轉貼到真網站完成登入；推播通知也一樣，使用者只要被疲勞轟炸下按了一次「核准」，攻擊者就直接進去了。這也是為什麼 CISA 建議，真的沒辦法馬上導入防釣魚等級驗證的組織，至少該替推播通知加上「號碼比對」這種折衷做法，但折衷終究不是防釣魚，只是降低被騙的機率而已。
導入後的客服工單和轉換率變化
實際導入之後，效益不是抽象的安全感，而是反映在具體的營運數字上。FIDO 聯盟的調查裡，已經導入 passkey 的組織回報：47% 認為安全信心明顯提升、45% 回報員工的登入速度變快、43% 回報員工對 IT 部門的滿意度提升、35% 回報密碼重設相關的客服工單減少、32% 回報釣魚相關事件減少。對負責維運會員系統的團隊來說，密碼重設工單本來就是最消耗人力的日常瑣事之一，能減少三分之一以上，等於直接省下一筆可以量化的人力成本。
轉換率的變化同樣可觀。Google for Developers 官方記錄了密碼管理商 Dashlane 的實測數據（Dashlane 在 180 個國家有超過 1800 萬名使用者與 2 萬家企業客戶），在支援 passkey 的網站上，passkey 登入流程的轉換率達到 92%，相較密碼自動登入的 54%，足足高出 70%；passkey 註冊提示的採用率是 63%，遠高於傳統密碼儲存提示的 25% 左右；passkey 每週的使用與儲存量，平均還在以 6.8% 的速度持續成長。這些數字合起來說明一件事，passkey 不只是防禦性的資安投資，對登入這個轉換漏斗來說，它本身就是一個提升轉換率的改動。
伺服器門檻、裝置支援落差，會員系統導入前最容易漏看的兩塊
passkey 不是裝一個外掛就能立刻運作，WebAuthn 本身對執行環境有幾個硬性要求，主機規格、瀏覽器與使用者手上的裝置版本都要達標，才不會出現「後台裝完看不到按鈕」或「使用者卡在註冊畫面」這種狀況。伺服器端的最低門檻與使用者手上裝置的支援落差，是導入前最容易漏看的兩塊。
HTTPS、WordPress、PHP 版本的最低門檻
最基本的硬性條件是 HTTPS，WebAuthn 這套規格只能在安全連線環境下運作，這不是外掛設定，而是瀏覽器本身的限制。如果網站還沒全站上 HTTPS，passkey 相關的外掛通常會在後台顯示警告，但對 localhost、127.0.0.1 這類本機開發網址會放行，方便你在正式上線前先在本機測試。
不同外掛對主機規格的要求也不一樣，選外掛前得先對照自己主機的實際規格。以 WooCommerce 官方的「Biometric Passkey Login」外掛為例，最低需求是 WordPress 6.4 以上、PHP 8.2 以上；如果要串接 WooCommerce 本身的會員與結帳流程，WooCommerce 版本還得在 9.4 以上，但不裝 WooCommerce，這支外掛仍然可以獨立運作在 WordPress 的登入頁與個人資料頁。另一支「Secure Passkeys」外掛（WordPress.org 官方外掛目錄的免費外掛）門檻明顯寬鬆許多，只要 WordPress 6.0 以上、PHP 7.4 以上就能裝。這代表主機規格比較舊、還沒升級到 PHP 8 的網站，可能只有部分外掛能安裝，導入前務必先確認清楚，免得選了外掛才發現主機根本裝不上去。
主流瀏覽器與裝置目前的支援程度
passkeys.dev（FIDO 聯盟與 W3C 生態圈共同維護的開發者參考站）整理的裝置支援矩陣顯示，同步型 passkey（也就是能透過雲端帳號在多台裝置間同步使用的那種）在 Android 9 以上、iOS 與 iPadOS 16 以上、macOS 13 以上都已經支援；Windows 這端官方原生目前還沒有預設支援，要到 Windows 25H2 之後才開始支援第三方的驗證管理器來補上這塊。這代表如果你的會員以 Windows 桌機使用者為主，規劃介面時就該提醒他們優先用手機或實體安全金鑰當作登入與備援的裝置，別預期桌機瀏覽器一開就能直接同步使用。
瀏覽器端的自動填入（autofill，也稱為 conditional UI）支援度相對成熟許多，使用者只要點一下帳號欄位，瀏覽器就會自動跳出已經註冊的 passkey 選項，不需要另外按一個額外的登入按鈕。這項功能在 Chrome 108 以上、Edge 122 以上、Firefox 122 以上、Safari 16.1 以上都已經支援。合起來看，2026 年主流瀏覽器已經全面支援 passkey 登入與自動填入這件事本身，真正的落差只剩下「跨裝置同步」在 Windows 端還沒補齊，這一點在規劃使用者流程時特別要記得。
WooCommerce 會員登入的 passkey 串接做法
如果你的網站本身就是 WooCommerce 會員制或電商，官方認證的「Biometric Passkey Login」外掛會直接把 passkey 登入按鈕放進 WordPress 登入頁的密碼欄位下方、記住我勾選框上方，以及 WooCommerce 我的帳戶登入表單、傳統結帳與區塊結帳的登入提示裡，不需要額外接第三方 SDK。公鑰、憑證識別碼與簽章計數器只存放在網站自己的三張資料表裡，私鑰全程留在使用者裝置內，公鑰本身就算外洩對攻擊者也沒有用處。真正需要判斷的不是要不要裝，而是裝完之後幾個關鍵設定該怎麼調。
角色的允許註冊和強制啟用分開設定
這支外掛的角色權限拆成兩個獨立的開關，而不是一個籠統的「開啟或關閉」。第一個開關是「允許註冊」，邏輯有個容易被誤解的地方，如果完全沒有勾選任何角色，系統預設當成「全部角色都允許」；但只要勾選了第一個角色，整份清單就會立刻變成白名單，沒被勾到的角色反而會被完全排除在外，連註冊按鈕都看不到，個人資料頁的 passkey 設定區塊也會一併隱藏。這個「一勾就變白名單」的行為，是設定時最容易踩到的地雷，調整前最好先想清楚要保留哪些角色，而不是先勾一個試試看。
第二個開關「強制使用」則是決定這個角色能不能繼續用密碼登入。一旦某個角色被設成強制，只要這個角色底下的使用者已經註冊過至少一組 passkey，就沒辦法再用密碼登入；如果他還沒註冊，系統仍然會放行密碼登入，但登入後會被導向 passkey 設定頁面，其他頁面一律被導回這個設定頁，直到他完成註冊為止。實務上比較穩妥的做法，是先鎖定一個角色做小範圍測試，確認整個註冊與登入流程順暢之後，再逐步擴大到其他角色，而不是一次對全站角色打開強制開關。
使用者驗證和裝置限制的安全性選項
有三個安全性設定，預設值背後其實都有取捨考量，值得展開看。User Verification 決定每次登入要不要做生物辨識驗證，預設值 Preferred 的意思是「裝置支援就做，不支援就略過」；如果調成 Required，等於每次登入都強制要求生物辨識或 PIN，安全性更高但也更嚴格；調成 Discouraged 則相反，只要使用者持有這把 passkey 就視為驗證通過，不再要求額外的生物辨識。Verification Timeout 決定裝置回應的等待秒數，預設是 60 秒，可調整範圍是 15 到 300 秒，如果使用者習慣用實體安全金鑰、常常需要翻找攜帶，適度拉長這個等待時間會比較友善。
Attestation Type 決定要不要驗證裝置型號，預設是 None，代表不要求裝置提供型號證明；Direct 與 Indirect 這兩個選項，是給需要限制「只准特定型號的硬體裝置登入」的企業用的，一般的會員網站用 None 就足夠，要求裝置證明只會讓使用者在註冊時多看到一個額外的瀏覽器同意提示，不會讓一般商店因此更安全。另外還有一個每人可註冊的 passkey 上限，預設是 5 組，可調範圍 1 到 20，一支手機、一台筆電，加一把實體安全金鑰的組合是常見配置，就算把上限調低，也不會影響使用者已經註冊好的 passkey。
非 WooCommerce 會員外掛的 passkey 導入路徑
MemberPress、Easy Digital Downloads、Ultimate Member 這類會員或數位商品外掛的網站，或者單純只是想替 WordPress 後台加上 passkey，「Secure Passkeys」這類第三方外掛走的是另一條路，直接整合通用的 WordPress 登入表單，而不是綁定在 WooCommerce 底下。
第三方外掛對熱門會員系統的整合範圍
「Secure Passkeys」是 WordPress.org 官方外掛目錄裡的免費外掛，整合範圍涵蓋 WordPress 預設登入表單、WooCommerce 登入頁、MemberPress 登入表單、Easy Digital Downloads 登入表單，以及 Ultimate Member 登入表單。換句話說，如果網站用的是這幾套會員系統其中一種，理論上都能透過這支外掛加上 passkey 登入，不需要另外找對應的專屬外掛。
這支外掛還支援用 shortcode 把 passkey 登入或註冊按鈕直接嵌進自訂的前台頁面，也支援多站環境、passkey 自動填入（使用者點進帳號欄位就自動跳出建議，不用多按一次按鈕）、角色排除清單、每人的註冊數量上限，以及登入速率限制。最低需求也比 WooCommerce 官方外掛寬鬆許多，只要 WordPress 6.0 以上、PHP 7.4 以上就能裝，對主機規格比較舊、還在用 PHP 7 的網站來說，是相對容易導入的選項。
外掛衝突與版本更新要留意的細節
passkey 外掛不是裝上去就一定順利運作，尤其網站原本就裝了兩階段驗證或其他安全性外掛的情況下，更需要先測過再上線。「Secure Passkeys」的官方更新紀錄裡，2026 年 1 月 30 日發布的 1.2.4 版，特別修正了「部分兩階段驗證外掛會擋住 passkey 登入」這個相容性問題。換句話說，在這個版本之前，確實有使用者裝了這支外掛之後，反而因為既有的兩階段驗證外掛彼此衝突，導致沒辦法順利登入。
2026 年 7 月 1 日發布的 1.3.0 版，則是因為第三方資安稽核新增了多項安全修正，同時補上瀏覽器自動填入的支援。這代表 passkey 外掛跟網站既有的安全性外掛堆疊時，相容性問題是真實存在、而且會隨版本反覆調整的，導入前務必先在測試環境完整跑過一次註冊與登入流程，確認不會把使用者卡在登入畫面外，而不是預設「裝上去就會生效」。
管理員帳號的 passkey 規則應比會員更嚴格
很多網站導入 passkey 時，第一個念頭是先讓一般會員用，但真正該優先鎖定的順序反過來，後台管理員與擁有結帳、退款權限的員工帳號，才是該第一批啟用的對象，因為這些帳號一旦被釣魚得手，損失遠遠大於單一會員帳號被盜。
管理員帳號應該列為優先啟用對象
FIDO 聯盟的調查也印證了這個順序，即使是已經部署 passkey 的組織，仍有 57% 回報員工日常登入主要依賴密碼類方式，顯示大多數組織還沒有把 passkey 鋪到全體員工，而是先從高風險、高權限的帳號起步，再逐步往外擴大。這個做法背後的邏輯很直接，管理員帳號通常只有一到兩位，啟用門檻低、影響範圍小，很適合當作第一批測試與示範對象，確認整套流程順暢之後，再推廣到人數更多的一般會員。
CISA 的建議邏輯也是同一套，優先替換高權限帳號的驗證方式，因為這類帳號一旦被攻陷，代價遠高於一般帳號。對一個電商網站來說，一個被釣魚得手的管理員帳號，可能直接牽涉到商品下架、金流設定被竄改，甚至整個網站被植入惡意程式碼，跟一個會員帳號被盜用的損失完全不在同一個等級，這也是為什麼順序要反過來排。
管理員帳號優先選擇裝置綁定型 passkey
passkey 依存放方式，大致分成同步型與裝置綁定型兩種。同步型 passkey 靠雲端帳號（像 iCloud 鑰匙圈或 Google 密碼管理員）在多台裝置之間同步，好處是方便，換一台手機也不用重新註冊，但代價是多了一個雲端帳號本身被攻陷的風險面，如果攻擊者拿下你的雲端帳號，連帶也就拿到了裡面同步的 passkey。裝置綁定型 passkey 則只存放在單一實體裝置裡，像是一把硬體安全金鑰，遺失就是遺失，不會被雲端帳號牽連在一起。
對權限高、能接受多帶一把實體安全金鑰的管理員來說，裝置綁定型是比較穩妥的選擇。CISA 的文件也指出，FIDO 安全金鑰、平台驗證器與裝置綁定型 passkey 都符合防釣魚的門檻，但同步型 passkey 背後依賴的是雲端復原機制，建議高權限帳號避免只依賴同步型 passkey；如果組織要求符合 NIST 身分驗證保證等級三（AAL3），更是必須使用具備硬體認證能力的裝置綁定型驗證器，同步型在這個等級底下並不合格。
使用者弄丟裝置後，帳號救援機制的設計原則
passkey 上線之後，最大的實務痛點往往不是安全性夠不夠，而是「救援」這件事有沒有先設計好。使用者換手機、裝置遺失或損壞，如果復原流程沒有事先想清楚，passkey 反而會變成把使用者鎖在自己帳號外面的工具，這種狀況一旦發生，客服壓力會比密碼時代大得多。
一次性復原碼的產生和失效規則
以 WooCommerce 的「Biometric Passkey Login」外掛為例，復原碼的數量預設是 8 組，可調範圍 4 到 16 組，格式是 XXXX-XXXX，而且刻意排除容易混淆的英文字母 O 與數字 0。這批碼會在使用者第一次註冊 passkey 時自動產生，以彈跳視窗顯示一次，這個視窗設計成不能按 Esc 鍵、也不能點外部區域關閉，就是要逼使用者當下把碼存好，因為之後網站只會保留這批碼的雜湊值，連管理員都沒辦法再把原始的復原碼讀回來。
每一組復原碼用過一次就會失效，如果使用者選擇重新產生一批新碼，舊的那一整批不管用過沒用過，會全部一起作廢。管理員也可以在使用者的個人資料頁按下清除，但清除之後不會自動補上新的一批，使用者得自己重新產生。這套設計背後的用意很清楚，復原碼是最後一道救援手段，一旦流出去就等於帳號的另一把鑰匙，失效機制要做得比一般忘記密碼的流程更謹慎。
忘記密碼和弄丟裝置，兩種情境分開處理
對客服團隊來說，最實用的其實是一套能直接照做的判斷邏輯，使用者手上還有沒有復原碼，決定了整個處理流程的走向。如果使用者還持有復原碼，他自己就能用「使用復原碼」這個連結登入，刪除遺失裝置上的那組 passkey，再註冊一台新裝置，整個過程不需要管理員介入。
如果復原碼已經用完，或者使用者一開始就沒有妥善保存，管理員才需要出手，直接從這位使用者的個人資料頁按下清除復原碼，讓他改用密碼這類備援方式先登入，登入後再自己重新產生一組新的復原碼。這套流程也搭配了速率限制，同一個帳號連續 10 次登入失敗，會觸發 15 分鐘的冷卻期，而且不管這個帳號是真的存在還是根本不存在，失敗次數的計算方式都一視同仁，避免有心人拿登入嘗試的反應速度去試探哪些帳號真的存在。
上線後的採用率追蹤與強制轉換時機
passkey 導入完成、外掛裝好之後，不代表這件事就結束了。真正決定「什麼時候可以要求全員都改用 passkey、關掉密碼登入」的，是上線後持續追蹤的幾個數字，而不是憑感覺覺得推得差不多了。以 WooCommerce 外掛的 Analytics 分頁為例，「採用率」的定義是「已經註冊至少一組 passkey 的使用者」占全體 WordPress 使用者的比例，而且只計算現存的帳號，如果有使用者把帳號刪掉了，比例會跟著重新計算，不會讓數字虛增，造成「採用率看起來很高，其實只是分母算錯」的假象。同一個分頁也會顯示最近 30 天內的登入次數、總註冊數、總刪除數，以及復原碼的使用總數，這些數字合起來能讓你看出使用者是不是真的把 passkey 用起來，而不只是註冊完就晾在一邊。
實務上比較穩妥的做法，是先對特定角色打開「強制使用」，但同時保留密碼登入當作備援，持續觀察這個角色的採用率，直到比例真的爬到 100%，才代表這批人全部完成註冊。這時候才是關掉密碼登入（也就是 Passkey-Only Mode）的安全時機。這個模式一旦啟用，是整站生效的開關，啟用前必須確認每一個需要存取後台的帳號都已經有 passkey，包含操作這個開關的管理員自己，如果連自己都還沒註冊好就把密碼登入關掉，等於自己把自己鎖在後台外面。
passkey 會不會普及，不是網站經營者能決定的事，但會員系統什麼時候導入、導入後先給誰用、裝置遺失了怎麼救援，這幾個決定確實是每個網站自己能選的。50 億組 passkey 已經在全球被使用，技術規格也在 2026 年正式定案，真正拉開差距的，往往不是要不要裝外掛，而是像角色權限、救援機制這些容易被跳過的細節，有沒有事先想清楚。把 passkey 登入這件事一次做對，省下的不只是外洩風險，還有客服工單與登入轉換率這些看得到的成本。