The Binance breach shows the gap: a key proves a device, not a person

In an update posted on 30 October 2026, Binance said its initial investigation suggests the incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to reach a service container and submit unauthorized withdrawal transactions. Binance puts the estimated impact at around $6.3 billion, says about $3 billion has been frozen on-chain with blockchain partners, and says it found no evidence that any wallet private key leaked. It will cover the losses from its SAFU fund and its own money, it paused deposits and withdrawals, and it promised a full technical post-mortem^[1].

Later the same day Binance told Reuters the incident "stems from multiple factors" and that its team is still tracing the full attack path through the compromised computer^[2]. On-chain analysts at TRM Labs counted about $6.36 billion leaving Binance wallets on ten blockchains, most of it in about 20 minutes, and their reading is that the attacker got Binance's hot-wallet signing system to sign transactions of the attacker's choosing^[3]. That is TRM's assessment, not Binance's root cause. TRM attributes the theft to North Korea's TraderTraitor unit with high confidence^[3], and Reuters reports that Chainalysis also points to North Korea^[2].

That post-mortem will tell us exactly what happened, and until then nobody outside Binance should pretend to know. But the shape of what they described is already worth studying, because it is not new. The attacker did not need to break the cryptography. They did not need the private keys. They needed one trusted machine, and from there, if TRM's reading holds, the system did what trusted systems do: it signed.

This is the moment authentication stops being a login problem. The question is no longer only "Is this the right device?" It is "Is a real, verified human approving this action, right now?" That is what this post is about: why passkeys and hardware keys alone don't answer it, what does, and how companies are already building it.

The pattern: the way in is a person's machine

Look at the largest crypto losses of the last few years and the entry point is rarely the vault. It is a person, and the machine or account that person trusts.

• Bybit, February 2025, about $1.5 billion. The FBI attributed it to North Korea's TraderTraitor^[4]. The preliminary findings published by Safe{Wallet}, from Sygnia and Mandiant's review, traced it to a compromised developer workstation and that developer's AWS session token^[5].
• Ronin, March 2022, more than $540 million. A senior engineer opened a fake job offer, and spyware got into the network from there^[6].
• DMM Bitcoin, May 2024, $308 million. A fake recruiter sent an employee of its wallet software provider a "pre-employment test". The attackers later used stolen session cookies to impersonate that employee^[7].
• Radiant Capital, October 2024. Malware on several developers' devices showed harmless transactions on screen while malicious ones were signed in the background, so hardware wallets approved what the screen hid. Radiant's own conclusion: hardware wallets and careful human review "can be circumvented"^[8].
• Coinbase, May 2025. Criminals paid support contractors and employees outside the US to pull customer data. No passwords or keys were involved^[9].
• Retool, 2023. An SMS phishing message, then a phone call with a deepfaked voice of a real employee, got one more MFA code^[10].

Each of these companies had real security controls. The attackers didn't beat those controls head-on. What the attacker took over was an identity the system already trusted: a laptop, a session, a support agent, a signing step. Once inside that trust, every downstream check said yes.

Passkeys are good. They answer a different question.

I want to be clear, because this gets misread: passkeys and hardware security keys are a big step forward and every company should use them. They are phishing-resistant by design: a passkey is bound to the website's origin, so a fake login page can't collect it, and there is no shared secret to leak from a database. NIST's newest guidelines make a phishing-resistant authenticator mandatory at the highest assurance level^[11]. If your employees still log in with passwords and SMS codes, fix that first.

But look at what a passkey actually proves to the server. It proves that someone holding an authenticator for that account completed a cryptographic challenge, and that the authenticator says a user verification happened (a fingerprint, a face or a PIN). That verification happens locally, on the device; the server gets a flag that says it happened^[11]. The server never sees who touched the sensor. It learns "this key is here and was unlocked", not "Ana from treasury is here".

That difference matters the moment the attacker stops trying to log in and starts using a login that already happened. In practice, attackers don't break passkeys. They go around them:

