MFA 是什麼？多因素驗證、TOTP、Push、SMS 與 Passkey 完整指南

先講結論：MFA 是一套驗證生命週期，不是一個六位數欄位

多因素驗證要求使用者提出兩種以上不同類型的證據，例如密碼這類『你知道的』資訊，加上安全金鑰這類『你擁有的』裝置。它能顯著降低密碼重用、Credential Stuffing、Password Spraying 與單一密碼外洩造成的帳號接管，但不能自動阻止釣魚中繼、Session Cookie 竊取、惡意程式或脆弱的帳號復原流程。

真正的 MFA 專案至少包含風險與保證等級、Authenticator 選型、註冊與綁定、登入 Ceremony、敏感操作 Step-up、遺失裝置復原、因素更換、Session 管理、監控及汰換弱方法。只在前端新增 OTP 欄位，卻保留不需 MFA 的 API、舊版 App Password 或客服人工解鎖，整體強度仍由最弱入口決定。

企業不應只追求『啟用率』。更重要的是抗釣魚方式覆蓋率、管理員與高權限帳號保護率、復原流程成功與濫用率、弱因素占比、Push 拒絕異常、Session 撤銷完整性，以及使用者是否能準備第二個可信 Authenticator。

• 所有人至少啟用一種 MFA，高權限與高價值帳號優先採抗釣魚驗證
• 每個登入入口、API、行動應用程式、VPN 與舊協定都必須納入相同政策
• 至少準備兩個彼此獨立的 Authenticator，並設計不弱於正常登入的復原流程
• 涉及付款、權限、MFA 變更或敏感資料匯出時，以 Step-up 再確認使用者意圖

什麼才算不同因素？密碼加 PIN 不是 MFA

常見因素分為知識、持有與生物特徵三類。密碼、PIN、安全問題都屬於『你知道的』；手機、Authenticator App、安全金鑰、Smart Card 與裝置私鑰屬於『你擁有的』；指紋、臉部或虹膜屬於『你是誰』。位置與行為訊號適合做風險判斷，但不應被當成唯一的高保證 Authenticator。

輸入密碼後再回答安全問題，或輸入兩組不同密碼，仍只是重複知識因素。兩個因素還必須盡量避免相同失陷路徑：若密碼與 TOTP 都儲存在同一台已被遠端控制的電腦，形式上雖有兩種因素，實際獨立性已下降。

生物特徵在 WebAuthn 或手機 Authenticator 中通常用來解鎖裝置內的私鑰；伺服器不應取得或保存原始指紋、臉部影像。NIST 也不把生物特徵單獨視為 Authenticator，而是要求它與實體 Authenticator 一起使用。

先做威脅模型：MFA 能擋什麼，又擋不了什麼？

MFA 最擅長處理的是攻擊者只有密碼的情境。即使密碼來自釣魚、惡意程式、第三方外洩或猜測，缺少第二因素仍不能完成登入。但若使用者把 OTP 輸入攻擊者控制的反向代理，攻擊者可以在有效時間內轉送；若攻擊者偷到已完成 MFA 的 Session Cookie，也可能直接繞過登入。

威脅模型要涵蓋即時 Phishing Proxy、Push Fatigue、SIM Swap、電話號碼轉移、Authenticator Seed 外洩、裝置失竊、Session Hijacking、客服社交工程、OAuth／SSO 錯誤、Legacy Protocol，以及攻擊者控制 Email 後重設第二因素。不同 Authenticator 只處理其中一部分風險。

因此安全判斷應從『攻擊者還缺什麼』出發，而不是從畫面有幾個步驟出發。手動輸入的 OTP 沒有與特定 Session 或網站來源密碼學綁定，Passkey 則會讓 Credential 只能在註冊的 Relying Party 範圍內使用，兩者面對釣魚的結果不同。

AAL1、AAL2、AAL3：保證等級不是產品名稱

