Smart Thermostat Security Research Project | Projects

A client project around connected heating

I worked on this smart-thermostat security project during CMP308, Professional Project Planning and Development, at Abertay University. The brief came from PA Consulting Group and was handled as a client engagement: we had a defined business need, supplied hardware, regular reporting expectations, project-management artefacts, and a final presentation aimed at a technically informed client audience.

The technical subject was a Tado smart thermostat and compatible smart radiator valve. The project brief asked us to examine the wider ecosystem around the devices, including local network traffic, the mobile application, integrations with voice assistants, communication between the thermostat and radiator valve, and the ways remote control features could fail or be abused.

My assigned role was project manager. I coordinated two technical workstreams, maintained communication between the team and the client, and translated a broad security-research brief into scoped objectives and deliverables. The hardware workstream concentrated on the thermostat and valve. The software workstream concentrated on the mobile application, traffic inspection, and the surrounding services. Both teams reported through me before progress was communicated externally.

The surviving project archive contains the client brief, our project plan, role allocation, objectives, stakeholders, delivery model, and intended test areas. It does not contain a complete final technical report, so this page describes the research programme I helped design and manage rather than claiming vulnerability findings that cannot be verified from the retained evidence.

Why a thermostat has a sizeable attack surface

The project started from the changing role of domestic heating. A traditional thermostat has a narrow job and limited connectivity. A smart thermostat participates in a much larger system:

a wall-mounted thermostat measures temperature and accepts local input
smart radiator valves control individual heating zones
a mobile application exposes remote control and account functions
local wireless communication links devices inside the home
vendor services carry state and commands between the home and application
integrations such as Google Home or Amazon Alexa add another control path

That connectivity is useful, but each integration creates another trust relationship. A command to change the target temperature might originate from the physical controls, the mobile application, a voice-assistant integration, or an automated schedule. The security question is therefore larger than whether the thermostat itself has an obvious software flaw. It includes identity, authorisation, command integrity, device pairing, local traffic, application behaviour, availability, and the user’s ability to regain control after something goes wrong.

The client brief also connected smart-heating security to wider infrastructure changes. As heating moves towards electric systems and heat pumps, connected thermostats can influence increasingly significant household and grid loads. The consequences of failure are not limited to losing access to an application. Unauthorised temperature changes, loss of heating control, denial of service, or interference with zoning can affect safety, energy costs, comfort, and trust in the technology.

Defining the test boundary

The brief deliberately constrained the work to the local home-network side of the ecosystem. Attacking the vendor’s cloud services was out of scope, as was evaluating the protective capability of consumer routers and ISP-supplied hubs. This gave the team a controlled boundary around devices and services we were authorised to examine.

Within that boundary, we planned to establish how the components communicated and what normal operation looked like before attempting to change anything. That baseline was necessary for both attack-surface analysis and later comparison. If a device contacted a service, opened a local port, resolved a hostname, or exchanged commands with another component, we needed to understand whether that activity belonged to installation, routine telemetry, user control, firmware management, or an integration.

Our initial objectives were:

identify the thermostat’s supporting infrastructure and observable traffic;
document normal traffic and expected device behaviour;
build a threat model around the thermostat, valve, application, local network, and integrations;
investigate potential weaknesses and rank any verified findings by severity and impact;
explain how a weakness could affect the device, the household, and the wider service;
produce evidence suitable for client reporting and, where justified, responsible disclosure.

This was not an open-ended instruction to attack everything connected to the product. The scope, authority, and reporting route were part of the technical design.

Turning the brief into test questions

The client supplied a prioritised list of behaviours to examine. I used that list to help turn a broad request for “smart thermostat hacking” into testable questions:

Could an unauthorised local party turn heating on or off?
Could the target temperature be changed without the expected user action?
Could occupancy-related features be influenced or misreported?
Could content be placed on the thermostat display?
Could a user be locked out of legitimate control?
Could communication between the thermostat and radiator valve be interrupted or altered?
Could one component be denied service while the rest of the system continued to operate?
Did the mobile application introduce weaknesses around storage, transport, authentication, or command handling?
Did voice-assistant integration create a separate route to sensitive actions?

These questions covered confidentiality, integrity, availability, and safety in different proportions. Reading temperature telemetry is an information-exposure problem. Changing a heating schedule or target value is an integrity problem. Preventing the owner from controlling the system is an availability and potentially safety-related problem. A good test plan needed to record those distinctions instead of treating every observation as the same class of vulnerability.

The brief also asked for proof-of-concept evidence where appropriate. In project terms, that meant demonstrating a verified effect inside the authorised lab and capturing enough evidence for another reviewer to understand the result. It did not mean extending the work into cloud infrastructure or unrelated home-network devices.

Hardware and software workstreams

We divided the project into hardware and software workstreams so that the team could investigate different parts of the ecosystem without losing a single project view.

