The life and death of a sensor

Buildings inherit fleets of networked devices through projects that end. What happens to those devices over the next ten years depends less on the hardware than on whether anyone keeps a register and runs rules over it.

Willy Tai · Smart Cities · AI · ESG · October 2026

A carbon dioxide sensor on level seven stopped reporting six weeks ago. The dashboard still shows its last value, 612 ppm, in a reassuring shade of green. No alarm fired, because a sensor that has gone quiet sends nothing to alarm on. The project that installed it closed three years ago, the integrator has moved on, and the person who knew which gateway it talked to has left the company.

I have delivered these fleets into government facilities and shopping malls, and the pattern repeats. Sensors arrive through projects: an energy retrofit, an indoor air quality programme, a smart-FM platform. Each is bought on device price and commissioned to a test sheet, and each leaves behind a few hundred small networked computers that somebody now owns for a decade. The handover folder usually holds a device list. It rarely holds an owner for each device, a firmware baseline, a support end date or a rule for noticing when one stops talking.

The explainer below runs the same synthetic estate of 400 devices twice over ten years. On the left nobody keeps a register after handover. On the right a register holds each device's owner, firmware, support date and expected reporting interval, and simple rules run over it.

Silence that nobody hears

Most building systems alarm on values: a temperature too high, a pressure too low. A device that stops sending produces no value, and many platforms keep displaying the last one they received. The fix costs almost nothing. Give every device in the register an expected reporting interval, and raise a work order when it has been silent for longer than that. In the right-hand fleet a 24-hour last-seen rule turns every silence into a ticket within a day, so at year five the left-hand fleet has 14 devices quietly offline and the right has none.

Batteries make this predictable rather than rare. The LoRa Alliance says devices on its networks can run for more than ten years without a battery change [3], and some do, but real life depends on how often the device reports, how much it sends and how warm it is. In my simulation battery-powered air quality sensors start to fail from year five. Without a register, the first sign is usually a gap in a report that someone else has to explain.

Firmware that drifts apart

On handover day every device runs the same release. Then the vendor ships updates, some devices get them during a service visit, some never do, and a few were never updateable in the first place. By year ten the unmanaged fleet in the explainer runs six firmware releases at once, and more than a quarter of its devices are three or more releases behind. Each release is a separate set of known weaknesses to track.

The cost of neglect is well documented. The Mirai botnet of 2016 found its victims by trying a list of 62 common default usernames and passwords on internet-facing devices [4], and at its peak it held around 600,000 infected devices [5]. In 2025 the UK government published testing of enterprise connected devices, the category that includes building entry systems, and found outdated software throughout; one device carried a bootloader more than fifteen years old [6]. That was a sample of eight devices, so it shows the problem exists rather than how common it is, and I could find no official figure for how much of the installed base runs old firmware. Singapore's new Green Mark, version 7, which took effect on 2 September 2026, puts the practice in writing: its Intelligence guide recommends an up-to-date inventory of hardware and software assets that includes each device's firmware version, and changing every factory default password [12][13]. Those are guidance notes and are not scored, which is worth knowing when a vendor tells you the building is "Green Mark compliant".

The right-hand fleet keeps a firmware baseline and rolls updates out in stages, so at most two releases are ever in use: the current one, and the previous one on devices still waiting for their turn.

A gate at the door

Before a device joins the network it should come with answers to a short list of questions, the same six my IoT Fleet Registry demo asks: who owns it, who patches it, where on the network it sits, what data it produces, how it authenticates and how it will be retired.

Regulators abroad have started to require part of this from manufacturers. Since 29 April 2024 the UK's product security regime has required consumer connectable products to ship without universal default passwords, to publish a contact for security reports, and to publish a defined support period [7]. The European standard behind much of this, ETSI EN 303 645, lists publishing the support period as a mandatory provision [8]. The EU Cyber Resilience Act goes further and covers products with digital elements more broadly: its reporting duty for actively exploited vulnerabilities has applied since 11 September 2026, most of the rest applies from 11 December 2027, and the support period must be at least five years unless the product is expected to be used for less [9]. Published support periods are still the exception. When the US Federal Trade Commission's staff looked at 184 smart products in 2024, 161 of them gave no support duration or end date on their product pages [10].

Singapore's Cybersecurity Labelling Scheme covers consumer devices, and only residential routers must carry a label [11]. There is no equivalent label for building or operational-technology devices, so for an estate the gate has to be written into the owner's own specification and enforced at commissioning.

The end date nobody budgeted for

Some devices fail because a network they depend on is switched off. Singapore began retiring its 3G networks in August 2024, with M1 switching off first and Singtel and StarHub planning to follow from November, and IMDA told providers of non-telecommunication products that relied on 3G to take mitigating steps and inform their users [1]. 2G had gone the same way from 1 April 2017 [2]. No device data sheet mentions a network retirement, yet it ends the device.

