The Loom of Doom: What My 35-Year-Old Land Rover Taught Me About Cyber Recovery
I drive a 35-year-old Land Rover Defender, which I love dearly and will never part with. After 35 years, it was finally time to replace the bulkhead, one of the few steel parts on a Defender that eventually rots away. Doing that job properly meant pulling the entire wiring loom out of the vehicle.
Needless to say, three-and-a-half decades of adding worklights, a tow hitch, rear cabin lights, a winch, a CB and a stereo meant that what was once a well-wired, colour-coded loom had become what I can only describe as the “Loom of Doom”. Every one of those additions had made sense at the time. None of them had been documented. Each wired in standard red and black wiring. By the time I came to rebuild it, I found interdependencies I'd long since forgotten about, including, somehow, a wiring path between the horn and the hazard lights.
Only Land Rover would design a vehicle where sounding the horn has anything to do with the hazard lights. On top of that factory-default weirdness, thirty-five years of incremental, undocumented change created their own strange interdependences on earth points and interconnections I needed to resolve before I could get back on the road.
Larry: my 35 year old Defender still doing the job it was built for.
I'm rebuilding it properly this time. New looms throughout. Every connector standardised back to classic Land Rover bullets. Consistent end-to-end wire colouring. Everything labelled. An auxiliary fuse box installed so future additions have somewhere sensible to go rather than being spliced into whatever wire happened to be nearby. Sometimes the right answer isn't to keep patching the fragile thing you already have. It's to retire it and rebuild it properly, because that's what makes everything easier when you do break down.
I couldn't get very far into that garage job without recognising the pattern. I've spent most of my career helping business respond and recover after cyberattacks only to discover that my Loom of Doom looks positively mature in comparison with many organisation’s understanding of how to get their businesses back on-the-road.
What Happened
Most environments I have been dropped into either as a consultant to run cyber resiliency transformations, or as a responder when they’ve been attacked started life reasonably well architected, then it lived in business-as-usual reality. Someone bolted on a quick integration to hit a deadline. A team stood up a workaround because the proper fix was six months out. A quick undocumented change here-and-there. A vendor product got wired directly into three other systems because that was faster than doing it the sanctioned way.
None of it was unreasonable in isolation. All of it made sense at the time, exactly like adding a winch or a CB radio to a Land Rover. Nobody sets out to build a Loom of Doom. It accretes, one sensible decision at a time, over years.
Exactly like my Defender, the interdependencies rarely get documented, because nobody documents the thing they're doing to solve today's problem. At best, they document the original design. What actually happens next lives in the heads of the two or three engineers who did the work, and those engineers move on, get promoted, simply forget, or don’t scale during a large-scale cyber incident.
You don't discover any of this while everything is running normally. My Defender with its Loom of Doom still started, still got me up mountains and through rivers, right up until the day you need to diagnose what’s wrong and recover. That’s the day you find out how tangled your wiring really is.
The Loom of Doom. Blue labels are to try and make some sense of it!
For years I had been driving the Defender and proving that it worked. What I had never tested was whether I could rebuild it, or even rebuild the electrics to a known, trusted state.
Most organisations continuously prove that production works. Very few regularly prove that they can reconstruct production when the assumptions that keep it working disappear.
Six Lessons From My Garage Floor That Apply Directly to Cyber Resiliency
1. Undocumented Growth Becomes Invisible Technical Debt
Every wire I added over 35 years made sense in isolation. Collectively, they became a system nobody, including me, fully understood anymore. IT environments accumulate the same way: integrations, exceptions, shadow IT and "temporary" workarounds that quietly become permanent. Technical debt like this doesn't show up on a risk register, because nobody's added it there. It shows up the day you try to recover.
2. Interdependencies Only Reveal Themselves When You Investigate, Recover or Rebuild
I had no idea my horn and hazard lights were connected until I had the loom out on the floor and started testing circuits one at a time. Most organisations are running systems with equivalent hidden couplings: an authentication service that three unrelated applications quietly depend on, a scheduled job that fails silently if a legacy system is unavailable. These dependencies are close to impossible to map from a whiteboard. They only surface under load, under failure, or under recovery, which is exactly the worst time to be learning about them.
3. Recovery Capacity Is Limited by People, Not Technology
The reason my rebuild took so long wasn't the wiring itself, it was that I was the only person who half-remembered why any of it was connected the way it was. I've written before about how recovery capacity is often constrained by people, not technology, and a garage floor is as good an illustration as any incident I've responded to. Tribal knowledge concentrated in a handful of people isn't resilience, it's a single point of failure that hasn't failed yet.
4. Identity Is the Wiring That Holds Everything Together
A loom is, functionally, the identity and trust fabric of a vehicle. Every component only works because it can trust the connection back to power and to every other component it depends on. I've argued for a long time that identity is the critical path to recovery: if you can't trust the credentials, tokens and service accounts running through your environment, restoring the servers around them achieves very little. A clean bulkhead means nothing bolted to a compromised loom.
5. Your Recovery Capability Needs Its Own Clean Infrastructure
Installing an auxiliary fuse box wasn't cosmetic. It gives future additions somewhere purpose-built to connect, rather than being spliced into circuits never designed to carry them. That's the same argument for architecturally separating the recovery control plane from production. Backup infrastructure, recovery orchestration and clean-room capability need to be trustworthy on their own terms, not inherit the fragility of the thing they're meant to recover.
6. Sometimes You Don't Patch. You Rebuild.
I could have kept tracing and labelling the spliced original loom indefinitely, the same way organisations spend years patching around legacy systems and inherited technical debt. At some point the fragility of the whole becomes the risk, not any one fault within it. That's also the argument behind treating your backups as more than an insurance policy: a clean, standardised, well-documented rebuild beats an ever-growing pile of patches every time, even when it's the harder call to make in the moment. That’s why I’ve invested in a new loom and to colour-code each circuit back to factory defaults.
The Bigger Picture
None of this was really about the Landy. It was a reminder of something I tell boards constantly: resilience isn't tested when things are running, it's tested the day you have to understand why it has stopped working, recover or rebuild them, and that day is rarely one you get to choose.
So here's the question worth asking about your own environment, not mine: if you had to pull your organisation's wiring out onto the garage floor tomorrow, would you understand how it all connects, or would you be discovering it for the first time under pressure?