NIST SP 800-63B-4 以 Authentication Assurance Level 描述驗證保證。AAL1 允許單一或多因素；AAL2 要求一個多因素 Authenticator，或兩個分離因素，而且至少提供一種抗釣魚選項；AAL3 則要求抗釣魚、不可匯出的硬體式金鑰能力與更嚴格的 Verifier Impersonation Resistance。

AAL 是整個驗證流程的性質，不是廠商在按鈕旁放一個『AAL2』標籤就成立。密碼政策、Authenticator 種類、FIPS／密碼學要求、重新驗證時間、復原、綁定、撤銷與 Federation 都會影響結果。

民間企業不一定要逐條採用美國政府規範，但可用 AAL 作風險溝通框架：一般內容帳號、能查看客戶資料的員工、能改 IAM 或付款資訊的管理員，不應用同一套 Authenticator 與重新驗證週期。

SMS、TOTP、Push、Passkey 怎麼選？先看抗釣魚與失陷路徑

方法選型不能只比便利性。SMS 容易導入但依賴電話網路與號碼生命週期；TOTP 不需電信訊號且標準化成熟，但使用者手動輸入的短碼仍可被釣魚代理中繼；Push 可呈現更多情境，但若只是連續跳出『允許』，會產生疲勞風險；Passkey／WebAuthn 透過非對稱金鑰與 RP ID／Origin 綁定提供更強的抗釣魚能力。

成熟做法通常不是只留一種方法，而是設計有方向的組合：以 Passkey 或安全金鑰作首選；TOTP 作相容性與離線備援；Push 必須有 Number Matching、交易情境與節流；SMS 僅作過渡或低風險備援，並為無障礙、裝置遺失與跨平台使用者保留安全替代方案。

SMS 與電話驗證：可降低風險，但不能被包裝成最高強度

NIST 將經 Public Switched Telephone Network 傳送的 SMS／語音碼列為 Restricted Authenticator。風險不只來自 SS7 攔截，還包括 SIM Swap、Number Porting、電信商帳號社交工程、回收電話號碼與鎖定畫面洩漏。OWASP 建議高價值或處理個資的系統不要把 SMS 當主要強方法。

若因使用者覆蓋或轉型期仍需保留，必須提供不受限的替代 Authenticator；在發送前檢查近期 SIM／裝置變更與異常行為；按帳號、電話與風險限制嘗試；短 TTL、單次使用且成功後立即失效；不得在 Log、APM、客服畫面或 Analytics 保存明文驗證碼。

設定或變更電話號碼等同綁定新 Authenticator，不能只依賴目前登入 Session 或原本電話收一次碼。高價值帳號應要求既有強因素、延遲生效與 Out-of-band 通知，並保留可稽核的風險接受與遷移期限。

• 不要把 Email Code 當成 SMS 的自動安全升級；NIST 不允許 Email 作 Out-of-band Authentication
• 不要在『收不到簡訊』時直接降級成安全問題或客服口頭核對
• 將 SMS 使用量、SIM 變更命中、重送、失敗與移轉進度納入監控
• 為沒有手機、無收訊、無障礙及國際使用者提供等強度替代方式

TOTP 與 HOTP：短碼是共享秘密的輸出，不是抗釣魚證明

TOTP 依 RFC 6238，以裝置與伺服器共享的 Secret Key 加上時間步階計算一次性密碼；預設 Time Step 為 30 秒。HOTP 則以 Counter 遞增。兩者的優點是標準化、可離線產生、無需電信網路，但 Verifier 必須持有能重算 OTP 的 Seed，因此 Seed 儲存與存取權限是核心風險。

驗證窗口要在時鐘漂移與攻擊面之間取平衡。窗口越寬，可被利用的有效期越長；伺服器必須限制嘗試次數，並記錄已成功使用的 Time Step 或 Counter，同一個 OTP 在成功驗證後不得再次接受。Rate Limit 應以帳號為主，不可只限制 IP，否則分散式攻擊仍能大量猜測。

TOTP 碼可以被使用者輸入釣魚網站，再由攻擊者即時轉給真站。它具 Replay Resistance 的有限特性，卻沒有把輸出綁定到特定網站與 Session，因此不屬於 NIST 所稱的 Phishing-resistant Authentication。

