According to Okta’s November 2023 root-cause analysis, attackers signed into Okta’s customer support case-management system with a service-account username and password an employee had saved into a personal Google account. Phishing-proof MFA 2.0 would have closed that entry path by removing the reusable support secret staff could export outside the corporate boundary. HAR files that later held session tokens used against five customers are residual post-auth collection; login MFA does not erase bearer tokens already sitting in support exports.
For the full attack-chain narrative, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped the Okta support-system sign-in?
Yes. MFA 2.0 would have stopped the Okta support-system entry path if support access no longer depended on a long-lived service-account password an employee could save into a personal Google vault. According to Okta’s RCA on 3 November 2023, “The username and password of the service account had been saved into the employee’s personal Google account,” and Okta assessed the most likely exposure as compromise of that personal Google account or personal device. Public reporting does not establish how the personal Google account or device was compromised. Device-bound, phishing-proof credentials leave no transferable password to copy into a consumer store, which is the prevention-focused model: the reusable secret never exists to leave managed control.
Why does a support service-account password defeat “just add MFA” thinking?
A support service-account password defeats “just add MFA” thinking because the failure is the shared secret itself, not a published push or OTP story on that account. Public reporting does not establish MFA prompts, factors, or policy failures on Okta’s support service account. Once the username and password sat in a personal Google account, anyone who opened that vault could replay the same password against the support system without touching the employee’s Okta-managed laptop again. Stacking another phishable factor on a copyable password still leaves exportable material. Workload identity and passwordless workforce controls for support tooling remove the shared-secret class rather than decorating it.
Would passkeys alone have closed this Okta support path?
Passkeys alone would not automatically close an Okta-style support path if the organization still runs a password-based service account staff can save elsewhere. Passkeys are phishing-resistant at the login ceremony. MFA 2.0 is phishing-proof across the identity lifecycle because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. If support systems still accept a shared password vaulted in a personal Google account, the lifecycle gap stays open even when interactive user logins use passkeys. The fix is killing password-based support service accounts, not only hardening one human login form.
Would MFA 2.0 have stopped the five HAR session hijacks?
No. MFA 2.0 would not have stopped the five customer Okta session hijacks that came from tokens embedded in HAR files. According to Okta’s RCA, some accessed files “contained session tokens which could in turn be used for session hijacking attacks,” and “the threat actor was able to use these session tokens to hijack the legitimate Okta sessions of 5 customers.” That phase is post-authentication collection and replay after legitimate admin sessions already existed. Closing the support password path is the prevention claim for initial access. Revoking HAR-borne tokens, keeping tokens out of case exports, and binding admin sessions by network location are residual containment. Okta also published HAR handling guidance for customers who still attach those captures to cases.
What should CISOs change for support identity after Okta’s 2023 RCA?
CISOs should kill password-based service accounts for support case systems, ban employee storage of shared secrets in personal Google or other consumer vaults, and treat HAR attachments as bearer-token risk. Okta later blocked personal Google profiles in Chrome on managed laptops, revoked embedded HAR tokens, and shipped administrator session-token binding by network location so admins re-authenticate on network change. Pair that hygiene with device-bound workforce authentication so support access cannot fall back to a copyable password. The device-bound architecture removes the secret that made Okta’s support sign-in possible after the password left the corporate boundary.
