Cloud dependency mapping — Identify which devices require vendor cloud infrastructure for core functionality versus those supporting local-only operation. Devices with mandatory cloud dependency introduce third-party breach risk independent of home network posture.
That is exactly the point I have been making.
A cloud dependency is not automatically a security advantage. It introduces an additional attack surface that exists independently of how well you secure your own network.
Local devices certainly still need to be secured properly, but with local-first operation I can control and restrict that risk myself through segmentation, VLANs, ACLs, firewall rules and local authentication.
With a mandatory vendor cloud, I additionally have to trust the vendor’s infrastructure, accounts, authentication, APIs and security practices — none of which I control.
That doesn’t mean “cloud = insecure”. It simply means that mandatory cloud dependency adds another security dependency, while local-only operation avoids that particular risk.
But that doesn’t matter if a device can’t do anything if it’s compromised. I mean: it doesn’t have access to the LAN or any other local device at all. The only thing it could do is become part of a botnet or become a residential proxy, which, since I check my DNS and firewall logs almost every single day, would get noticed instantly and then I can replace the device with a “clean” one within a few hours.
Don’t trust your IoT network. The devices are all very insecure, outdated firmware, etc. No local connections, no inter-device communications, the IoT network is just like the guest network, but with DPPSK instead of captive portal/voucher authentication (at least in my case)
VLAN isolation protects your LAN from a compromised device. It does not protect you from a compromised vendor cloud, account or API sending legitimate commands through the exact channel the device is supposed to trust — for example opening your front door or garage door.
And “I check my DNS and firewall logs every day” is not a serious counterargument for me. I build a smart home so I can enjoy it, not so I have to audit network logs every morning to make sure my toaster hasn’t joined a botnet. Edit: The Omada System features DPI, IDS/IPS, DoS/DDoS and Stateful ACL that work automatically.
Also, replacing the device only helps if the device itself is compromised. If the vendor cloud is compromised, replacing the device with another one using the same cloud changes absolutely nothing.
So yes, isolate IoT devices.
But no, that does not make mandatory cloud dependency harmless. It solves a different problem.
But when this occurs that the manufacturer’s online services are compromised, then still, what will the device do? If it’s compromised or every device on the service is compromised, it still can’t do anything other than control that single device. A hacker could turn a hacked light bulb on, off, dim it, mess with it, but not much more.
In a network where local connections are allowed, it could be much worse, since in that case it could also try to profile your network and infect other vulnerable devices.
The primary reason for doing it is because some devices on my network are known to contain serious vulnerabilities (like MAC-only authentication) or even backdoors, so I want to check it very often to know when they are compromised.
And you don’t have to look at it 24/7, I have my network traffic graphs and live DNS logs open in the background on my second monitor, enough for noticing any strange traffic, but I don’t have to focus on it the entire day
You are thinking far too narrowly.
In my case, a compromised cloud service could potentially mean:
opening the garage door
unlocking a door
disabling an alarm
accessing cameras or other sensitive devices
That is already far beyond “messing with a light bulb”.
And even a supposedly harmless compromised device can still be abused as a botnet node or residential proxy. Malicious traffic then originates from your internet connection, which can create very real consequences for you.
I don’t have such devices, Matter devices have no backdoor exposed to the outside as they work locally by design and acces from outside is blocked by propper VLAN configuration.
I deliberately avoid devices like that.
All of my smart-home devices are local Matter devices. They do not require a vendor cloud for their core operation, and with proper VLAN and firewall configuration they do not need unsolicited access from the internet either.
That is exactly the architecture I prefer: local control, network isolation, and cloud only where I explicitly want it.
But I’m going to stop this discussion here.
At this point, it no longer feels like an exchange of arguments. You seem determined to push your preferred cloud architecture as the answer, regardless of common IoT security principles or the external security guidance already quoted.
Matter says nothing about the device itself, only the protocol it uses to connect to a Matter-enabled smart home ecosystem. If the manufacturer themselves is malicious (which is the case with my smart camera), they can still put other methods of communication into the firmware, like a server connection.
All of my smart-home devices are cloud-connection IoT devices. They do not need any access to any device on the LAN, and with the proper client isolation and firewall configuration, they do not need unsolicited access to the local network either
And also: the more cloud-connected devices, the more interesting my traffic graphs become to look at