Push MFA：不要讓『按下允許』變成反射動作

Push 的安全性取決於使用者必須確認什麼。若手機只顯示 Allow／Deny，攻擊者在已知密碼後可以連續發送請求，誘導使用者為了停止干擾而誤按允許，形成 MFA Fatigue。NIST 要求 Out-of-band 流程增加能證明使用者正參與該 Session 的 Secret Transfer，並建議限制 Push 發送頻率。

較佳做法是 Number Matching 或等價的 Session Binding：登入頁顯示短 Challenge，使用者在手機上選擇或輸入相符值；同時顯示服務名稱、動作、裝置、位置與時間，對付款或權限變更再綁定金額、對象與資源。拒絕按鈕要能回報『不是我』，立即觸發風險處置。

Push 服務故障或手機離線時，不應自動降級到無保護登入。預先註冊的 Passkey、安全金鑰、TOTP 或單次 Recovery Code 才是可控備援；客服臨時關閉 MFA 必須被視為高風險復原事件。

• 限制未完成 Push 的總數與頻率，新的請求應使舊請求失效
• 清楚顯示登入或交易情境，避免只有模糊的 Allow／Deny
• 要求裝置解鎖或本機 User Verification 後才能批准
• 偵測短時間大量請求、反覆拒絕、陌生位置與 Impossible Travel
• 拒絕事件應可一鍵撤銷 Session、重設密碼並通知安全團隊

Passkey／WebAuthn 為什麼能抗釣魚？關鍵是非對稱金鑰與網站綁定

Passkey 是基於 FIDO 標準的 WebAuthn Credential。註冊時 Authenticator 為特定 Relying Party 產生金鑰對：Public Key 與 Credential ID 交給伺服器，Private Key 留在 Authenticator。登入時伺服器產生不可預測的 Challenge，Authenticator 在使用者 Presence／Verification 後簽章，伺服器再以 Public Key 驗證。

抗釣魚的核心不只是『不用密碼』，而是 Credential 有 RP ID Scope，Authenticator Data 包含 rpIdHash，瀏覽器與伺服器還要驗證 Origin。假網站無法要求 Authenticator 為真正網站的 RP ID 產生有效簽章，也無法把在其他網站取得的簽章移作真正網站使用。

實作端仍不能把安全責任全交給 Browser。Relying Party 必須驗證 Challenge 一次性與逾時、Origin 精確 Allowlist、rpIdHash、User Presence、要求時的 User Verification、Credential ID、Signature、User Handle 與 Sign Count／風險訊號；註冊流程也要防止攻擊者替受害者綁定自己的 Authenticator。

同步式 Passkey、裝置綁定 Credential 與硬體安全金鑰怎麼取捨？

Passkey 可以由平台 Credential Manager 在使用者裝置間同步，也可以綁定在單一硬體 Authenticator。同步式 Passkey 改善跨裝置與遺失復原，降低大規模消費者導入摩擦；裝置綁定或硬體安全金鑰則更容易滿足不可匯出、資產管理與最高保證需求。

選擇要回到威脅模型。一般客戶服務可把同步式 Passkey 作為主要登入方式，並依平台帳號的復原與裝置安全設計風險控制；管理員、Production Access、Root CA、財務付款與高影響操作可要求企業管理的安全金鑰、Attestation 政策、指定 Authenticator 類型或兩把實體金鑰。

不要用 User Agent 字串猜測所有安全屬性，也不要因為 Passkey 體驗好就只允許註冊一組。產品必須讓使用者查看 Authenticator 名稱、建立時間、最後使用、備份狀態或裝置資訊，能新增第二組、撤銷遺失裝置並收到通知。

註冊與綁定：新增 Authenticator 本身就是高風險操作

若攻擊者已取得一個被竊 Session，而系統允許直接新增 Passkey 或顯示 TOTP QR Code，他就能把自己的裝置綁到受害帳號。綁定前應要求近期且符合目標保證等級的重新驗證，不可只相信數小時前建立的 Session。

