Losses in the tens of millions because of temperature controllers
Supermarkets across Europe took losses in the tens of millions after attackers got into their refrigeration controllers. Facilities Dive reported the Danfoss controller hack, and the same question applies to any building whose automation systems can be reached from the internet.
The report covers the stores' losses. It doesn't say who owned the equipment or how the losses were split among retailers, landlords, and insurers. In a lot of retail leases the refrigeration belongs to the tenant, so I wouldn't assume a landlord would carry this kind of loss. As an asset manager, I'd still take one thing from it. The same kind of controller runs the chillers, air handlers, door access, and lighting in buildings you own. Some of them are your equipment, on networks somebody set up years ago. If one of those systems stops working, your staff, your tenants, and your operating statement pay for it.
So I'd want two questions answered in writing for every property. Who can reach each system that runs the building? If a system fails and the company that installed it can't help, how would you bring it back with its settings and history intact?
How a building ends up with controls nobody has listed
Here's how it usually goes. A building gets a lighting retrofit in one year, a parking system a few years later, and a new chiller plant after that. Each contractor needs to support its work without driving to the site, so each one leaves itself a way in: a modem, a cloud portal, a remote desktop login. The passwords live in the contractor's service records. The as-built drawings, if anyone made them, end up in a project folder that left with the project manager. Ten years on, the property has several networks and several remote access paths, and nobody has a list of either.
Each contractor did reasonable work within its own scope. Nobody's scope covered the whole building, so nobody keeps the whole record. The property manager assumes IT keeps it, IT assumes the vendors keep it, and the asset manager gets a monthly report saying the systems are running.
The fix is three records the owner holds. The first is an inventory of every connected system. The second shows who can reach each one, from where, and by what method. The third is the admin credentials, held by the owner. Together, these are what operational technology governance means at a property, and it's common for a property to be missing at least one of the three.
The credentials matter most, because whoever holds them decides who gets in and who can fix things. If you don't own your data & digital infrastructure, your vendors do.
Why "call the vendor" isn't a recovery plan
The second question is recovery, and it depends on companies you don't control. Over a ten-year hold, some of the firms that installed your systems will be bought, change their support model, stop making the controller you run, or close. When that happens, the system often still works, but nobody can change it, update it, or repair it.
A system whose vendor is gone sometimes gets replaced even though it still works, and the reason is usually access. If the controller runs proprietary software, if the firmware can only be updated with the vendor's tools, or if the admin password was never handed over, then nobody else can safely reconfigure it. A technician from another company may decide the cheaper path is to rip out working equipment and start over. In that case you lose the setpoints, the schedules, the alarm history, and the operating logs that showed what normal looked like for that building.
A recovery plan you could actually use answers four things for each system:
- Where the current configuration is backed up, and in what format.
- Where the admin credentials are kept, under the owner's control.
- What the operating history looks like and where the owner keeps a copy.
- Where replacement parts and qualified service would come from if the original vendor couldn't help.
I put it this way on PPP Podcast Ep. 27: "I have the right to repair. I have the right to access. I have the right to make this data portable. It's my data. I just happen to be using you, Mr. Vendor... but I don't have to." That right only matters if the owner has the credentials, the documentation, and a copy of the data before anything breaks.
How a controller problem affects NOI and asset value
When a building system fails, the costs show up on specific lines.
The first is operating expense. The engineering team stops planned work to deal with the outage, and outside technicians get called in at emergency rates. If the outage affects how tenants use their space, it could also lead to rent concessions and a harder renewal conversation with that tenant.
The second is insurance. Underwriters ask what you run, how it's protected, and how you'd restore it. An owner who can hand over an inventory, access rules, and recovery plans gives the underwriter something specific to evaluate. I haven't seen a study that measures the effect on premiums, but I'd expect an underwriter with less information to be more cautious with terms.
The third is unbudgeted capital. If a system has to be replaced because nobody can support it, a working asset turns into a capital request.
The fourth comes at refi and exit. A lender's or buyer's diligence team will ask the same questions the underwriter asked, and any question you can't answer becomes something they can negotiate on.
All four lines lead to the same math. NOI you lose, or can't show is stable, gets divided by the cap rate when the asset is valued. Because the cap rate is a small fraction, each dollar of NOI moves the valuation by many times that amount. A small recurring loss on the operating statement can take a much larger amount off the sale price.
What an owner-controlled foundation would look like
The approach we recommend would connect every building system to one network the owner controls, with each system in its own segment so a problem in one stays there. From that foundation you'd get the three records above, plus a recovery plan for each system that would still work if the vendor couldn't help.
We'd get there in five steps, which we call the Peak Property Performance® PPP 5C™ plan:
- Clarify: build the inventory, record who controls each system and its credentials, and note what nobody could tell you.
- Connect: move each system onto one segmented, owner-controlled network. Our BoT® (Building of Things®) approach is built to do this.
- Collect: keep each system's configuration backups and operating history in a format the owner holds, so a vendor change doesn't erase them.
- Coordinate: set the rules for identity and access, including who can log in remotely, from where, and for how long.
- Control: run vendors, and any decision tools you add later, under owner permissions, so any of them can be replaced without rewiring the building.
The engineering discipline behind this is SIC®, our owner-controlled approach to securing and connecting a property's data & digital infrastructure. We run it as a managed service, so your engineers and property managers aren't asked to become network specialists on top of their regular work.
Where to start
This week, ask your property team for one document: the list of every system at one building that a vendor can log into from off site, with the name of whoever holds each login. If the list doesn't exist, or if most of the names belong to vendors, you'll know where the work starts.
If you'd like help building that list, we'd suggest a PPP Review on that one asset. It would show what's connected, who controls it, and what it would take to restore each system. It would also give you a written record you could bring to your next insurance renewal and your next refinancing. Send us the property you're least sure about, and we'll start there.
