Is society engineered to be vulnerable?
I recently read that Apple had released a firmware update for a charging cable. A cable! I spend a fair amount of time playing with technology, but apparently I still underestimate how much software there is in a piece of wire.
It was an amusing place to start thinking about a question that has come up since my previous post on AI safety: are we engineering society to be vulnerable?
By “engineering”, I mean the choices we make about how things work. Using the same software everywhere makes maintenance easier. Putting services with a large provider gives us access to expertise we couldn’t afford ourselves. Connecting equipment lets us fix it remotely. I can see good reasons for all of these, but put them together and we can end up with quite unrelated services depending on the same things. Nobody needs to have intended that outcome.
And over ten days in October 2026, we’ve had rather less amusing examples: spoiled food in French supermarkets, disrupted deliveries to Dutch shops, banking problems during a Google Cloud outage, and websites taken offline because of flaws in PHP.
So how do we get from software in a cable to people unable to pay for their shopping?
What happened to the MagSafe cable
The cable in question was Apple’s USB-C to MagSafe 3. On 5 October, MacRumors reported that new firmware had been released, installing automatically when the cable was connected to a Mac and power adapter. Apple doesn’t publish release notes for these updates, so quite what needed changing remains a mystery.
Firmware is simply software running inside a piece of hardware, controlling its behaviour. Some modern cables contain electronics that tell the equipment at either end what they can do. Infineon, for example, makes USB-C controllers with their own processor and memory. So there’s a small computer in something I still tend to think of as a connector.
Of course, being able to update it is useful. I’d much rather fix a cable than throw it away. But it does mean that using it depends on software behaving as expected, and fixing it may depend on the manufacturer still supporting it.
I’m used to thinking about the software on my laptop. I probably ought to think a bit more about the software in everything I’ve plugged into it.
The drives that could fail together
An older firmware problem shows why this matters beyond having yet another thing to update. In November 2019, a defect was disclosed in certain HPE enterprise solid-state drives, or SSDs—the devices storing data in servers. After 32,768 hours of operation, roughly three years and nine months, affected drives would fail. Neither the drive nor its data could then be recovered. You had to install the corrected firmware before reaching that point, as the NHS Digital alert explained.
The particularly uncomfortable detail appears in HPE’s own documentation:
SSDs which were put into service at the same time will likely fail nearly simultaneously.
Imagine you’ve bought several of these drives and installed them together. You’ve allowed for a drive failing, as anyone running a storage system should, and the extra drives will keep things working while you replace it. Except that when the first one reaches the limit, the others are getting there too. They’ve all been running for much the same length of time.
You did the sensible thing and bought redundancy. Unfortunately, you also bought several copies of the same mistake.
There’s no network connecting the failures here, and no attacker moving between machines. The drives simply share a fault and the conditions that trigger it. Even a separate copy of the data could have the same problem if it lived on similar affected equipment.
Having more of something only helps if it can still work when the first one stops. Which sounds obvious, until we start looking at what our alternatives actually depend on.
When software trouble reaches the shopping basket
The French fridges
The French supermarket attacks are a particularly unpleasant example. In October, attackers interfered with refrigeration controls across hundreds of shops, and Reuters reported staff throwing away spoiled meat and frozen goods. We tend to picture a cyberattack as something happening to computers. Here, the result was food that could no longer be eaten.
I can see why you’d want remote access to refrigeration equipment. Being able to monitor and adjust it without sending an engineer to every shop is useful. But whoever can reach those controls may also be able to stop the equipment doing its job. CERT-FR confirmed compromises involving several controller families, advising operators to remove public internet exposure, use protected networks for access and update supported equipment.
The precise route into every installation hasn’t been established, so I wouldn’t assume one exploit explains the whole incident. What we do know is that control of the refrigeration was compromised across many shops. And once the food has spoiled, fixing the software doesn’t put it back on the shelf.
The Dutch supermarkets
Meanwhile, a separate incident affected Ahold Delhaize, which owns Albert Heijn in the Netherlands. The group detected malicious activity and took systems offline to protect them. The shops stayed open.
But on 12 October, Albert Heijn’s chief executive told NOS that some distribution centres had stopped working altogether because systems had been switched off. Fresh supplies were affected. Regular store deliveries resumed later that week, although availability still varied between shops and home deliveries were still suspended at that point.
On 21 October, Albert Heijn announced that online ordering was reopening for an initial group of customers, with deliveries due to restart gradually on 23 October. It had roughly a third of its normal delivery capacity available. Getting the systems back online and getting everyone’s shopping to them were still rather different stages of recovery.
This is a slightly different problem. Taking systems offline may be exactly the right response to an attack, but what do you do about the work that depends on them? You can have food, staff, shops and customers, and still struggle to get groceries to people because the software organising the deliveries isn’t available. Planning how to switch something off safely has to include what happens while it stays off.
And then the bank card
On 20 October, Google Cloud reported a power event in a London availability zone, interrupting services with some effects elsewhere in its London region. No attack was needed for this one.
Google’s preliminary incident report, published on 22 October, adds an uncomfortable detail: both the primary and backup programmable controllers failed to initiate the generators’ start and transfer sequence. The batteries keeping the equipment running then ran down. As workloads moved to other zones, they overwhelmed available capacity there, spreading the disruption. The investigation is still under way, so this doesn’t establish that the controllers shared a software fault. But it brings us back to those drives: the backup was there, and still wasn’t able to do its job when needed.
Reuters reported problems with Revolut card payments and ATM withdrawals, alongside disruption at other financial firms and public-sector websites. Revolut reassured customers that their money and data were safe. Good, of course, but that doesn’t help much if you’re at the till and can’t pay.
Google suggested moving affected workloads to another zone or region where feasible. That’s a perfectly reasonable option if you’ve prepared for it and there’s capacity to take the extra work. If you haven’t, moving an application, its data and everything it needs isn’t something you can do while a customer waits. Nor can that customer easily tell whether trying another bank would avoid the same underlying problem.
The software underneath the website
On 21 October, PHP released emergency fixes for two critical vulnerabilities. PHP is used to run websites and applications, and these flaws could let an attacker run code on a server without logging in. The PHP team described a demonstrated attack against Apache’s mod_php configuration that could begin before the website’s own application code even ran. Its wider warning covered other PHP deployments too.
Even the Dutch National Cyber Security Centre temporarily took its own website offline, publishing information through other channels. The Dutch judiciary took some PHP-based sites offline too, while its main website and court portal, which didn’t use PHP, remained available.
These were precautions; taking a site offline doesn’t mean it had been hacked. But the website’s developers didn’t have to make a mistake themselves to inherit an urgent security problem. They were using software that many other people used too.
I think this is the part we underestimate. These incidents have different causes, but in each case the consequences extend well beyond the system first affected. Disrupting several banks doesn’t require a separate attack on each bank. Disrupting food supplies doesn’t require anyone to go near the food. We’ve connected these activities in ways that make a relatively limited failure reach a surprising number of people.
Different services, shared dependencies
I spend much of my working life building things using other people’s technology. That’s how we get useful work done. A large provider can afford specialists and equipment that its customers couldn’t, and popular software can benefit from far more scrutiny than something we write ourselves. I’d be very suspicious of an argument that we should all go off and build everything from scratch.
But making a service more reliable for each customer can also mean that, when it does fail, many more customers fail together. We need to understand both. And PHP is a useful reminder that this isn’t only about big companies. Separate organisations can inherit the same problem through a common piece of software, without ever buying anything from the same supplier.
The dominance of a few providers makes finding alternatives harder too. The CMA’s 2025 cloud investigation found a highly concentrated infrastructure market, led by Microsoft and AWS, with commercial and technical barriers to switching or using multiple clouds. Choosing another provider can mean changing software, moving data and learning to operate a different system. You need time, money and people who know how to do it.
So I don’t think we can simply count dependencies and declare that fewer is better. An extra connection might give us another way to keep working. But if two supposedly independent services both rely on the same thing underneath, we’ve recreated the problem with the drives.
This reaches into some very ordinary activities, including things we used to fall back on when something else stopped working. A basic corded landline could keep working when the lights went out because the telephone exchange supplied its power. The exchange and the line still had to work, of course. A television needed electricity at home, an aerial and a broadcast signal. A portable radio could run on batteries; a wind-up set could generate its own power.
Ask a smart speaker to play the radio, or watch television through an app, and you’re now using an internet connection and a streaming service. Digital landlines use broadband too, with backup power needed to keep them working during a power cut. You may still be using a familiar handset, but quite a lot has changed behind it. What sounds like three different ways to get information or help may now depend on the same router and electricity supply.
The value of those older options became painfully clear after Russia’s full-scale invasion of Ukraine in 2022. The European Broadcasting Union describes refugees relying on car radios and battery-operated sets for vital information, in places where broadcasting still worked but internet access had gone. The broadcaster still needed power and functioning equipment. The listener, though, could hear the news without a working internet connection or mains socket. There’s a good reason battery and wind-up radios still appear in the UK’s emergency preparation advice.
We haven’t lost all of these alternatives: terrestrial Freeview still doesn’t need an internet connection, including on a smart TV with a working aerial connection and tuner. But if we’ve removed the aerial, replaced the portable radio with a smart speaker and moved the phone onto broadband, we’ve given up useful fallbacks. We can make each of those changes for perfectly sensible reasons without noticing what they add up to.
The same applies to switching from broadband to mobile data. Very useful if the broadband is down; rather less useful if the app’s servers are unavailable at the other end. Or having a second bank card, which helps only if the systems needed to accept and authorise it are still working.
What worries me most is how poorly we understand all this compared with how much we now depend on it. Turning on the radio, making a call, buying food: we still think of these as simple activities. Explaining what has to work for us to do them is getting rather more complicated.
The bus is part of the service
Of course, we were quite capable of creating these problems before we put computers in everything. Consider a GP surgery that’s open, staffed and offering appointments, but the bus route has changed. Someone a few miles away can no longer get there because the new route involves a walk they can’t manage, or the bus arrives after their appointment.
From the surgery’s point of view, the service is available. There’s still a bus too. But for the person trying to see a doctor, those two facts aren’t much use unless they fit together.
The local post office can be part of this as well. It’s somewhere to pay bills, get cash and ask for help from an actual person. In January 2022, Citizens Advice described a man whose nearest open branch involved a 90-minute journey. He could only get there once a week, which led to overdue bills and fines from utility companies. Making a service available further away had changed whether he could use it when he needed it.
Now imagine the bus becomes less frequent. Someone assesses the change, looks at the services nearby and concludes that residents should still be able to manage. Then the post office closes. A water leak temporarily closes the GP surgery, and appointments move elsewhere.
I’ve made up that combination, but it doesn’t take much imagination. The bus change might have been manageable while everything else stayed where it was. Either relocation might have worked with the old timetable. The person who assessed each change may have done a perfectly reasonable job with the information available. It’s the combination that leaves someone stuck.
And who notices? Does anyone connect the missed appointment and unpaid bill to what has changed, or do they just get recorded as someone who didn’t turn up or pay on time?
Each organisation could fall back on the Shaggy defence: it wasn’t me. We checked our decision. Somebody else changed theirs. I can understand how we get there, but it leaves the person affected trying to solve a problem that none of the organisations considers its own.
This is why “just use another supermarket” isn’t much of an answer either. It assumes you can get there. “Use another payment method” assumes you have one that works. Those might be easy enough for me, but someone with less money, limited mobility or nobody to help may have very little room to adapt.
We don’t need society to stop functioning everywhere for it to stop functioning for someone.
What would engineering for resilience look like?
I don’t expect the bus operator to predict a water leak at the surgery, any more than I expect every website developer to find every flaw in PHP. But I do think we can be more curious about what our services depend on, and more realistic about what happens when those things aren’t available.
What are we trying to keep working?
I’d start with what someone needs to do. A supermarket needs to receive food, keep it safe to eat and let people buy it. A patient needs to get to an appointment. Working back from those needs tells us which connections matter, including the ones that don’t appear on an IT diagram.
Then we can ask what still works if we lose one of them. Could the refrigeration be controlled locally? Could staff accept essential orders while the usual system is unavailable? Can they get to the recovery instructions and contact the supplier if the login service is down? I would want to try these things with the people expected to do them. Discovering that the emergency procedure requires access to the broken system is an avoidable disappointment.
The Dutch cybersecurity centre’s response to the PHP problem offers a useful example. It could still publish advice through other channels while its website was offline. It had another way to do the important part of its job. That’s the sort of alternative I mean, although we’d still need to check what those other channels depend on.
Patching software and restricting access to equipment remain essential. But we also need to plan for the period when something has been switched off for investigation or repair. As the supermarket incident shows, protecting a system can interrupt the work it supports. Having a plan for that interruption should be part of making it safe to shut down.
And getting the computers running again doesn’t finish the job. Spoiled food has to be replaced and delayed orders dealt with. In our imagined community, someone needs to notice the missed appointment, find out why it happened and help arrange a journey the patient can actually make. That requires time, information and sometimes money. It also requires permission to get involved in something that may technically be somebody else’s responsibility.
I’d want the people affected involved in deciding whether we’ve fixed it. Waiting for a complaint assumes they know who to complain to and have the means to do so. A call from the surgery might tell us more than another report showing how many appointments were available.
And AI?
This brings me back to where the conversation started. The 2026 International AI Safety Report discusses shared vulnerabilities when a small number of models are used across many sectors. We could build very different applications and still inherit the same underlying behaviour, much as we did with those drives.
Before making another service dependent on a model, I’d like to know what we’ll do if it becomes unavailable, changes or keeps getting something wrong. Can someone challenge a decision and get help? Will we still have people who know how to do the work without it? These are fairly ordinary questions, and this month’s incidents give us plenty of reasons to ask them now.
Who has to put things right?
The part I find hardest is responsibility. We’ve made it possible for a decision in one organisation to affect people who may never have heard of it. Those people have very little say in the decision, and often no useful alternative when something goes wrong.
I think that should create an obligation. If people depend on what you provide, you should have to understand that dependence, explain its limits and help when it breaks. That applies to the organisation choosing the technology as well as the supplier. Neither can sensibly take responsibility for every possible event, but between them they ought to know who can act, who can authorise spending and who will check that people can use the service again.
For the bus, surgery and post office, there may be no contract joining the organisations up. I’d want the local authority, or another agreed lead organisation, to provide a named coordinator with time, authority and a budget to bring them together. Someone needs to check what their changes mean in combination, listen to the people affected and arrange practical help—whether that’s adjusting appointment times or paying for a journey. Otherwise, we’re leaving the coordination to the person with the fewest options.
Keeping alternatives available will cost money. So will retaining skills and giving staff time to practise recovery. We should be honest about that, but also about who bears the cost when we decide those things are unnecessary.
I enjoy building connected things. I want us to keep doing it. What I don’t want is for us to keep adding dependencies without understanding how far a failure can travel, then be surprised when the consequences turn up at the supermarket or the surgery.
Perhaps the question to ask before making the next improvement is quite simple: if this stops working, what will the person who needs it actually be able to do?