跨裝置綁定時，Binding Code 必須由 CSPRNG 產生、單次使用、短時間有效，透過已保護端點與使用者主動轉移；NIST SP 800-63B-4 明確禁止把 Binding Code 經不安全通道傳送。註冊完成後，要向既有通知通道發送包含 Authenticator 類型、時間與撤銷入口的通知。

首次導入時，使用者應註冊至少兩種可用方式，或一組主要 Authenticator 加單次 Recovery Codes。QR Code、Seed、Private Key Export、Recovery Code 只應在必要瞬間呈現，禁止進入 Session Replay、客服錄影、前端 Analytics、Error Tracking 或伺服器 Log。

• 以近期強驗證授權新增、移除或替換 Authenticator
• 讓使用者辨識名稱、類型、建立時間與最後使用資訊
• 防止重複 Credential、Race Condition 與跨帳號錯誤綁定
• 成功後通知並提供快速撤銷；高價值帳號可加延遲生效
• 不在 URL、Log、Telemetry 或客服工具暴露 Provisioning Secret

復原與備援：最弱的 Reset 流程會決定整體 MFA 強度

使用者一定會換手機、遺失安全金鑰或無法使用生物辨識。沒有設計復原，客服最終會建立臨時旁路；復原太容易，攻擊者就會略過 MFA，直接攻擊客服、Email 或電話號碼。復原不是例外流程，而是另一種 Authentication Ceremony。

Recovery Code 應由 CSPRNG 產生、具足夠熵、只顯示一次、每碼單次使用，伺服器只保存雜湊或等價 Verifier。使用者應能下載或列印，並看到剩餘數量；重新產生整組時必須使舊碼全部失效。不要用六位數 Recovery Code 假裝長期秘密。

高價值帳號可要求兩個既有 Authenticator、人工身分驗證、管理者核准、等待期與 Out-of-band 通知的組合。復原完成後應撤銷舊 Authenticator、輪替 Session／Refresh Token、要求檢查近期活動，並建立可調查的安全事件。

更換或移除 MFA：不能只靠目前已登入的 Session

變更電話、重建 TOTP、移除 Passkey、停用 MFA 與新增 Recovery Method 都能讓攻擊者取得長期控制，因此必須視為高風險事件。OWASP 建議先使用既有已註冊因素重新驗證，不能只因 Cookie 尚未過期就允許操作。

高風險帳號可對因素替換設定冷卻期，在期間限制付款、API Key、Email 變更與管理權限；同時通知舊 Email、舊 Push 裝置與安全管理者。若使用者聲稱所有因素都遺失，應走正式 Recovery，而不是讓同一張客服工單直接跳過。

移除最後一個強 Authenticator 前，應要求先註冊替代方式，或清楚降級帳號權限。所有變更要記錄 Actor、來源、舊／新類型、風險訊號、授權 Ceremony、通知與結果，但不得記錄 Seed、OTP、Private Key 或完整 Recovery Code。

Step-up Authentication：敏感操作要重新確認，而非永遠相信登入狀態

登入時完成 MFA 不代表整個 Session 期間所有操作都具有相同保證。當使用者變更密碼、Email、付款對象、API Key、角色權限、MFA 因素，或大量匯出敏感資料時，應要求近期強驗證，並把批准內容綁定到具體操作。

Step-up 必須防止攻擊者先建立正常 Session，再誘導使用者批准另一個動作。介面要明確呈現『你正在批准什麼』，Transaction Authorization 應把金額、收款方、資源、權限或變更內容納入簽章或受保護的 Challenge，而不是只要求一個通用 OTP。

完成 Step-up 後，只提升必要 Action 或短時間內的 Assurance Context，不應把整個 Session 無限升級。伺服器端必須檢查 Auth Time、Authenticator Method／Class Reference、風險與交易綁定資料，不能只依賴前端顯示。

Session 與 Token：MFA 完成後仍要避免 Session Hijacking

