A single phone call was enough to turn a standard employee password into valid internal access at Uber. The attacker, affiliated with the Lapsus$ group, obtained the credential through social engineering and then persuaded the employee to approve an MFA prompt or share a one-time code. With the resulting session token, the intruder moved into corporate systems, accessed the company Slack workspace, and began extracting data.
The incident hinged on two extractable components: a reusable password and an MFA factor that could be harvested in real time. Once the token was issued, every downstream system treated the activity as legitimate because the token carried no record of its origin.
Credential Reuse and the Limits of Session Validation
Credentials remain the leading initial access vector according to multiple years of breach data. In this case the MFA mechanism still required either a human decision or a short-lived value that an attacker could obtain while the victim stayed on the call. After approval, the issued session token looked identical to any other token created through normal means.
Standard MFA implementations evaluate only the moment of login. They do not constrain registration, device enrollment, authorization rules, or token lifetime in a way that prevents later misuse. When any of those steps depends on something an attacker can coerce or extract, the resulting session becomes indistinguishable from ordinary use.
Device-Bound Credentials Remove Extractable Secrets
MFA 2.0 replaces every identity step with public-key credentials bound to hardware. During registration the user’s device generates a private key that never leaves the secure enclave or TPM. No password store exists to compromise. Each subsequent authentication signs a fresh challenge that cannot be phished or replayed. The same key pair governs authorization and decommissioning, eliminating any phishable hand-off across the full identity lifecycle.
MFA 2.0 is phish-proof, passwordless authentication built on public-key cryptography—the same technology used in Apple Pay and Google Pay. It uses device-bound credentials with no central credential database and requires only same-device authentication; no second device is needed. Because the model is prevention-focused, the attack cannot occur in the first place: there are simply no reusable secrets for an attacker to obtain.
This approach extends beyond strengthening a single authentication ceremony. It applies the public-key model consistently to registration, onboarding, authorization, and token issuance, closing the social-engineering paths that remain open when only the login step is hardened.
Hardware Protection Without Additional Tokens
Even if an attacker obtained the laptop, device-bound keys stay protected by the platform’s secure enclave or TPM. Extraction would require breaking hardware-backed cryptography rather than persuading an employee. The credential resides on the employee’s existing corporate device; no extra hardware token or OTP application is required.
Implementations built on this architecture keep the private key exclusively on the device. The absence of extractable secrets therefore stops the attack chain before any session token can be issued.
