DEV Community: Zoran Stankovic

Why a password is not a security architecture for connected building devices

Zoran Stankovic — Fri, 17 Jul 2026 14:42:43 +0000

Connected heating, water, and building devices are now part of the cybersecurity surface of a building. A password screen is not enough. The product needs update paths, secure defaults, supported software and documentation from the start.

A heating controller with Wi-Fi is not just a heating controller anymore.

A water treatment monitor with cloud connectivity is not just a monitor. A smart access panel is not just a relay board with an app. Once the product connects to a phone, gateway, cloud platform or building network, it becomes part of a cybersecurity problem.

For a long time, many connected building products treated security as something added near the end. Add a password. Disable a debug port. Put TLS in the app connection. Write something about encryption in the manual.

That approach is running out of road.

The EU Cyber Resilience Act brings cybersecurity requirements into the planning, design, development and maintenance of products with digital elements. The main obligations apply from 11 December 2027, with reporting obligations starting on 11 September 2026. The UK PSTI regime is already in force for consumer connectable products and includes requirements around passwords, vulnerability reporting information and minimum-security update periods.

The point is not only regulation. The point is what it forces engineering teams to decide earlier.

Security starts with product architecture

A connected building device needs a security model before the firmware is finished.

Who can configure it? How is the device provisioned? Are credentials unique per unit? Where are keys stored? What happens after a factory reset? Can firmware be downgraded? Is debug access disabled in production? Can a compromised phone app change safety-relevant settings?

These are embedded architecture questions, not paperwork.

We saw this clearly on a residential heating project. The client used a touch display as the central HMI for controlling and configuring heating devices in daily operation. The previous platform had been in use for around ten years and was based on a 5-inch display. At the time, it made sense. Over time, it became a critical dependency.

The problem was not only that the interface felt old, or that similar devices had moved toward 7-inch displays. The deeper issue was the software base underneath it. Legacy libraries, outdated components and unsupported versions made it harder to maintain security, support production and align the device with newer cybersecurity expectations.

It meant moving to supported software versions, updating libraries, applying secure coding practices and rebuilding the HMI platform on a more robust cybersecurity foundation.

That is a common pattern in building products. Cybersecurity risk is not always visible as an exposed cloud API or weak password. Sometimes it sits inside the HMI, bootloader, Linux image, third-party library, production tool or service interface that nobody wanted to touch because it had “worked for years”.

OTA is part of the plan

Building products live for years. During that time, vulnerabilities will be found, libraries will age and customer systems will change.

That makes OTA more than a convenience feature. The update mechanism needs signed firmware, version checks, rollback and clear failure recovery. A failed update should not leave a heating controller unable to control outputs or a monitoring device silently offline.

Plan it before the board is frozen

Cybersecurity planning belongs in the first development gates.

In PrecisionPath™, our seven-gate development process, this is treated as an early architecture and risk topic. Support period, update strategy, secure boot, provisioning, debug access, documentation, service tools and vulnerability handling need to be defined before detailed hardware and firmware work lock the product into a weak path.

A password screen is not a cybersecurity plan.

For connected water, heating and building products, the real plan is the ability to build securely, update safely, prove what was released, and support the product for the years it will actually spend in the field.

Designing heating and water electronics that last 15 years in the field

Zoran Stankovic — Fri, 17 Jul 2026 14:38:55 +0000

A heating controller is not a phone. Nobody replaces it every two years. It goes into a basement or a plant room. It has to run for 10 to 15 years with almost no service. Getting the first prototype to work is the easy part. The hard part is the thousandth unit, still working ten years later, long after the engineer who designed it has left.

Almost every long-life field failure we have been asked to investigate started with a decision made in the first few weeks of the project. So that is where the design work belongs.

What actually kills these products

Electrolytic capacitors, most of the time.

Their lifetime roughly halves for every 10 °C increase in operating temperature. A capacitor rated for 2,000 hours at 105 °C may last well over a decade in a lightly stressed design, or only a few years if exposed to high heat and ripple current. That is why we derate them generously, place them away from hot components, and use polymer or long-life types where the budget allows.

