BM強制2FA進不去

登入 Ads Manager 想處理一筆 pending 付款，頁面卻先要求 BM 人員啟用雙重驗證。點繼續沒有反應，付款清不了，廣告也跑不了。

這時最危險的動作，是把它當成瀏覽器故障：換 Profile、換 IP、找 Cookie，或者讓操作員去收帳號持有人的驗證碼。

BM 強制 2FA 是身分驗證邊界，不是普通環境問題。驗證交回帳號持有人；完成前，接 BM、綁卡和管理員變更全部停。

先分清：是誰要求，誰來完成

BM 可以要求相關人員啟用雙重驗證，但真正配置和完成 2FA 的物件仍是登入 Facebook 的個人號。

這意味著 BM 負責人可以要求團隊成員開啟驗證，卻不能替另一個個人號持有人生成驗證碼、接管驗證應用或收走恢復材料。

如果操作員看到「此業務資產組合要求雙重驗證」，先確認當前登入的是哪個個人號，再把頁面交回該帳號持有人。不要因為任務屬於公司，就預設任何公司管理員都能完成這個人的身分驗證。

真實社群問題裡，有人先看到付款 pending，登入處理時又被 BM 的 2FA 頁面攔住。此時付款和身分驗證同時存在，但順序不能顛倒。

個人號還沒有通過當前身分要求，操作員就無法可靠確認自己看到的是哪個廣告戶、是否有付款權限，也無法完成後續管理員操作。先解決身分層，再回到付款層。

不要為了清一筆付款，臨時把權限轉給另一個號，也不要用另一個瀏覽器繼續撞同一頁面。這樣做只會新增身分和權限變化，原來的 2FA 阻塞仍然存在。

換一個乾淨瀏覽器有時能排除快取或頁面載入問題，但它不能代替雙重驗證本身。

如果頁面明確要求 2FA，判斷標準不是新瀏覽器能不能開啟，而是帳號持有人是否已完成 Facebook 當前提供的驗證或恢復路徑所要求的身分驗證。

Cookie 是敏感會話材料，不是所有權證明。TOTP 金鑰、驗證碼和恢復碼也不應該出現在群聊、任務表、官網表單或普通操作日誌中。

把這些材料交給操作員，可能暫時越過一個頁面，卻會讓後續所有操作都無法證明是誰授權、誰完成以及誰能恢復。

2FA 完成不等於原來的所有問題一起消失。

重新登入後依次確認：

如果 2FA 已完成，頁面隨後明確顯示缺資產、廣告戶停用或付款被拒，就轉入對應路徑。不要繼續把所有問題都叫「2FA 還沒好」。

付款仍被拒時，參考 Facebook 廣告付款被拒排查；不確定到底是個人號、廣告戶還是 BM 出問題，可先看 Facebook 帳號狀態區別。

一批帳號生產時，2FA 阻塞意味著當前帳號需要持有人確認，不代表它已經失敗，也不應該拖著整批任務一起停。

工蜂 FLOW 會把要求安全驗證的帳號留在待處理清單，記錄停在身分層；其他狀態明確的帳號繼續接 BM、綁卡和清管理員。持有人完成驗證後，再從同一個帳號和環境重新讀取狀態。

官網諮詢不接收密碼、Cookie、TOTP、驗證碼或恢復碼。需要驗證流程時，只說明帳號規模、當前工具和卡住的頁面類型即可。

驗證交回持有人，完成前不讓生產流程越過身分層。

核對日期：2026-09-01

來源用於事實核對，不代表認可、合作或為來源觀點背書。