The hardware workstream was assigned to the thermostat and radiator valve. Its planned work included identifying exposed services, inspecting underlying technologies, observing device behaviour, and examining how the physical components communicated. The project plan listed Nmap as one of the intended discovery tools, but the objective was broader than running a port scan: the team needed to map observations back to a component, protocol, expected behaviour, and possible effect.

The software workstream was assigned to the mobile-application side. Its plan included the use of interception proxies to observe application traffic and distinguish normal exchanges from security-relevant behaviour. Application testing also needed to account for authentication, session state, command construction, transport protection, local storage, and the way the app represented device state to the user.

Separating the work reduced duplication, but it also created an integration problem. A command seen in the application might trigger traffic through several components before the thermostat changed state. The project manager therefore needed to keep the two streams aligned on terminology, timestamps, test conditions, and evidence. Otherwise, the software team and hardware team could describe the same event differently or miss the relationship between them.

Threat modelling the ecosystem

The threat model had to identify more than individual devices. I treated the thermostat system as a set of components and trust boundaries:

the user and their account;
the mobile device and application;
the local home network;
the thermostat;
the radiator valve;
vendor-controlled services outside our test boundary;
third-party voice-assistant integrations;
administrators, support processes, and firmware delivery.

From there, the research could ask where identity was established, where commands crossed a boundary, where state was stored, and which component trusted another component’s response. For example, a mobile application showing that heating is off does not prove the physical device accepted the same state. A command accepted by one local component may still require authorisation elsewhere. A device using encrypted transport may still expose metadata, weak pairing logic, replayable messages, or unsafe recovery behaviour.

The threat model also helped keep impact realistic. A finding would need to state the access required, affected component, user action, repeatability, resulting control, and likely household effect. A local-network observation should not be presented as an internet-wide compromise. Likewise, an application weakness should not automatically be described as control over the physical thermostat unless the effect was demonstrated.

Managing the engagement

The project plan used an agile delivery model. In practice, that meant breaking a broad research brief into short investigation tasks, reviewing evidence as it emerged, and changing priorities when one component depended on another. Security research rarely follows a perfect sequence: traffic inspection can reveal a new hostname, hardware behaviour can expose an undocumented dependency, and a client question can change which result needs evidence first.

I was responsible for the reporting chain. The hardware and software teams reported to me, and I reported consolidated progress to the client. Internal communication used Discord, while external communication used email and Microsoft Teams. That separation was part of practising professional delivery rather than treating the exercise as four people working independently.

Stakeholder analysis was also included in the plan. The direct stakeholders were PA Consulting Group, Abertay University, the student team, and the module lead. The brief also identified downstream client interest and the wider household impact of insecure smart-heating technology. Those groups wanted different forms of evidence:

the technical team needed reproducible observations;
the client needed prioritised findings and implications;
the university needed an academically rigorous process;
a manufacturer would need a concise disclosure with affected components and evidence;
household users would need risk explained in terms of control, privacy, availability, and recovery.

The expected client delivery was a 45-minute presentation followed by questions. The brief explicitly said that the audience would be cyber-aware but more interested in tangible results and implications than a recital of every command. That shaped how evidence needed to be recorded: enough technical depth to defend a conclusion, followed by clear explanation of impact and recommended action.

Reporting and responsible disclosure

The planned deliverables included a client presentation, the academic report, one or more manufacturer-ready vulnerability disclosures if findings justified them, and potentially a demonstration video. Each format served a different purpose.

A useful vulnerability record would need:

an affected component and version;
the conditions required to reproduce the observation;
the expected and observed behaviour;
evidence showing the effect;
an assessment of severity and practical impact;
relevant scope limitations;
remediation or further investigation;
a disclosure route and handling status.

That structure also guarded against overclaiming. Network traffic that looked unusual was an observation until the team could explain it. A failed request was not automatically a denial-of-service weakness. A controllable feature was not a security issue if the test used the expected authenticated path. The project plan therefore combined technical testing with evidence management and client communication.

The NDA and IP exercise

The module used NDA and intellectual-property handling to give the team experience of working under client-style constraints. It was a simulated professional process for the university project rather than an ongoing restriction on this portfolio summary.

I have kept the public page tied to evidence that is present in the retained brief and plan. It does not publish private contact details, unverified vulnerabilities, manufacturer disclosure material, or results that are not available in the archive. That is normal evidence discipline, not an attempt to hide the nature of the work.

What I developed through the project

The project combined IoT security with delivery responsibility. Technically, I had to reason about an ecosystem rather than a single host: device communication, mobile control, local traffic, integrations, command paths, availability, and physical effect. As project manager, I also had to turn that scope into assigned work, keep two research streams coordinated, manage stakeholder expectations, and prepare evidence for a client audience.

It gave me direct experience of the work around a security assessment as well as the testing itself: defining authority, controlling scope, establishing a baseline, separating observations from findings, ranking impact, maintaining a reporting chain, and planning responsible disclosure. Those are the same disciplines needed when engineering, investigative, and offensive work meet in a real engagement.