When a team tells me something would be quicker if its developers had more access to production, I understand the argument. It probably would be.

But is it $6 billion faster?

That is the question I found myself asking after the reports about Binance. Not because we already know every detail of the attack. We do not. But because the possibility of a compromised work laptop becoming a route to financial transactions should make every board ask what stands between an ordinary working day and a catastrophic loss.

I helped set up a neobank which became a regulated retail bank. One lesson from that experience stays with me: when you are looking after other people's money, the speed of development is not the only thing you are managing.

You are also managing what one mistake, one compromised device or one misused identity is allowed to do.

What has actually been reported?

Binance's initial incident update put the estimated impact at about US$6.3 billion. It described a possible compromise of a DevOps engineer's laptop, leading to access to a service container and unauthorised withdrawal transactions. This was a preliminary account, not a completed investigation.

A subsequent Binance News update said investigators had identified further entry points and had found no evidence of leaked wallet private keys. The company also said the attack could not have been completed from a single machine, and that one engineer's permissions did not allow a simple immediate transfer of the funds. That remains the company's account, not an independently completed forensic finding.

We do not yet know whether a convenience-driven access exception contributed. Associated Press also reported the company's statements about further breach points, no evidence of leaked keys and its pledge to cover losses.

TRM Labs' own analysis estimated that about US$6.36 billion moved out across ten blockchains on 29 October 2026. It says most of that movement occurred in about 20 minutes. It described this as the largest cryptocurrency theft on record. Its technical assessment points towards compromised hot-wallet signing infrastructure: the ability to obtain signatures for attacker-chosen transactions. That is an investigator's assessment, not Binance's final root-cause report.

Those distinctions matter. We cannot turn an initial laptop report into a finding that an engineer kept billions of dollars' worth of private keys on that laptop. Nor should we turn a gross incident estimate into a final unrecovered loss. Freezing assets, returning them and reimbursing customers are different stages.

This article is checked against the information available on 30 October 2026. The investigation may change the account. My argument is about the controls financial institutions should test, not a claim to have completed the Binance investigation myself.

The dangerous thing is the authority

Imagine that a private key is kept inside a protected signing service. A user cannot download it. That is useful protection.

Now imagine that the same user's compromised session can ask that service to approve any transaction it likes.

The attacker may not need to steal the key. It may be enough to persuade the legitimate system to use it.

That is an illustrative failure mode, not a reconstruction of Binance's internal architecture. But it explains why I would ask a different question from simply, Where are the secrets stored?

Who, or what, can exercise the authority those secrets represent?

A vault, hardware security module or multi-party signing arrangement can form part of the answer. None should be treated as a substitute for controlling the requests, policies and identities around it. Moving a secret from a laptop to a server is not enough if an ordinary laptop session can still exercise unrestricted production authority.

For institutional custody, my starting point would be no routine storage of production signing secrets on general-purpose development laptops. Then I would examine the whole route by which a person or workload can cause money to move.

DevOps is not the permission model

I understand the attraction of bringing development and operations closer together. People building a system benefit from understanding how it behaves in use. People operating it need an effective route back to the people who can fix it.

That does not mean every developer's everyday machine should have standing access to the live estate.

The important separation is between environments, identities and powers. A team name on an organisation chart does not provide it. Neither does creating two teams if the same account can override both.

NIST's Secure Software Development Framework addresses this directly. Its PO.5 practices cover separating and protecting development environments, limiting their connections to production, hardening development endpoints and controlling privileged access. Its implementation examples include separate endpoints for development and production tasks. These are security recommendations, not a universal legal requirement for one staffing structure.

My expectation in a high-consequence financial system would be that an ordinary development session cannot administer production or authorise customer-money movements. Fixes should move through a controlled release process, with independent checks proportionate to what could go wrong.

Operations can provide diagnostic evidence. Developers can reproduce faults using suitably protected or sanitised information. Where genuine production access is necessary, provide it through an approved privileged route, for the task and time required, with an audit trail.

Emergency access needs a designed exception, not an undocumented shortcut. Who authorises it? What can it reach? When does it expire? Who checks what happened afterwards?

That is compatible with engineers working closely together. Collaboration and unrestricted access are not the same thing.

Secure the machine, then contain what it can reach

Of course we need to secure the laptop. Keep supported software patched. Use managed devices, appropriate endpoint protection and phishing-resistant multi-factor authentication. Protect credentials. Remove unnecessary administrator rights.

But a financial institution's plan cannot end with hoping every employee avoids every sufficiently convincing attack.