驗證成功後，系統應輪替 Session ID，避免攻擊者預先固定或取得 Pre-authentication Session 後沿用；Session 必須以 Secure、HttpOnly、適當 SameSite、短 Idle Timeout、Absolute Timeout 與伺服器端撤銷能力保護。MFA 不能補救把 Session Token 放在可被 XSS 讀取的位置。

Session 應記錄達成的 Assurance Level、Authentication Time、使用的 Authenticator Class，以及是否完成特定交易授權。這些屬性必須由可信伺服器或 Identity Provider 簽發並在 Backend 驗證，不能接受前端傳來的 isMfa=true。

偵測到因素更換、密碼重設、Push Fatigue、裝置遺失或帳號接管時，應能撤銷所有 Session、Refresh Token、Remembered Device、App Password 與相關 OAuth Grant。只刪除瀏覽器 Cookie，不代表其他 Access Token 已失效。

Risk-based Authentication 不能變成靜默繞過 MFA

裝置、IP、地點、時間、Impossible Travel、ASN、Browser Metadata 與行為訊號可以決定何時要求 Step-up、拒絕或啟動人工審查，但風險引擎不是可被不透明信任的第二因素。攻擊者可能重用裝置 Cookie、透過受害者網路代理或竊取完整 Browser Profile。

『記住這台裝置』Token 應具高熵、綁定帳號、可撤銷、短期有效並受 Cookie 安全屬性保護；不可只是 Local Storage 的布林值。高權限、MFA 變更與關鍵交易不應因 Trusted Device 就永久免驗。

風險決策需可觀察且可回溯：保存觸發的 Signal、Policy Version、決策與結果，監控 False Positive、攻擊通過率及族群偏差。不要保存不必要的精確位置或敏感裝置資料，並提供隱私告知與保存期限。

別漏掉 API、Mobile、SSO、Legacy Protocol 與 App Password

Web Login 啟用 MFA 後，攻擊者會尋找不受相同政策保護的入口：舊版 Basic Auth、IMAP／SMTP、VPN、Mobile API、Support Portal、CLI Device Flow、App Password、SCIM、Recovery Endpoint 或 OAuth Password Grant。任何能取得長期 Token 或建立 Session 的流程都要列入 Authentication Inventory。

機器對機器工作負載不應假裝用人的 TOTP。Service Account 應改用短效工作負載身分、mTLS、Signed Assertion 或受管 Secret，並用最小權限、輪替與稽核管理。共享管理員帳號則應拆成可歸責的個人身分，緊急 Break-glass 帳號離線保護並定期演練。

SSO 導入後，Service Provider 必須正確要求 AuthnContext／ACR 與新鮮度，不能只看到 IdP Login 就假設已完成目標 MFA。Identity Provider、Federation、Fallback Login 與 Local Admin 入口要用同一威脅模型測試。

• 建立所有 Authentication、Token Issuance、Recovery 與 Factor Management 入口清冊
• 停用不支援 MFA 的 Legacy Protocol 與 Password Grant
• App Password 視為高風險長期 Credential，能不用就不提供
• 對 Service Account 使用 Workload Identity，不以共用手機收 OTP
• 定期驗證 Local Admin／Break-glass 不會成為日常繞過路徑

可用性與無障礙：安全選項必須真的能被使用

如果 Authenticator 流程對某些使用者不可達，組織最後會建立更弱的例外。導入前要測試鍵盤、螢幕閱讀器、放大、色彩對比、認知負荷、跨裝置、離線、漫遊、受管裝置、沒有智慧型手機，以及共用櫃台等情境。

不要以顏色或地圖位置作為唯一確認資訊；OTP 欄位要支援 Paste、Autofill 與清楚錯誤，但不可把完整碼寫入 Analytics；Passkey 要提供辨識 Authenticator、取消、改用其他方式與失敗復原的清楚路徑。

使用者教育應短而具體：不分享 OTP、不批准未主動發起的 Push、檢查交易內容、收到異常請求立刻拒絕並回報。安全團隊則必須確保回報後真的能快速鎖定風險、撤銷 Session 與提供復原。

監控與指標：不要只看 MFA Enrollment Rate