Relays are next. Every relay has a limited number of switching cycles. That number drops fast under inductive loads such as motors, pumps, and solenoid valves. A relay controlling a pump just a few times per hour can still accumulate millions of operations over the product’s lifetime. So we size it for the real duty cycle, not the headline number in the datasheet. On the 12 kW three-phase water heater controller we built for HotSet, we moved the switching to TRIAC stages with zero-cross detection. That removed the mechanical wear completely.

Then there is the power environment, which is not a single component. Brown-outs, mains spikes, condensation, and surge events are normal in a plant room. They are not rare cases. Surge protection, reverse-polarity protection, and a wide-input supply should be part of the design from day one. If you only add them after a field failure, you end up paying for a redesign.

The firmware has to outlive its chip

Hardware is only half of the problem. A connected device needs security patches and bug fixes for as long as it is in the field. Under the EU Cyber Resilience Act, that is now a legal duty, not a favour to the customer. None of it works unless the firmware was built for it. That means a clean separation between the application logic and the hardware abstraction. It means deterministic state handling, watchdogs, safe states, and signed OTA updates.

The hardware abstraction layer matters more than it sounds. Over 15 years, a microcontroller will go end-of-life. That is certain. A layered architecture lets you move to a new chip without rewriting the whole product. We have done exactly this for a client whose original chip disappeared from the market. We carried the existing behaviour onto a new part.

This is why we run every project through PrecisionPath 7™, our seven-gate development process. A capacitor lifetime question is free when it is one line in a Gate 1 requirements document. The same question becomes a recall when the field finds it for you. So lifetime targets, EN 60335 scope, and duty cycles get fixed before anyone draws a schematic. Derating and end-of-life flagging happen during detailed engineering. And active management of the parts list at volume keeps the product buildable as components change underneath it.

Build the long life in at the start, or pay for it later in warranty claims. There is no third option.

A firmware fix instead of a recall: root-cause engineering for a deployed wearable

Zoran Stankovic — Fri, 17 Jul 2026 14:35:51 +0000

The wearable was already in the market, on athletes, when the reports started. Units power-cycling at random. Unreliable charging while docked. Data going missing during real competition use, which is the worst possible moment. The product was already in customers’ hands. So the two obvious answers, redesign the hardware or recall the units, were both slow and both expensive.

This is the situation nobody wants. It is also where the difference between guessing and root-cause engineering gets very real. We took this device, in exactly this state, and fixed it in firmware. No hardware redesign. No recall.

When a deployed product misbehaves, the tempting move is to chase the symptoms. Add a retry where charging fails. Add a delay where it power-cycles. Patch each visible failure as it gets reported. That road leads to firmware that is a pile of workarounds, and to a problem that keeps coming back in a new shape. We have seen products die slowly that way.

So we went after the cause instead. We stress-tested the device on purpose, to force the failures under controlled conditions, rather than wait for them in the wild. The instability traced back to electrostatic discharge. The device’s input pins did not have enough hardware filtering. And the firmware did not have the signal conditioning to reject the transients that resulted. That single cause explained everything at once: the random power cycling, the charging trouble, and even some inconsistent button behaviour that had been logged as a separate complaint. One root cause, several symptoms. That is usually the shape of these problems. It is also why chasing symptoms one by one never converges.

Once we understood the cause, the fix could be precise. The units were already deployed, so hardware was off the table. The solution had to live entirely inside the existing hardware and its firmware. We built a firmware module for signal stabilisation. It used interrupt-driven validation with defined timing windows, in the range of 80 to 100 milliseconds. So a transient from an ESD event was recognised as noise and rejected, instead of being acted on as a real signal. It dropped into the existing firmware without disturbing the core functions. It removed the random power cycling and the charging instability. The button problem, same root cause, went away with it. The fix was deployed as a firmware update to devices already in use.

Now the honest part, because it would be easy to turn this into a story about firmware saving everything. It does not always. Some field failures have no firmware solution. If the hardware is fundamentally wrong, firmware can sometimes buy time, but it cannot provide a real fix. Pretending otherwise just delays the reckoning and burns the customer’s trust along the way. Part of the value of proper root-cause work is that it tells you honestly which case you are in. You find the cause first. Then you decide whether firmware can address it. You do not just hope a patch holds and find out in the next batch of returns.

