You Can't Respin a House

This article was originally published on Insight Source.

Written by Jack Heath, Information Security Engineer

Most security advice quietly assumes a fantasy world: one where you can start over. Buy the new appliance. Replace the fleet. Respin the board with the right chip this time. Refresh on a three-year cycle and let the problem age out.

Real life does not work that way. Real life is already deployed.

My wife runs short-term rentals. A house is not a lab. It has a guest checking in tonight, a cleaner turning it over tomorrow, and a calendar booked out past that. You don't get to shut it down for a quarter while you re-architect it. Whatever you fix — a lock, the network gear, the way people get in and out — you fix between stays, in a window measured in hours. And it has to work the first time, because the next person through the door isn't a tester. They're paying to sleep there.

That isn't a hospitality problem. It's everyone's problem. And the technology world is finally starting to say it out loud.

This week a chip vendor announced something that sounds small and isn't: TPM 2.0 — secure boot, device identity, protected key storage — delivered in firmware across an entire line of modules already in the field. No discrete chip. No board respin. If the device can take a secure firmware update, it can gain a root of trust it didn't ship with. The vendor talks about product lifespans of seven to fifteen years. That's the honest timescale. The board you shipped five years ago is still in a clinic, a factory, a truck, a building — and it'll still be there five years from now. The question was never how to design a secure new one. The question is what to do with the ones already bolted down.

I've spent a lot of my career on the enterprise version of the same wall. Key estates, certificate estates, server fleets — none of them get respun either. They grow, they get acquired into, they accumulate one-offs nobody wants to delete. You secure them in place, in stages, while production is running. Or you don't secure them at all. The perfect redesign that requires everything to stop is just a polite way of leaving the old thing exposed.

Here's the work that actually holds up, whether the deployed base is a module, a server fleet, or a house people sleep in.

Start with what's actually out there

Not the purchase orders. Not the diagram. The physical reality: what's installed, what firmware it's on, how old it is, and whether the vendor still supports it.

This sounds basic, and it's where most plans quietly die. I've watched teams design an upgrade for a fleet they didn't actually have — wrong versions, forgotten units in a closet, a device swapped during an emergency repair and never recorded. In a house, that's the router a previous owner left behind, still plugged in behind a dresser. In a data center, it's the same router with a bigger budget.

Write it down before you buy anything. An inventory you trust is worth more than a product you don't.

Take the firmware door before the forklift

If something can be made meaningfully more secure by an update — firmware TPM instead of no TPM, current software instead of end-of-life software, automated renewal instead of a certificate tracked on a calendar — take that door first.

It's faster, cheaper, and it reaches the whole deployed base instead of just next quarter's purchases. A refresh-only strategy protects the future and abandons the present, and the present is where attacks happen. Attackers don't wait for your refresh cycle. They inventory your old gear more carefully than you do.

The catch: the update path itself must be trustworthy. Signed updates, a way to prove what a device is after the update, and a way back if the update fails. An insecure update mechanism isn't a door. It's a second front entrance with no lock.

Stage it like somebody lives there — because somebody does

Never start with everything.

Pick one unit, one property, one product line. Upgrade it. Live with it. Watch what breaks that the test plan didn't predict — the guest who can't get in, the client that doesn't trust the new configuration, the workflow that relied on the old behavior for reasons nobody wrote down. Fix it, document it, then move to the next group.

In key-management work, the rule is the same one I use in a house: the original stays working until the replacement is proven. You don't cut over on hope. You run the new thing alongside the old, reconcile the counts, and retire the old only after the new has carried real load. Big-bang cutovers are how security projects become outage stories people tell for years.

Automate the part that repeats, or it will beat you

A deployed base only grows. Every unit you add is another certificate to renew, another update to apply, another key to rotate, another account to close when someone leaves.

At small scale you can carry that in your head. At slightly larger scale you carry it in a spreadsheet and feel fine — right up until the week you don't. Manual tracking doesn't fail loudly. It fails on a Tuesday, in an expired certificate or a missed update, in a system nobody remembered was still running.

The fix isn't working harder. Inventory first, automate the recurring work second, and keep alerts as the safety net instead of the process. That order matters. Automating a mess just makes the mess happen faster.

Replace on evidence, not on a brochure

None of this means never replace anything. Some gear is genuinely done — unsupported, unpatchable, unable to prove what it is or protect what it holds. That gear goes first, ahead of the merely old.

What I'm arguing against is replacement as the default answer. Replace because a device can no longer be secured where it sits, not because a newer model exists. Put the money you save by upgrading in place into the short list of things that truly cannot be saved. That's how a small operator — and, honestly, most large ones — secures all of it instead of beautifully securing the newest tenth.

Regulators are starting to price this in. Europe's Cyber Resilience Act, fully applicable in December 2027, expects products to be secure by default and to receive security updates for years. That's not a refresh-cycle law. It's a deployed-base law — written for things that stay in service long enough to need looking after.

Why I'm sharing this

Because the most useful security shift I've seen in a while isn't a new product category. It's vendors and operators admitting, publicly, that the installed base is the job.

You can't respin a house. You can't respin a factory floor, a medical practice, or a fleet already on the road. You inventory what you have, take the upgrade that reaches it where it sits, stage it so the people using it never have to care, and automate the upkeep so it stays secure after you stop thinking about it.

Start this week with the list. One page, every deployed thing you're responsible for, with its age and update status. If a line on that page surprises you, you've found the work — and it was never going to be fixed by buying replacements for lines that didn't surprise you.