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

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.