先分清失去的是哪種存取能力
忘記密碼、遺失第二項驗證工具，以及電郵被他人控制，是不同事件。客戶若仍能以另一種驗證方式登入，或可在正常已認證工作階段加入新工具；若所有可用工具都失去，便需要帳戶恢復程序。NIST 明確區分兩者。設計時應列出實際帳戶和常見故障：換手機的個人、已離職的公司管理員，以及電郵地址疑遭擅改的客戶。各種情況需要不同的核實和升級途徑。
支援話術不應把所有情況都簡化為「發一封重設電郵」。若郵箱已遭入侵，重設郵件可能把帳戶交給攻擊者；只憑密碼就重設第二項驗證，則會抹去它原本提供的保障。應記錄求助者仍控制哪些登入憑證、哪些聯絡渠道早前已核實，以及帳戶能否處理款項、披露紀錄或更改其他用戶。帳戶後果越重大，改變存取權前所需的證據和審查就應越嚴謹。
恢復帳戶既是介面設計，也是業務流程。要決定高風險要求由誰批准、客服可看見甚麼資料、個案可等多久，以及客戶無法提供標準證明時如何處理。不能以「來電者說得可信，客服就可破例」作為答案。有紀錄的例外可加入額外審查、等待期或受限制的帳戶狀態。應預早告訴用戶可設定哪些恢復選項，免得他們在被鎖於帳戶之外才第一次知道要求。
預先建立可用的恢復選項
NIST 為其適用系統列出預存恢復碼、發送的恢復碼、恢復聯絡人及重新核實身分等方法。香港中小企可用這框架思考哪種選項適合自己的客戶，但不能聲稱所有 NIST 保證級別規定自動成為香港私營服務的法律要求。妥善保存的恢復碼可幫助遺失手機的客戶；預先核實的備用聯絡方式可在主要郵箱失效時派上用場。若事故前從未提供，事發時就無從使用。
在註冊及帳戶設定頁，說明如何加入第二種可用驗證工具或恢復選項，並讓客戶確認已妥善保存恢復碼。恢復碼是秘密，不是普通客服參考編號。不要在例行電郵列出，也不要放進分析事件或讓客服從畫面讀回。NIST 對預存恢復碼說明了安全交付、服務端單向雜湊保存、使用後失效及重新發出等做法。即使產品採用別的方法，這些細節仍可幫助業主向供應商提出具體問題。
更改恢復聯絡渠道應視為保安事件。如果攻擊者可先改恢復電郵，然後立即用它取回帳戶，保障只是被移走。新增或更改恢復渠道時應要求合適的認證，並通知原有渠道。對敏感帳戶，可考慮在新渠道可用於重大恢復前設等待期或人工審查。實際等待時間取決於產品風險，並非這些來源給所有服務的劃一數字。規則要讓客戶看見，免得正當更改被誤會為莫名鎖帳。
讓重設流程有明確驗收標準
OWASP 建議無論帳戶是否存在，密碼重設要求都回覆一致訊息，避免陌生人借表格試探客戶地址。實際可行時亦要避免明顯回應時間差異，並限制濫用要求。重設憑證應隨機、足夠長、只能用一次、安全保存，並於適當時間後失效。應經預期渠道送出，重設網址須使用可信設定來源，而非由可被攻擊者操控的要求標頭建立。這些是工程驗收點，並非向客戶保證絕對安全的宣傳語。
完成有效重設後，應通知帳戶持有人帳戶已有變更。OWASP 指出未收到有效憑證前不應更動帳戶，並建議考慮改密碼後是否使現有工作階段失效。若服務包含敏感紀錄，負責人應明確決定是否撤銷其他登入、要求重新登入，以及怎樣提示客服留意異常活動。若重設連結會削弱原有登入檢查，就不應因此自動登入。事件要留紀錄，但重設憑證及新秘密不可寫入日誌。
遺失第二項驗證工具要有自己的處理途徑。NIST 把帳戶恢復與仍持有另一驗證工具時更換忘記的密碼分開討論。應按帳戶類別列出可接受的證據組合，以及是否需要人工審查。出生地或公開公司資料等知識題，不應單獨作為證明；答案可被猜中、查到或與他人共知。客服需要知道何時停止處理並升級。若恢復路徑對真正用戶和冒充者同樣容易，設計問題仍未解決。
演練客服真正會遇到的情況
假設供應商平台有兩名管理員。一人遺失手機，但仍持有另一種有效驗證工具，便可在符合檢查後，經正常已登入途徑加入替代工具。另一人同時失去手機及預存恢復碼，但仍可使用已登記郵箱；這是另一種恢復個案，系統須按文件化的證據要求處理、通知帳戶持有人，並記錄由誰批准加入新工具。兩人都說「手機不見了」，不代表流程應完全相同。
再加入惡意情況：來電者知道公司名稱、發票金額及員工姓名，卻不能控制任何已登記驗證工具或核實渠道。承包商可能知道這些業務細節，也可能從外洩訊息取得。客服不應因此刪除驗證工具。個案可能須轉到更可信的途徑，或在能核實擁有權前維持未解決。這會帶來不便，因此應預先公開選項和預期流程，而非向所有人承諾即時恢復。
也要測試客戶體驗。真實用戶須知道哪一步仍待處理、如何透過自行找到的官方渠道聯絡服務，以及收到非本人要求的恢復通知時怎樣做。測試要包括已用過的連結、過期連結、連續多次要求及不存在帳戶的要求，並一起檢查瀏覽器回覆、電郵、客服佇列和稽核紀錄。單是重設憑證產生單元測試成功，不能證明困惑的客戶可安全完成整段旅程。
在緊急事故前批准政策
負責人可批准一頁恢復矩陣，列明帳戶類別、仍可用的驗證工具、預先核實渠道、所需證據、審查者、通知方式及恢復後的限制。請供應商用測試帳戶展示密碼重設和遺失驗證工具流程，包括模擬郵箱被入侵的情況。若說明只寫「客服會核實身分」，卻不列明可依賴或絕不能接受的證據，就不足以驗收。好設計應讓忙碌時的客服仍可一致執行，證據不足時亦有清楚出口。
產品加入通行密鑰、企業帳戶或影響更大的操作後，須更新政策。適用於電子通訊帳戶的方法，未必適合可更改付款指示的帳戶。應檢視恢復要求及差點出事的個案，了解阻力或濫用，但不能單憑數量聲稱設計已安全。如果客戶常常無法走完正當途徑，就改善預先登記和客服溝通，同時維持核實界線。恢復完成的標準，是正確的人重新取得合適權限，而錯誤的人沒有捷徑。
下一步可用三個測試身分演練：一人記得密碼但失去第二項驗證，一人失去所有工具但已預設恢復方法，一人完全沒有可信證據。請業務負責人、客服主管及開發員一起觀察。逐條記錄決定、通知、所需時間及帳戶最後狀態。若流程依賴私下通融，或客服把秘密讀出，就要在真客戶受困或冒充者得逞前修正設計。
進行前先確認
- 忘記密碼與遺失驗證工具是否走不同途徑？
- 證據不足時客服能否停下並升級？
- 每次恢復有否通知帳戶持有人？