高啟用率可能掩蓋大量使用 SMS、共用裝置或容易繞過的復原。指標應分解到 Authenticator 類型、保證等級、角色、應用程式與入口；對高權限帳號單獨追蹤抗釣魚覆蓋率與弱因素剩餘量。

事件 Log 應記錄成功／失敗、Authenticator ID 的非敏感識別、方法類型、AAL、Step-up 原因、風險訊號、Factor 變更、復原、撤銷與通知。絕不記錄 Password、OTP、TOTP Seed、Private Key、完整 Recovery Code 或可直接重播的 Assertion。

Push 拒絕、短時間大量要求、同一 OTP 重播、異常 Recovery、Factor 新增後立即匯出、管理員降級 Authenticator，以及同一裝置大量跨帳號綁定，都應建立告警與 Investigation Playbook。

偵測到 MFA 攻擊或因素外洩時怎麼處理？

單一使用者收到未主動發起的 Push，可能代表密碼已被攻擊者取得。系統應停止後續 Push、通知使用者、提高風險、要求安全的密碼重設或 Passkey 驗證，並檢查來源、Session、Token、Factor 變更與資料存取。不要只叫使用者繼續按拒絕。

若 TOTP Seed、Push Signing Key、SMS Provider Credential 或 MFA 服務遭到系統性外洩，需要盤點受影響 Credential、停止弱路徑、撤銷 Session／Token、重新綁定 Authenticator、通知利害關係人並保存證據。TOTP Seed 不能像公開 Salt 一樣留著不處理，因為持有 Seed 就能持續產生有效碼。

對可疑 Factor Replacement 或 Recovery，應凍結敏感操作、通知舊通道、回復被撤銷的合法 Authenticator，並檢視客服或管理者操作紀錄。事件後要把根因修到 Policy、產品與測試，而非只封鎖單一 IP。

• 撤銷受影響 Authenticator、Session、Refresh Token、App Password 與 OAuth Grant
• 保留足以重建時間線的事件資料，但不擴散 OTP 或 Secret
• 通知使用者哪些裝置、位置、因素與操作受影響
• 輪替 Provider／Signing／Encryption Key，並驗證舊金鑰真正失效
• 修正註冊、Rate Limit、Recovery 或 Session 控制後做攻擊鏈複驗

企業導入路線：從高風險帳號開始，逐步汰換弱因素

第一階段先建立 Authentication Inventory、角色與資料風險分級，盤點所有登入、Token、Recovery 與 Legacy 入口。對管理員、開發、財務、遠端存取與能接觸客戶資料的帳號先強制抗釣魚 Authenticator，並準備至少兩把金鑰或第二個可信方式。

第二階段讓一般使用者註冊 Passkey／WebAuthn，以 TOTP 作相容性備援；改善 Browser、Mobile、Cross-device 與 Helpdesk 流程；同時加入 Number Matching、Push 節流、Factor 變更通知、Recovery Code 與 Session 撤銷。

第三階段以數據縮減 SMS、Email Code、App Password 與 Legacy Protocol。每次降級或例外都要有 Owner、Risk Acceptance、補償性控制與到期日；持續演練遺失裝置、IdP 中斷、Push Provider 故障與大量帳號接管事件。

測試清單：不只驗證『正確 OTP 可以登入』

功能測試要涵蓋每種 Authenticator 的註冊、登入、Step-up、變更、撤銷與復原，也要驗證錯誤與競態：重播同一 OTP、重用 Challenge、平行提交、窗口邊界、取消 Ceremony、跨帳號 Credential、錯誤 Origin、錯誤 RP ID、缺少 UP／UV、失效 Session 與 Token。

安全測試要模擬 Phishing Proxy、Push Flood、SIM Change、Authenticator 遺失、已竊 Session 新增 Factor、客服社交工程、Recovery Code 暴力猜測、舊 API 無 MFA、Mobile Deep Link、SSO AuthnContext 降級，以及 Factor 變更後的 Session 撤銷。