1. Stolen sessions. Infostealer malware takes the session cookie or token after a perfectly valid, phishing-resistant login, and replays it. Microsoft's own playbook describes token theft as working "even if that user has satisfied multifactor authentication"^[12]. Google's answer is Device Bound Session Credentials, which ties a session to a key on the device so a stolen cookie is useless elsewhere. Google's own framing is that this forces attackers to work locally on the device^[13], and a compromised work laptop is exactly that.
2. Cloud account takeover. A synced passkey lives in a cloud account or password manager. It is exactly as strong as that account and its own recovery flow. That is why NIST allows synced passkeys only up to its middle assurance level, never the highest one^[11].
3. Downgrade. If the account still accepts a weaker fallback, attackers push the login to the fallback. In 2025, Proofpoint researchers built a phishing kit that pushes FIDO-protected sign-ins down to weaker methods. They had not seen it used in the wild yet, which is exactly when to close the gap^[14].
4. Account recovery. "Forgot password", "lost my key" and the help desk issue fresh credentials. CISA warns that groups like Scattered Spider talk IT help desks into resetting passwords and MFA tokens^[15].
5. A trusted device in the wrong hands. An unlocked, compromised laptop acts with its owner's authority. Every device check passes, because it is the right device.

None of these is fixed by a stronger key. A hardware key plugged into a compromised laptop is still plugged into a compromised laptop. What fixes them is moving the check from "the right device logged in this morning" to "the right human approves this specific action, now".

Bind the action to a verified human

Here is the thesis, plainly. Logins will keep getting stronger, and that is good. But for actions that can't be undone, a login is the wrong place to stop. Every high-risk action should be bound to a live, verified human at the moment it happens.

What counts as high-risk depends on the business, but the list is usually short:

• a withdrawal or payout above a limit, or to a new destination,
• a new admin, a new role or a permission change,
• a new device, a new API key, or a change to an existing one,
• a password reset, a passkey reset or an MFA change,
• a production deploy, a key ceremony or a change to signing policy.

For each of these, the step-up asks three things together. Is the device and network what we expect for this person? Is a real, live human in front of the camera, not a replay, a mask, a deepfake or a video injected through a virtual camera? And is it the same person whose identity was verified at onboarding? If all three hold, the action goes through in seconds. If any fails, the action does not go through, and your team sees why.

This is what Didit's biometric authentication does. It takes one selfie, runs liveness on it, matches the face to the one stored when the person was verified (the approved liveness face, the ePassport chip photo or the ID portrait), and checks it against your face blocklist. Presentation attacks such as masks, screen replays and deepfake-class spoofs are declined automatically^[16], and the liveness check flags virtual cameras and injected camera feeds^[17]. Our device and IP analysis runs in the same session: it recognises the device even after storage is cleared, flags VPNs, proxies, Tor and data center IPs, compares the live IP with the one you expected, and catches impossible travel^[18]. Didit Networks then links accounts that share a face, a device, an IP or a document, so one person behind many identities shows up as one case, not twenty alerts^[19]. And in Didit Authentication, a step-up rule sits in front of the sensitive action itself and never fails open: if verification is unavailable, the action stays blocked^[20]. For someone who genuinely can't complete a selfie, the fallback should be a second verified approver, never a help desk that can be talked into it.

The difference from a hardware key is not that it is "stronger". It answers a different question. A key proves possession. A live face matched to a verified identity proves presence and identity. You want both.

Two things make this work in practice, and both are easy to get wrong.

First, the approval has to be bound to what will actually happen, not to what the requesting machine says will happen. Radiant learned this the hard way: the screen showed one transaction and the wallet signed another. So the approver should see the real amount, destination and network on their own phone, from your backend, and the system should execute exactly what was approved, nothing else. Approving "a withdrawal" is not enough. Approving "this amount, to this address, on this chain" is.

Second, this does not mean a selfie in front of every hot-wallet signature. Exchanges sign thousands of transactions a day, and automated signing needs its own controls: limits, policy engines, hardware security modules, separation by wallet tier. The human check belongs where a person can change that machinery: who raises a limit, who adds a destination, who changes the signing policy, who approves the exception above the threshold. If one compromised laptop can change any of those without a verified human saying yes, that is the gap.

For the very largest actions, add a second human. Two verified approvers, each passing their own biometric check on their own device, is very hard to fake from one compromised laptop. The approver's phone is a device too, which is why the check runs on the server with liveness and injection detection and is read with device and network signals. That is the part of this story that stays with me: from one machine, an attacker was able to get withdrawals submitted and, by TRM's reading, signed. Binance already asks its customers for a face check before some withdrawals^[21]. The same principle belongs inside every company, on the path from an engineer's laptop to the systems that move money. The design goal is that no single machine, and no single person, can move that much money alone.

