從 Passkey 到可營運的防仿冒驗證

從登入頁面移向帳戶生命週期

傳統認證設計往往圍繞一個問題：「這次登入是否成功？」但仿冒詐騙的風險，通常不會在登入成功的一刻結束。攻擊者可能先取得帳戶，再註冊新裝置、建立新的持續 session、修改聯絡資料，最後發出不符合客戶慣常模式的交易。

因此，成熟的控制框架必須同時處理四個階段：在登入及裝置註冊時預防仿冒；透過登入、裝置及交易訊號偵測異常；在發現可疑活動後即時限制、暫停、撤銷及通知；並持續教育客戶識別仿冒短訊、假網站及社交工程手法。

Passkey 為何能降低仿冒風險？

SMS OTP 的根本限制，是它仍然是一段可被輸入、截取及即時轉送的秘密。當客戶被假網站誘導輸入登入資料和一次性密碼，騙徒便可能把資料即時轉送到真實平台，形成中間人攻擊。證監會明確指出，一次性密碼並非可防止仿冒詐騙的認證解決方案，因此不應將其用於客戶登入及裝置綁定等關鍵程序。

Passkey 則以公鑰加密技術為基礎。建立通行密鑰時，私鑰保留在客戶裝置或通行密鑰管理工具，服務提供者保存公鑰；登入時，認證器對一次性 challenge 產生簽署回應，伺服器以公鑰核實。由於通行密鑰的設計會綁定至其建立及註冊時對應的合法網站或應用程式，仿冒網站較難取得可在真實平台使用的有效回應。

對客戶而言，這可能只是一次指紋、面容或 PIN 解鎖；對平台而言，卻是由「輸入可轉送秘密」轉為「使用本地私鑰回應來源綁定挑戰」。這是 Passkey 的核心安全價值，也是證監會附錄把通行密鑰列為可接受方法例子的原因。

附錄帶來的關鍵訊息：裝置綁定不只有一條路

證監會附錄並沒有把某一個產品或某一種技術指定為唯一答案，而是列出可接受的穩健核實方法例子。這為券商提供了彈性，也同時提高了設計責任：機構必須按平台、客戶、風險及營運能力，選擇適當的方法並證明其有效性。

附錄所列的裝置綁定方法，可以整理為以下四類：

附錄亦說明，在實施期後，沒有綁定裝置的現有客戶可以透過穩健核實方法重新綁定裝置；對遺失、遭盜用、被替換或無法接達的裝置，服務提供者應制定撤銷及復原政策，並向客戶提供清晰指引。

同步通行密鑰，不等於可管理的裝置數量

只看 Passkey，仍然不足以處理持續存取權。同步通行密鑰可能在多個 client 上可用，而伺服器未必能看見 Apple 或 Google 管理的所有實體裝置。於是，登入成功不應直接等同於新 client 已獲得既有 endpoint 的授權。

更穩健的做法，是在伺服器建立 managed endpoint 層。每個 endpoint 都應有獨立的 binding public key、active 或 revoked 狀態、session version，以及可供稽核的事件時間線。這讓券商能夠枚舉、限制、撤銷及追蹤持續存取權，而不是只知道某個 Passkey 曾經驗證成功。

證監會的表述則是一般而言不應容許客戶綁定或註冊超過三個通行密鑰及／或三部裝置；若有超額要求，應先作充足評估。業界應避免把方案建議誤寫成絕對硬性規則，但也不應讓第四個 client 在沒有額外核實和審批的情況下自動取得授權。

New endpoint activation：四道閘門，而不是一個按鈕

新裝置註冊應被視為一次高風險授權，而不是一般登入的延伸。可採用以下四道後端閘門：

只有在所有條件成功後，endpoint 才能轉為 active，系統才可寫入 binding public key 並簽發 endpoint-bound session。若結果是 pending、failure 或 timeout，則應重查、轉人工覆核或按政策拒絕，不能以 SDK 或 H5 前端顯示完成作為最終授權依據。

Rule-based controls：把監管要求變成可測試的決策

當券商採用 OneSpan Digipass S3 或其他政策驅動的認證平台時，真正需要交付的不是一張「支援 Passkey」的功能表，而是可測試、可重播及可稽核的控制矩陣。OneSpan 公開資料顯示，Digipass S3 支援 Passkey／FIDO、政策驅動的註冊和認證、裝置及風險訊號、復原與稽核紀錄等能力。

在實務上，Authenticator Policy 可決定允許哪些 FIDO 或 Passkey 認證器；Registration Policy 可決定何時允許 new endpoint 註冊，及是否需要 existing Passkey、eIDV 或人工覆核；Authentication Policy 可決定哪些登入流程必須使用 Passkey，以及 OTP 在過渡期間何時不可再作為成功條件；Policy Set 則將多層政策綁定至指定的 web、mobile 或 desktop application。

每條 rule 都應配備正向及負向測試：

每次規則變更都應經過 Define、Approve、Test、Monitor 及 Tune／Rollback。證據包應包括 application／policy map、rule inventory、版本歷史、變更批准、正負向測試、命中規則事件、通知送達、案件處置及管理層定期覆核。這些證據才足以讓控制被重播、驗證及持續調校。

真正的合規，是可觀察、可介入及可復原

證監會要求對成功登入、新裝置登入、新裝置綁定，以及通行密鑰創建或撤銷等高風險活動及時通知客戶，並監察可疑登入及異常交易；在需要時，機構應直接向客戶核實、限制或暫停帳戶。

因此，認證服務、交易平台及營運團隊必須形成閉環。可被捕捉及覆核的訊號，包括不尋常地理位置、短時間內從多個地點登入、同一裝置綁定多個帳戶、新 endpoint 綁定後迅速交易、偏離客戶慣常模式的交易，以及異常過長的 session。這些訊號不應只停留在 dashboard，而要能觸發明確行動：Allow、step-up、restrict、suspend 或 manual review。

同樣地，trusted endpoint 管理與 all-endpoints-lost recovery 必須分流。若客戶仍可使用一個安全 endpoint，可要求 fresh authentication 後撤銷其他 endpoint，令被撤銷 endpoint 的 session 即時失效並通知客戶。若客戶遺失全部 endpoint，則應進入高保證復原程序，例如 eIDV、客服人工覆核、撤銷舊 session，以及完整保存復原時間線。

雲端服務不是自動合規

採用雲端認證服務，並不代表券商可以把責任外包。券商仍須界定與服務供應商交換哪些資料、資料用途、最少必要資料、服務地點、保存期限、管理員存取權、SLA、事故通報、稽核權及服務中斷時的應變安排。

尤其在採用生物識別或身份證明文件核實時，資料治理必須與技術流程同步設計。誰可以看見原始影像？服務供應商保存什麼？券商收到的是原始資料、核實結果，還是風險摘要？復原失敗或服務不可用時，是否有人工處理及客戶通知方案？這些問題都應在合約、DPA、私隱影響評估及營運 runbook 中明確回答。

以 2027 年 7 月 8 日倒推，現在應該開始什麼？

證監會要求在通函發出後 12 個月內，且不遲於 2027 年 7 月 8 日，實施穩健的認證方案；大型互聯網經紀行則應立即實施。對業界而言，最務實的方式不是等待所有系統一次過完成，而是採用風險為本的分階段路線。