The National Cyber Security Centre's guidance on lateral movement explains why internal controls matter after an attacker gains an initial foothold. It recommends protecting credentials and separating everyday activity from privileged administration, including the devices used where possible.

For the most sensitive work, I would want a dedicated privileged workstation or an equivalently controlled administration environment. Not the same everyday session used for email, browsing, development experiments and arbitrary downloaded code.

The NCSC's administration-tier guidance makes another useful distinction: access should reflect the damage a compromised account could cause. A development sandbox and a system which controls signing policy are not equivalent risks.

This is also what I mean by zero trust. Not that we think our colleagues are dishonest, and not that buying a product makes a network safe. NIST's zero-trust architecture does not grant implicit trust merely because a device belongs to the company or is connected to a particular network. Access to the resource still needs authentication and authorisation.

When somebody says, But we trust our people, my answer is that we are also protecting those people. A good system should limit what can happen when their account or device is compromised.

Use the same reasoning for service accounts, deployment jobs and AI agents. Giving a bot a human's unrestricted production credential does not make the boundary any stronger.

Protect the route to the money

Four illustrative control boundaries: routine work, controlled privileged access, constrained production and independently verified transaction authority. Protected logs, detection, revocation and recovery span the route. This is not Binance
Illustrative control objectives, not a reconstruction of Binance's systems. The question is what authority can cross each boundary.

Here is the design I would ask a financial organisation to demonstrate. It is a set of questions and control objectives, not a product shopping list or a claim that every item would have prevented this particular attack.

  • Separate routine work from privileged work. Use distinct identities and controlled devices or environments. Give a person or workload only the permissions needed for its task, and remove temporary access when the task ends.
  • Protect the secrets and their callers. Use appropriate managed custody or signing infrastructure. Keep production credentials out of source repositories, development fixtures, logs and ordinary laptop files. Check who can issue requests, change the policy or recover the system.
  • Make important approvals independent. Two approvals do little if one compromised interface can mislead both approvers, or one identity can alter the rule and then approve its own transaction. Verify the destination, value and transaction meaning through appropriately independent controls.
  • Limit cumulative damage. Examine limits per transaction, across a time window and across connected wallets or services. A small per-transaction limit is not much protection if an attacker can repeat the transaction indefinitely. Protect the authority to change those limits too.
  • Contain the compromise. Design boundaries so that access to one service does not automatically unlock the next. Test whether separation between environments, wallet tiers and critical control systems works in practice.
  • Detect, stop and recover. Retain protected audit evidence, watch for abnormal activity, and rehearse how to revoke access or suspend unsafe actions. Recovery must include restoring trustworthy identities and policies, not just bringing a server back online.

The exact implementation will depend on the institution, its assets and its risks. Independent review should challenge whether these controls are genuinely independent and whether an attacker can bypass their combined effect.

That is the thing. A firewall between networks is useful, but the larger question is where the authority stops.

This is where regulation earns its keep

Regulation is not always a bad thing. Sometimes it makes an organisation confront problems which would otherwise remain inconvenient questions at the end of a project meeting.

The FCA's operational-resilience framework requires firms within its scope to identify important business services, set impact tolerances, map dependencies and test their ability to withstand disruption. The implementation deadline for the established requirements was 31 March 2025. This is more than asking whether a website is currently online.

The PRA's SS2/21 expectations for outsourcing and third-party risk discuss encryption and key management, stronger controls for higher-risk identities, activity logging and incident response. Their scope is PRA-regulated firms and relevant arrangements; they are not proof that Binance was subject to, or breached, those particular expectations.

ISO/IEC 27001 provides a framework for an information-security management system and managing risk. I regard that sort of discipline as a foundation, not a guarantee that a company cannot be breached. A certificate cannot answer every question about a live transaction path.

There is a legal distinction here too. A crypto exchange is not automatically a licensed bank. The FCA explains that registration under the money-laundering regime is not the same thing as an endorsement or a promise of Financial Services Compensation Scheme protection.

The UK regime is also changing. As checked on 30 October 2026, the FCA says the new cryptoasset regulatory regime is expected to commence on 25 October 2027. Rules published for that regime should not be presented as if every requirement already applies to every crypto business today. The entity, activity, permissions and commencement dates matter.

My argument is a standard of responsibility, not a claim that all exchanges already have identical legal obligations to banks. If you are entrusted with assets on this scale, customers deserve security and governance appropriate to the consequences.

What I would ask at the next board meeting