"Forgot password" is the real front door

Most companies spend their security budget on login and then let anyone who controls an inbox or a SIM card reset the account. Email links get forwarded, SIMs get swapped, and help desks get talked into resets by people who have done their homework on the employee they are pretending to be.

This is where we see the fastest adoption. Many companies, including large enterprises, build their "forgot password", lost-device and MFA-reset flows on Didit: device and IP checks first, then one live selfie matched against the face verified at onboarding, then new credentials with every old session revoked. The honest user gets back in quickly, without calling anyone. The person with the stolen inbox gets nothing, because they don't have the face. The same flow protects a help desk: the agent doesn't have to judge a voice on the phone, they send a verification link and act on the result.

This is an enterprise problem, not only a crypto one

It is easy to read this as a crypto story. It isn't. Every company has a handful of people who can move money, change permissions, read customer data or push code to production. Those are the accounts attackers want, and those are the actions that deserve a human check.

It also starts before day one. North Korean IT workers have been getting hired into Western companies under false or borrowed identities, and getting remote access the normal way, through onboarding. The US Justice Department says more than 70 US companies were hit, and in one operation it seized about 187 devices from so-called laptop farms^[22]. If you don't verify who you hired, a perfect login only proves the impostor logs in perfectly. Verify the person when they join, keep that verified face as the reference, and check against it whenever they do something that matters. Do it with the person's consent and a retention policy you control, and use that face for nothing else.

And it is about to get harder. Gartner predicted that by 2026, 30% of enterprises would consider identity verification and authentication solutions unreliable in isolation because of deepfakes, after injection attacks rose 200% in 2023^[23]. That is the right instinct: a face check has to come with liveness, injection detection and context, never alone. Meanwhile, AI agents are starting to act inside company systems on people's behalf. When an agent asks to move money or change access, the question is the same: which verified human approved this? If the answer is "a token that was valid", that is not an answer.

Where this is going

My bet is simple. Within a few years, binding important internet actions to a verified human will be as normal as HTTPS. A withdrawal over your limit will ask for your face the way a card payment asks for a PIN. Thailand's central bank announced in 2023 that high-value mobile banking transfers would require a biometric scan^[24]. Exchanges will ask for it before large withdrawals. Enterprises will ask for it before a role change, a key rotation or a production deploy. In the EU, the payment rules provisionally agreed in November 2025 target scams where fraudsters impersonate a customer's bank, and make payment providers liable when they don't use the required fraud-prevention tools^[25].

Hardware keys won't go away; they will sit next to biometrics. The key proves the device, the face proves the person, the network and history prove the context, and for the biggest actions a second person proves it wasn't one bad day. No single layer is enough, and nothing makes fraud impossible. The goal is to make one compromised laptop worth very little.

If you run security for a team that can move money or change access, here is where I would start this week:

1. List the ten actions in your company that can't be undone. Put a step-up in front of each one.
2. Verify every person with access to those actions once, properly, with document, NFC chip where available, and liveness. Keep that verified face as the reference, with their consent.
3. Rebuild "forgot password", MFA reset and lost-device recovery around a live selfie matched to that reference, not an inbox.
4. Use passkeys or hardware keys for login everywhere, and remove the weak fallbacks.
5. Require two verified humans for the largest withdrawals, key changes and permission grants.
6. Read device, IP and network signals on every one of those actions, and block what doesn't fit.

If you want to see how this is set up on Didit, start at business.didit.me or send me a message. And to the Binance team: good luck with the recovery. Covering every user from your own funds is the right call.

Frequently asked questions

What did Binance disclose about the incident?

Binance said its initial investigation suggests a compromised DevOps engineer's laptop let an attacker reach a service container and submit unauthorized withdrawals, with an estimated impact of around $6.3 billion and about $3 billion frozen on-chain so far. It said it found no evidence of a private key leak, that SAFU and company funds will cover losses, and that a technical post-mortem will follow. The root cause is still being investigated.

Would passkeys or a YubiKey have prevented it?

We don't know the details yet, and it would be wrong to guess. What we can say is that passkeys and hardware keys protect the login. An attacker working from an already trusted machine or session doesn't need to log in again, so a stronger login alone doesn't stop actions taken from inside that trust.

Are passkeys hackable?

