According to Okta Security on 11 December 2024, attackers impersonating Okta Support sought customer passwords and MFA tokens from workforce users. Phishing-proof device-bound MFA 2.0 closes that path: there is no password, OTP, SMS code, email code, or push approval a user can hand over under live coaching, so fake Support never obtains a usable login. The full advisory chain is on legacymfa.sucks.
FAQ
Would phishing-proof MFA stop Okta Support impersonation credential harvest?
Yes. Phishing-proof MFA 2.0 would stop the Okta Support impersonation credential harvest at the moment of transfer because authentication uses device-bound public-key signatures with no shared secret a user can speak, type, forward, or approve for an attacker. According to Okta, legitimate Support will not ask for a password or an MFA token; the campaign still succeeds against legacy stacks when a convinced user hands those factors over. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem.
Why do OTP, SMS, email codes, and push fail under fake Okta Support pressure?
OTP, SMS, email codes, and push fail under fake Okta Support pressure because they are transferable factors. Once a workforce user believes the caller or mail is real Support, they can read a code aloud, forward a message, or tap approve. That is the same failure class as helpdesk password-reset social engineering: live coaching of a factor that still works for whoever holds it. Device-bound MFA 2.0 has no out-of-band code and no fatigueable prompt, which is why prevention, not detection, is the control story here.
Are passkeys enough against Support-impersonation MFA token phishing?
Passkeys alone are not a full guarantee against Support-impersonation MFA token phishing if enrollment or recovery still uses phishable factors. Passkeys are phishing-resistant at the login ceremony; they harden origin-bound authentication. MFA 2.0 is phishing-proof across the identity lifecycle, so registration, device onboarding, authorization, authentication, and decommissioning never introduce a password, OTP, or recovery secret someone can social-engineer. If fake Support’s only ask is “read me your code” or “approve this push,” removing those factors ends the harvest. If recovery still mints a transferable secret, the lifecycle gap remains.
What does MFA 2.0 not undo after a real workforce session already exists?
MFA 2.0 does not undo post-authentication abuse after a real workforce session already exists. Public reporting on the Okta Support advisory does not establish AiTM reverse-proxy kits, device-code OAuth theft, TAP issuance, or session-cookie theft as the method. The documented ask is passwords and MFA tokens before a usable attacker login. Once any legitimate session is already on an endpoint, local malware or infostealer theft is residual containment work: revoke, short-lived sessions where policy allows, and endpoint controls. Fooling a user into handing transferable factors is easy. Planting malware is not.
How should identity teams harden workforce recovery against verbal MFA token transfer?
Identity teams should harden workforce recovery so no password or MFA token can be verbally transferred under fake Okta Support pressure. Prefer enrolment and re-enrollment that require an already-enrolled device, not a phishable code IT or the user can read out. Treat caller ID as spoofable, as Okta states, and route real Support validation through known case processes and verified contacts. Public reporting does not establish named customers, threat actors, or victim counts for this campaign; the prevention claim still holds wherever transferable factors remain in the lifecycle.