In the explainer, eight of the estate's 24 gateways use 3G. When the network goes in year six, those gateways and the 40 meters behind them go quiet together, and in year seven vendor support ends for 48 controllers. The register-driven fleet sees both dates years ahead, because they sit in the register next to each device, and replaces the gateways in year five and the controllers on a budgeted schedule. Green Mark version 7, again in guidance notes, recommends that building management system components carry firmware and security patch support for at least ten years, and fifteen where possible [12]. That belongs in the original tender.

A register that survives handover

A register is only useful if it outlives the project that created it. That means it belongs to the owner, sits in a system the owner controls, and names a person for every device. In the unmanaged fleet, owners drift out of the record as staff leave: by year ten, 137 of 400 devices have nobody on record. In the managed fleet the owner field is updated as part of every staff exit.

The register also needs a shared vocabulary, or each contractor will name points their own way. Green Mark version 7 scores the adoption of a recognised ontology such as Brick or Project Haystack, and for new buildings it scores a digital FM handover in which asset documents are linked to each asset in the as-built model [12]. ASHRAE's proposed Standard 223P is working towards a common semantic model for building data [14]. NIST's baseline for IoT device security starts with device identification for the same reason: a persistent identifier supports asset management [15].

Silent devices also reach the sustainability report. Owners of most commercial and institutional buildings of 5,000 m² or more must report a year's energy use to BCA under section 22FF of the Building Control Act [16], and a silent meter turns into an estimate there and in any carbon figure built on it. I traced that path in Where a carbon number breaks.

At year ten the two fleets in the explainer look like this. Without a register, 162 of 400 devices are silent and unnoticed, six firmware releases are in use and 137 devices have no owner on record. With one, seven devices are silent and every one of them is already flagged, two releases are in use and every device has an owner. The hardware was identical.

What I ask for at handover

• One row per device, keyed by an identifier that survives replacement of the gateway it talks to.
• A named owner, and the process that changes the name when that person leaves.
• Current firmware version and the date the vendor's support ends, including any network the device depends on.
• An expected reporting interval, so silence becomes a work order.
• Network placement and how the device authenticates. Factory credentials should already be gone.
• Which reports its data feeds, so a gap can be traced forward as well as back.

Sources

1. IMDA, 3G services to retire in phases, starting with M1's network in Aug 2024, paras 2 and 5. www.imda.gov.sg (24 Jul 2024)
2. IMDA, Equipment Registration Q&A, cessation of 2G networks and services. www.imda.gov.sg
3. LoRa Alliance, homepage statement on battery life. lora-alliance.org (accessed 18 Oct 2026)
4. US-CERT (CISA), Alert TA16-288A, Heightened DDoS Threat Posed by Mirai and Other Botnets. www.cisa.gov (14 Oct 2016)
5. Antonakakis, M. and others, Understanding the Mirai Botnet, 26th USENIX Security Symposium, 1093 to 1110. www.usenix.org (Aug 2017)
6. UK Department for Science, Innovation and Technology, Research on cyber security in enterprise connected devices. www.gov.uk (12 May 2025)
7. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, SI 2023/1007, regulation 1(2) and Schedule 1. www.legislation.gov.uk (in force 29 Apr 2024)
8. ETSI EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements, provisions 5.1-1 and 5.3-13. www.etsi.org (Sep 2024)
9. Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13(8), 14 and 71. eur-lex.europa.eu (23 Oct 2024; in force 10 Dec 2024)
10. US Federal Trade Commission, Smart Products Surveyed Fail to Provide Consumers with Information on How Long Companies will Provide Software Updates. www.ftc.gov (26 Nov 2024)
11. Cyber Security Agency of Singapore, Government to Raise Cybersecurity Labelling Requirements for Residential Routers. www.csa.gov.sg (2 Mar 2026)
12. BCA, Green Mark Version 7 Intelligence Technical Guide R1, IN1.2(i), IN2.1(iv), IN2.1(vi) and IN2.2(ii) with guidance notes. go.gov.sg (effective 2 Sep 2026)
13. BCA, Industry Circular, Launch of BCA Green Mark Version 7, ref BCA ID GM020926, paras 7 and 8. isomer-user-content.by.gov.sg (2 Sep 2026)
14. ASHRAE, Titles, Purposes, and Scopes: Standard 223P, Semantic Data Model for Analytics and Automation Applications in Buildings (proposed). www.ashrae.org (accessed 18 Oct 2026)
15. NIST, NISTIR 8259A, IoT Device Cybersecurity Capability Core Baseline, Table 1. csrc.nist.gov (May 2020)
16. Building Control Act 1989, section 22FF, Periodic reporting on energy use of Type 1 buildings. sso.agc.gov.sg (in force 30 Sep 2025)