The cryptography is very strong and passkeys resist phishing. Accounts protected by passkeys can still be taken over around them: through stolen session tokens after login, through the cloud account that syncs the passkey, through weaker fallback methods, through account recovery, or through a compromised device that is already trusted.

What is biometric authorization?

It is a check at the moment of a sensitive action, not at login: the person takes a live selfie, the system confirms it is a real person present right now and that the face matches the identity verified at onboarding, and only then releases the action.

How is that different from face unlock on a phone?

Face unlock on a phone unlocks the device locally, and the service only learns that the device was unlocked. Biometric authentication with Didit checks liveness and matches the face against the verified identity on the server side, so the service learns which verified person approved the action.

Can deepfakes beat a selfie check?

Deepfakes and injected camera streams are a real and growing attack. That is why the selfie runs liveness and presentation-attack detection, and why it is read together with device, network and account history instead of on its own.

Which actions should require a step-up?

Anything you can't undo: large or new-destination withdrawals and payouts, new admins and permission changes, new devices and API keys, password, passkey and MFA resets, production deploys and signing policy changes.

Does this add friction for users and employees?

Very little when it is placed at the right actions. A selfie step-up takes seconds, and it only appears for the handful of actions that matter. Account recovery gets faster, because nobody has to wait on a help desk.

Does this replace hardware security keys?

No. Keep hardware keys and passkeys for login. Biometric authorization adds the layers they don't cover: presence and identity at the moment of action.

How do companies build this on Didit?

Verify the person once with ID verification and liveness, then use biometric authentication with device and IP analysis on the sensitive actions and in account recovery. With Didit Authentication, step-up rules sit in front of those actions directly. Everything is available through the API and the console.

Sources

1. Binance, "Security Incident Update", 30 Oct 2026. www.binance.com
2. Reuters, report on the Binance security incident and the Tether and Circle freezes, 30 Oct 2026. www.reuters.com
3. TRM Labs, "North Korea steals USD 6.36 billion from Binance in the largest hack in history", blog, read 30 Oct 2026.
4. FBI, "North Korea Responsible for $1.5 Billion Bybit Hack", PSA I-022625-PSA, 26 Feb 2025. www.fbi.gov
5. Sygnia, investigation of the Bybit hack, 2025. www.sygnia.co
6. The Block, "How a fake job offer took down the world's most popular crypto game", 6 Jul 2022. www.theblock.co
7. FBI, DC3 and NPA, "Identification of North Korean cyber actors tracked as TraderTraitor responsible for theft of $308 million from Bitcoin.DMM.com", 23 Dec 2024. www.fbi.gov
8. Radiant Capital, "Radiant Capital incident update", 6 Dec 2024. medium.com
9. Coinbase Global, Form 8-K, US SEC, 14 May 2025. www.sec.gov
10. Retool, "When MFA isn't actually MFA", 13 Sep 2023. retool.com
11. NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, July 2025. pages.nist.gov
12. Microsoft Learn, "Token theft playbook". learn.microsoft.com
13. Chromium Blog, "Fighting cookie theft using device bound sessions", April 2024. blog.chromium.org
14. Proofpoint, "Don't phish-let me down: FIDO authentication downgrade", 12 Aug 2025. www.proofpoint.com
15. CISA, Advisory AA23-320A, Scattered Spider, 16 Nov 2023. www.cisa.gov
16. Didit docs, Biometric Authentication. docs.didit.me
17. Didit docs, Liveness warnings. docs.didit.me
18. Didit docs, Device and IP Analysis. docs.didit.me
19. Didit docs, Networks. docs.didit.me
20. Didit docs, Authentication API, Create a step-up. docs.didit.me
21. Binance, FAQ on face verification. www.binance.com
22. US Department of Justice, coordinated actions against North Korean remote IT worker schemes, 13 Oct 2026. www.justice.gov
23. Gartner, "Gartner predicts 30% of enterprises will consider identity verification and authentication solutions unreliable in isolation due to deepfakes by 2026", 1 Feb 2024. www.gartner.com
24. US-ASEAN Business Council, "Bank of Thailand introduces new security measures to mitigate financial fraud", 4 Apr 2023. www.usasean.org
25. Council of the EU, "Payment services: Council and Parliament agree to step up the fight against fraud", 27 Nov 2025. www.consilium.europa.eu

Didit docs for every step

• Biometric authentication
• Biometric authentication report
• Device and IP analysis
• Networks
• Blocklists
• Didit Authentication overview
• Step-up API