WTWilly Tai
Case study · live demoSmart Buildings · IoT Governance

Buildings buy sensors like stationery, then inherit them like liabilities.

Every smart-building programme ends with a fleet nobody meant to own: gateways two firmware versions behind a published security advisory, controllers past end-of-support, certificates expiring into outages, devices whose owner left the company, and a CO₂ sensor that went silent six weeks ago while its readings still feed the sustainability report. This registry runs a 124-device synthetic estate through seven versioned lifecycle rules and produces the three artifacts an estate actually needs: a risk register where every finding cites its rule, a twelve-month governance calendar, and an onboarding gate that stops the next liability at the door. It is my PhD research, made operational. Runs live in your browser.

01 / The pain, and why the naive approach fails

The project that installed the sensors ended. The sensors didn't.

IoT enters buildings through projects: an energy retrofit here, an IAQ initiative there, each procured on device price with no line item for the decade of custody that follows. Then the project closes, the integrator leaves, and the estate has inherited hundreds of networked computers with no owner, no patch path and no death plan. The naive answer is a network scanner, which finds devices but answers none of the governance questions: who owns this, when does support end, what happens to the ESG number it feeds when it goes quiet? Discovery is a snapshot; lifecycle is a register, and a register is only useful when rules run over it continuously. Ten years of delivering these fleets (50+ Government facilities, ten malls, IAQ programmes) taught me the pattern; the PhD (IoT management in smart buildings, University of Reading) is the systematic version of the lesson.

02 / How it works

Seven rules, a calendar, and a gate.

The rules are deliberately readable: L1 past end-of-support (severity scaled by network exposure), L2 firmware behind a security advisory (critical, patch this week), L3 certificates expired or expiring, L4 no accountable owner, L5 factory credentials flagged, L6 silent devices whose data feeds reports, L7 flat-network placement. Each finding names its device, rule and rule version; the register sorts by severity and blast radius, because a gateway with an authentication bypass outranks a thermostat past support. The calendar plots every support expiry and certificate renewal across the next twelve months, turning surprises into budget lines. And the onboarding gate asks six questions of every new device (who owns it, who patches it, where does it sit, what data does it produce, how does it authenticate, how does it die), because the cheapest finding is the one that never enters the estate.

Finding classCountSharpest example
critical12gateways running firmware behind a published authentication-bypass advisory
high15silent CO₂ and energy meters whose gaps become estimates in the ESG report
medium51orphaned owners, flat-network placements, certificates drifting toward expiry
clean67 devicesa fleet is not a scandal; it is a register with findings
The ESG angle is the sleeper. When Scope 1 and 2 assurance arrives for listed companies in FY2029, the meter trail behind each number gets tested. A registry that shows which sensor produced which figure, and when it was last alive, is the difference between evidence and an estimate wearing a sensor's name.
03 / Numbers & honest trade-offs

What it does, and what it does and doesn't prove.

124
devices, 7 types
Four buildings, planted pathologies, zero labels.
7
versioned rules
78 findings, every one citing its rule.
38
calendar events
Twelve months of expiries, visible at budget time.
6
gate questions
No device enters without the answers.

Where this stands, honestly. The estate is synthetic, with a made-up advisory list, because real fleet data is exactly what should never appear on a public page. The rules are deliberately simple; production versions wire into network discovery, a CMDB and vendor advisory feeds, and the genuinely hard work is organisational: getting a building owner, an FM contractor and an IT department to agree who owns a sensor. That is why the deliverable includes the gate, not just the register: the technology is a spreadsheet with rules, and the value is the operating discipline it encodes. The proposition in one line: I turn an inherited pile of devices into a governed asset class, before the auditor or the attacker does it for you.

What this says about how I work.

My PhD asks how buildings should govern the sensing layer through its whole life, and my delivery record kept handing me the reason the question matters: every programme I shipped left behind a fleet, and nobody budgeted for its middle age. This registry is what research looks like when it is built to be used: seven rules an FM director can read, a calendar a finance team can budget from, and a gate a procurement team can enforce. Where the audit training shows is in the shape: findings cite rules, rules have versions, and nothing is asserted that the register cannot show.

See it run, live.

Read the fleet summary, filter the risk register by rule (start with L2, the advisory-exposed gateways), hover the calendar dots, and read the six gate questions that stop the next liability at the door.

Open the registry →Runs client-side over a synthetic estate: no sign-in, nothing to install.