營運測試則要確定通知送達、告警可調查、Helpdesk 有一致 Runbook、Break-glass 可用但不被日常濫用、Provider 中斷不會無條件 Fail Open，且所有敏感 Log 都沒有 OTP、Seed、Private Key 或 Recovery Code。

• 相同 OTP 成功後再次提交必須失敗；錯誤嘗試受帳號層級限制
• WebAuthn Challenge、Origin、RP ID、Signature、UP／UV 均由伺服器驗證
• Factor 新增、替換、停用與 Recovery 均要求目標等級重新驗證
• 任何入口、App、API、CLI 與 Legacy Protocol 都不能繞過政策
• 高風險事件能撤銷全部 Session、Token 與已記住裝置
• 桌機、手機、跨裝置、無障礙與離線備援都有實際測試證據

常見迷思：有 MFA 不代表帳號接管問題已經結束

『六位數每 30 秒變一次，所以不會被釣魚』是錯的；攻擊者可以在有效窗口即時轉送。『生物辨識資料會上傳網站』也不一定正確；在 WebAuthn 中，Biometric 通常只在本機解鎖 Authenticator，伺服器驗證的是簽章。

『Passkey 等於同步到雲端就不安全』過度簡化了問題；同步改善復原與採用，但高保證情境可選裝置綁定或硬體金鑰。反過來，『用了 Passkey 就不用保護 Session』也錯，因為登入後 Token 仍可能被 XSS、惡意程式或錯誤儲存竊取。

『客服可以人工關閉 MFA，因為有人核對身分』最危險。若核對依賴公開個資、安全問題或已被接管的 Email／電話，它的保證遠低於正常登入。復原流程必須被威脅建模、測試、監控並持續改善。

MFA 上線前的最終檢查表

一套可持續的 MFA 架構應同時回答：目標保證等級是什麼、不同帳號能用哪些 Authenticator、哪些方式抗釣魚、如何安全綁定與替換、使用者遺失全部裝置時怎麼辦、敏感操作何時 Step-up，以及事故發生時能否撤銷所有 Credential 與 Session。

不要等到 MFA 上線後才補 Recovery、Helpdesk 與 Legacy Protocol。這些通常是攻擊者最先尋找的旁路，也最需要跨產品、IAM、客服、IT、法遵與資安共同決策。

• 已盤點所有 Web、Mobile、API、SSO、VPN、CLI、Legacy 與 Recovery 入口
• 高權限帳號已採抗釣魚 Authenticator，並有獨立備援
• TOTP Seed、Binding Code、Recovery Code 與 Provider Key 有適當保護
• Push 有 Number Matching／情境、頻率限制與『不是我』處理
• WebAuthn 完整驗證 Challenge、Origin、RP ID、UP、UV 與 Signature
• Factor 新增、移除、替換與復原均需重新驗證、通知與稽核
• Step-up 與交易授權綁定具體動作，而非只再輸入通用 OTP
• MFA 完成後輪替 Session，風險事件可全域撤銷 Token 與裝置
• 已完成桌機、手機、跨裝置、無障礙、失敗與攻擊情境測試
• 弱因素與例外都有 Owner、補償控制、期限與移轉指標

Redmark 在 MFA 安全治理中扮演什麼角色？

Redmark 可從外部與登入後網站攻擊面協助辨識與 Authentication／Session 相關的可觀察問題，例如弱 Cookie 屬性、未受保護的路徑、安全標頭、部分存取控制與流程暴露，並以持續掃描、風險資訊與複驗協助團隊追蹤修復。

但自動化網站掃描不能證明整個 MFA 架構符合 AAL，也不能單獨驗證客服身分核驗品質、TOTP Seed 是否位於 HSM、Passkey Attestation 政策、所有 Legacy Protocol、IdP 內部設定或人員社交工程韌性。完整治理仍需要架構審查、程式碼與設定檢查、威脅建模、人工測試、IAM Log 分析及事件演練。

最實際的做法，是把驗證入口與高風險流程納入授權的登入後掃描與人工測試範圍，將可安全自動驗證的問題持續檢測，並把需要身分、復原、營運與流程判斷的控制交由對應團隊定期審查。