Two things made the firmware fix possible here. First, the cause was a signal-integrity problem that firmware could compensate for, which is not always the case. Second, the firmware was built well enough to accept a clean new module without destabilizing the rest of it. That second part is never luck. It is a result of how the firmware was built in the first place.

That is where this connects back to how we work. The whole point of the validation gate in PrecisionPath 7™, our seven-gate development process, is to force failures like this one before the product ships. We use stress testing and EMC and ESD pre-compliance, so they never reach a customer. When something does slip through, the work after launch is the same disciplined root-cause method, now pointed at deployed units. And the firmware-architecture decisions made back at the detailed-engineering gate are what decide whether a clean late fix is even possible. A well-built firmware base is what lets you drop in a stabilization module instead of opening a recall.

A misbehaving product in the field is not automatically a recall. Sometimes it is a hard week of honest root-cause work and a firmware update. The trick is knowing the difference. And you earn the right to the easy ending by building the product properly the first time.

Build vs buy for industrial controllers: the common mistake I see

Zoran Stankovic — Fri, 17 Jul 2026 14:33:03 +0000

After 13 years of industrial projects, I can usually tell early how a build-vs-buy decision will go. And it tends to go wrong the same way.

The engineers want to build because building is the interesting work. Finance wants to buy, because buying looks cheaper this quarter. Both sides argue from instinct. Instinct is not a decision. The decision needs numbers. And the number people start with is almost always the wrong one.

That number is the per-unit cost. Here is why it is a trap.

A few years ago, a UK-based energy aggregator came to us. They ran distributed energy systems across thousands of field sites. They used off-the-shelf industrial PCs with GSM modules, at about £1,200 per installation. With around 3,000 installations planned, that is £3.6M of hardware that does not scale. The obvious move was to build custom hardware and push the unit cost down.

And custom hardware did win on unit cost. Our conceptual custom design came in at around £140 per unit. If per-unit cost were the whole story, we would have built it.

But it is not the whole story. Custom hardware also meant 12 to 18 months of development. It meant real upfront cost, certification work, and the constant risk of a board re-spin. The off-the-shelf option we chose was a Siemens SIMATIC IOT2020 running Yocto Linux, at about £260 per unit. On the spreadsheet, that £120 premium looked like a loss. What it actually bought was no certification overhead, no re-spins, no timeline risk, and immediate availability. For a project that needed to deploy soon and at scale, that was the cheap option, not the expensive one.

The thing that decided it never shows up in a per-unit comparison. The existing software moved onto the IOT2020 with no major changes. We adapted the Yocto environment, added Modbus for the external heating and industrial devices, and added Perl runtime support so their existing scripts kept running. Keeping the software platform intact removed a whole class of cost and risk that a per-unit number cannot see.

The final numbers. Unit cost dropped from about £1,200 to £260. Hardware cost across 3,000 units dropped from about £3.6M to £780K. The engineering to get there was around €20,000. And the cheaper-per-unit option, custom hardware, would have been the wrong call.

So when someone asks me build or buy, I do not answer with an opinion. I answer with four comparisons, and you have to do all four honestly. First, total cost at your real volume, not per unit. Second, timeline, and what a delay actually costs you. Third, risk, which means re-spins, certification, and supply. Fourth, what you get to keep, because keeping your existing software is often worth more than a cheaper board.

At ARS we make this call at the conceptual-design gate of PrecisionPath 7™, our seven-gate process. And we treat it as a real gate. We design the custom option far enough to cost it properly. We measure the off-the-shelf options against the same yardstick. Then we hand over a side-by-side comparison, not a recommendation dressed up as one. The teams that get this wrong skip the gate. They commit to building, or to buying, before the work that would have told them which one was right.

A €20,000 feasibility study is cheap insurance against picking the wrong architecture for the life of the product. I have watched the alternative too many times.

If you are facing a build-vs-buy decision and want it answered with numbers, not instinct, send me a message. No sales pitch, just the math.