In today’s connected world, even something as simple as a thermostat relies on the Internet—and that dependence introduces real security risks.
I decided to find out the hard way.
The Experiment: Restrict Everything, Then Allow What’s Needed
I have two popular smart thermostats in my home. A few years ago, as part of a personal project, I wanted to see if I could restrict their outbound network access—essentially, implement a basic form of Zero Trust.
Using my home firewall, I blocked all outbound Internet traffic from the thermostats. They immediately dropped offline in the mobile app and stopped reporting any data. So far, so good: obviously, they were cloud-dependent.
The Support Spiral Begins
Next, I contacted the vendor’s technical support to ask for a list of IPs or domains the thermostat needed in order to function properly.
Me: I’m trying to limit Internet access. Can you provide the IP addresses or domains the thermostat uses?
Support: Uh… just make sure ports 443 and 80 are open.
When I pushed for specifics, they eventually said:
“Just put it in the DMZ so it can talk to everything.”
That’s not Zero Trust—that’s zero security.
Turning to Packet Captures
I mirrored the thermostat’s traffic to a monitoring port and ran packet captures over a few days. Here’s what I found:
-
NTP (network time) servers
-
Cloud services—probably AWS or Azure
-
Analytics and telemetry domains
-
Push notification systems
I built an allow-list based on this traffic and updated my firewall rules. But things were still flaky: mobile commands failed, firmware updates didn’t apply, and the sensors would randomly desync.
What I Learned
This experience confirmed three things:
-
Vendors rarely provide visibility into their products’ network dependencies.
-
Packet analysis is tedious and fragile—it’s not something most users can (or should have to) do.
-
Device behavior is dynamic, especially with third-party cloud services. Today’s domain could change tomorrow.
The Bigger Problem
If I, a security professional, struggled to lock down two thermostats without breaking them, what chance does the average homeowner or small business have?
This is why I started working on a solution: the Network Bill of Materials (NetBOM). Think of it as a companion to the SBOM (Software Bill of Materials), but for network behavior. A NetBOM provides a structured, vendor-supplied list of the domains, IPs, and services a device needs to communicate with on the Internet.
With NetBOM, instead of doing manual captures or begging support for documentation, you just import a NetBOM file into your firewall or security gateway and the system automatically builds the right policies. In a pinch, you could do it manually, but at least you have the information you need to secure your network.
Final Thoughts
IoT security isn’t just a big-company problem. It’s everyone’s problem—from homeowners to hospitals to high-tech manufacturers. We all deserve transparency and control over the devices we rely on every day.
NetBOM is a step toward making that vision real.
Want to learn more? Check out the NetBOM white paper.
If you want more details about my attempt to lock down the thermostats, read this blog.