BBC NewsBorrowing was £17.4bn last month, the second highest October figure since monthly records began in 1993.
Christopher Jackson
There is something almost impossible to picture about a theft of $6.3 billion. We can imagine a stolen wallet, a ransacked office, even a bank vault emptied overnight. But billions disappearing through a series of digital instructions belong to a different order of vulnerability. The money moves faster than the institution can explain what has happened.
The attack on Binance on 29 October has brought that vulnerability into sharp focus. The exchange reported losses of approximately $6.3 billion from its hot wallets, which are connected to the internet, and committed to covering the stolen funds. Its initial investigation pointed towards a compromised laptop. Subsequent enquiries uncovered further breach points, and Binance said it was still establishing the full sequence of events. It also reported no evidence that wallet private keys had been leaked.
For Stephen Alexander, President and CEO of F1R3FLY Industries, the incident raises a question which extends far beyond cryptocurrency: how much power should any one compromised part of an organisation be able to exercise?
In his written response to the attack, Alexander puts his diagnosis bluntly: “What failed was authority.”
That is a useful word to pause over. We tend to describe cybersecurity in terms of keeping people out. We install protections, train staff and hope that the person seeking access is who they claim to be. Alexander’s emphasis falls on the permissions behind the door: what a device or credential allows its holder to do, and how far that authority extends.
His concern is “one credential, one device or one service account, with access to far more than it should ever need”.
The final technical account of Binance’s breach will matter. An evolving investigation cannot yet establish every weakness an attacker exploited. But the broader question Alexander poses is one that any employer can ask now. If an employee’s machine falls into the wrong hands, what else falls with it?
F1R3FLY’s answer is an architecture based on capabilities: narrowly defined permissions to perform particular operations. Alexander describes the principle in direct terms. “F1R3FLY does not rely on identity to grant authority. Every action requires its own unforgeable key, issued for that action alone.”
Think of the difference between a pass admitting someone to a building and permission to open a particular cupboard for a particular task. In Alexander’s account, the authority needed to do one job should not quietly become authority to do another.
“An engineer’s laptop carries keys for that engineer’s work, not a route to systems that move value,” he explains.
This is where the argument becomes relevant to people who have never owned a cryptocurrency. A hospital holds patient records; a retailer holds customer information; a professional services firm holds confidential documents. In each case, organisations must decide how much access a particular job requires, and what prevents that access from being extended or misused.
For financial transactions, Alexander says, the restrictions can be more specific still. “Withdrawal authority can be limited by amount, destination and time, and can require several independent holders to approve before anything moves.”
The purpose is to contain the consequences of compromise. A stolen permission should have a ceiling on what it can achieve. In the model Alexander describes, an attacker cannot simply turn possession of one credential into unrestricted access to the wider organisation.
“An intruder holding one key reaches one record or one action,” he says. “There is no bulk transfer and no path across the estate.”
Alexander also emphasises the way transactions complete and the records they leave behind. “Transactions settle in full or not at all, and every action and attempted action is finalised on a record that cannot be altered.”
For an organisation recovering from an incident, knowing what was attempted as well as what succeeded can be crucial. Accountability requires a record that people can trust.
How far has the company taken these ideas into practice? Alexander explains that a gold-backed token already runs in production on F1R3FLY, and that no successful breach of its capability-based security model has been recorded to date. That is the company’s account of its experience, rather than a guarantee about future attacks. His own qualification is worth hearing: “No architecture makes laptops immune, and people will always be targeted.”
For employers, this is perhaps the most constructive part of his argument. Staff training matters, but a resilient organisation must also think about what happens when someone is deceived. The design of a system should help prevent an individual compromise from becoming an institutional catastrophe.
For young people entering technology, it is a reminder that good engineering involves judgement about responsibility as well as ingenuity. Who needs this permission? For how long? What happens if it is stolen? Those apparently modest questions can have extraordinary financial and human consequences.
Alexander’s closing formulation brings the discussion back to the scale of the Binance loss: “Architecture decides whether a stolen laptop costs one transaction or an exchange’s reserves.”
The challenge for business leaders is to know which possibility their own systems allow.
