After Lapsus$ hit NVIDIA in February 2022, the confirmed workforce-identity damage was stolen employee passwords and roughly 71,335 NTLM hashes in later circulation, not a named interactive MFA failure at sign-in. According to NVIDIA’s customer help disclosure, the actor took employee passwords and some proprietary information and began leaking material online, and every employee had to change passwords. Public reporting does not establish the initial access method, so phishing-proof MFA 2.0 cannot be scored as having blocked or failed a named workforce login step. This case is about honest limits after credential material already left the environment.
For the confirmed timeline, leak facts, and what NVIDIA did not document, read the companion on legacymfa.sucks.
FAQ
Would MFA 2.0 have stopped the NVIDIA Lapsus$ intrusion?
No. An honest phishing-proof claim does not say device-bound authentication stopped the NVIDIA Lapsus$ intrusion. NVIDIA’s primary notice confirms a cybersecurity incident against IT resources and later theft of employee passwords and proprietary information. It does not name the first foothold or any workforce MFA ceremony. MFA 2.0 prevents phishable login and enrollment factors when those paths are in play. It does not get credit for blocking an access step public reporting never established.
Does phishing-proof MFA reverse stolen NVIDIA passwords or NTLM hashes?
No. Phishing-proof MFA does not reverse employee passwords or NTLM hashes already stolen from NVIDIA after a network foothold. Exfiltrating password material or offline hashes from identity or directory stores is post-foothold theft. Device-bound signatures never leave the hardware, but they do not pull secrets back once attackers already hold a dump. Company-wide password changes were containment for material already exposed, not proof that a login factor failed on day one.
Can device-bound MFA stop pass-the-hash after the NVIDIA hash set circulated?
No. Device-bound MFA does not invalidate offline NTLM hashes or undo pass-the-hash style replay after those secrets are already in attacker hands. Circulation of roughly 71,335 NTLM hashes is reusable credential material for post-foothold movement, not a live cloud session cookie from a proxied login. Fresh interactive access still needs enrolled hardware under a passwordless model, but already-stolen hashes remain a residual identity-store and rotation problem until they are worthless in your environment.
What prevention story still applies to workforce identity after a hash dump?
Prevention still matters for future interactive paths: remove transferable passwords and OTP-style factors so the next campaign cannot coach a fake login or harvest a reusable secret at sign-in. That is the prevention focus, not detection boundary. It is not a claim that MFA 2.0 would have erased NVIDIA’s 2022 dump. After foothold, defenders still need store hardening, hash and password rotation, endpoint control, and revoke hygiene. Malware or internal theft after a legitimate session is a harder, separate problem from stopping a phishable login.
Should CISOs treat Microsoft DEV-0537 as NVIDIA’s access method?
No. Microsoft’s DEV-0537 tracking of Lapsus$ group techniques is adjacent actor context, not documented proof of how NVIDIA was entered. Do not import MFA fatigue, helpdesk resets, or AiTM phishing into this breach unless a primary source ties them to NVIDIA specifically. Public reporting does not establish those methods for this incident. Keep group TTP libraries separate from the facts NVIDIA confirmed.