I would ask for evidence, not just assurances that we have a good security team.

  1. If an engineer's normal laptop is compromised tomorrow, what production systems could the attacker reach, directly or through another identity?
  2. Can one person, account or service change code, change access, weaken transaction limits and then cause money to move? Which independent control prevents that?
  3. What is the maximum cumulative exposure before a separate control stops further action? Does the answer include repeated transactions and multiple connected services?
  4. Can privileged activity be detected and investigated if the operational system is compromised? Who can alter or delete that evidence?
  5. When did we last demonstrate that expired access was removed, emergency access was reviewed and a simulated compromise could be contained?
  6. Which exceptions have we accepted for convenience, who owns those decisions, and when will they be reviewed?

Test those questions in an authorised, controlled exercise with independent challenge. Do not improvise an experiment against live customer funds.

Monitoring also needs governance: appropriate purpose, access controls, retention and privacy safeguards. The answer is accountable security logging, not unlimited surveillance of employees.

A promise to pay is not a security architecture

I welcome a commitment to protect customers from losses. In a later 30 October update, Binance said it had reserved more than US$6.34 billion of company funds and begun restoring affected assets to users.

That is relevant reported progress, not just the original pledge. It remains a company report, rather than independently audited proof of funding or completed reimbursement. Restoring customers' assets and fixing the route by which the incident happened are different jobs; neither should be confused with the other.

Nor does an attack, by itself, prove that every part of a company's governance is rotten. The investigation needs to establish what actually happened. Engineers deserve that distinction too.

The board still owns the questions about design, risk appetite, accepted exceptions and the resources available to enforce the boundaries. Those are governance questions, even when the first visible symptom appears on somebody's laptop.

We have established security principles for this class of risk. We have not solved security permanently, and regulated banks are not immune. But we do not need to invent the idea of constrained privilege or controlled production access after every incident.

Some controls take time. They require people, maintenance, testing and the occasional refusal to take a convenient shortcut. Good automation can make that discipline easier to operate; it should not quietly remove it.

So yes, broader access might make the next task faster.

But is it $6 billion faster?

That is not a claim that one rule would certainly have saved that amount. It is the question I want leaders to ask before the next exception: what could this convenience expose, and where will the damage stop?

Sources and notes

Research checked on 30 October 2026. The Binance investigation is ongoing. Company statements, external investigators' assessments and my recommendations are kept distinct. This is security and governance commentary, not a forensic conclusion, a finding of regulatory breach or legal advice. My banking experience comes from my own account.

  1. Binance Announcement, Security Incident Update, 30 October 2026, and Binance News's multi-entry update. The initial announcement was available as substantial indexed official text; direct retrieval failed. The subsequent update was later opened and read through the official news feed. AP's initial report and its 30 October follow-up also report the company account; this is not independent forensic validation. The reserve and restoration update was also opened and read. It is company evidence, not an independent audit or a completed-payout receipt.
  2. TRM Labs, North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History. The article displays 29 October 2026; its official listing displays 30 October. Figures are described as a snapshot at 00:30 UTC on 30 October. After an initial direct-fetch failure, the indexed article was read and the listing then provided access to the parsed article. TRM's amount, record comparison and signing-system assessment remain attributed investigator findings, not a final company or court conclusion.
  3. NIST SP 800-218, Secure Software Development Framework v1.1, February 2022, PO.5.1 and PO.5.2, PDF pages 17-18. Separate environments, constrained connections, privileged-access monitoring and hardened endpoints. Informative implementation examples are not UK legislation.
  4. NCSC, Preventing Lateral Movement, and Risk manage administration using tiers. General defensive guidance, not evidence of Binance's exact access architecture.
  5. NIST SP 800-207, Zero Trust Architecture, August 2020. Resource-focused authentication and authorisation without implicit trust based on network location or ownership.
  6. FCA, Operational resilience, page updated 15 September 2026. Requirements apply to firms in scope. This article does not decide which particular Binance entity or activity falls within a UK rule.
  7. PRA SS2/21 version page and the November 2024 version, especially paragraphs 7.10-7.12. This is the currently effective version identified on the Bank's page. The March 2026 revision is marked for 18 March 2027, not treated here as already effective.
  8. ISO's public ISO/IEC 27001:2022 overview. The public explanation was read; no claim is made to have inspected the complete paid standard or a particular company's certificate, scope or implementation.
  9. FCA, Cryptoassets: AML/CTF regime, and A new regime for cryptoasset regulation, updated 30 September 2026. Registration, authorisation and customer-protection coverage remain different questions; the new regime's stated commencement is prospective.