Bit of background:
I am new to Home Assistant in 2025 (loving it so far), and relatively new to “proper” network management after finally taking the dive into Unifi in October 2024. I am, admittedly, quite proud of what I have learned and implemented so far, and the learning never ends. However, while proud of my progress, I have much to learn still; as a result, please pardon an oversight or ignorance in my question.
Current Setup:
HA installed on miniPC via HAOS on my IoT VLAN (along with all my IoT devices)
Pixel 8 running Android 15
I am currently looking at a more efficient way of home/away detection that doesn’t require location sensor on Companion App to be on all the time (I tried Wi-Fi connection sensor within the app, but it seems the entity does not update in a timely manner in the background unless I also have Background Location enabled as well).
I’m interested in the Unifi Integration that allows me to use connected clients as device tracker, and I am aware of the guides and setting it up. Instead my question lies in the security of adding such an integration; and I wonder if I am overthinking or simply wrong. For said integration, you require an admin account of read//write privilege (I opt for read-only); while unable to change anything, this account can read everything within your Unifi console (unmask VPN keys, SSH keys if you use, public IP address, etc). Therefore, if an IoT device on that VLAN becomes compromised, while contained within the IoT VLAN with firewall rules, it can now still access your unifi console with the read-only admin account via HomeAssistant.
Is this not a large security issue? We spend time locking down the IOT VLAN, including blocking access to the gateway itself (except for DNS requests on 53 and 443), but now via HA we open the front door into the unifi console?
Thank you for taking the time to read my post and help me further my understanding and knowledge
In security circles, P yes I would consider a compromised HA machine with Access to a UniFi installation a risk to that UniFi install.
Reason. I have credentials as an admin and I have ssh access to the network controller
Done. Game over.
That Op. Is for you to decide if it’s ‘less secure’
So. The risk. Yes it exists.
Aaaaand, Yes I think you’re over thinking it because they’re already in and honestly I’m not going for your core router if I have that kind of access. You’re not a nation state where I want to leave a present. I want a smash and grab lock up malware drop with bitcoin on the back end. Or I want to suck up your creds for other services. Oh look all those files on the HA box I already have…
For me the convenience and control of what I can automate in my UniFi environment FAR outweighs the risk. Understand the risk and mitigate it.
Yes, but he’s talking about a compromised device. HA being compromised is a different story than an iot device being compromised. Devices don’t auth into HA, it’s the other way around. So I don’t see how a random device on the network can get access to HA’s information unless you give that device HA’s credentials.
That is true. I took it from the perspective of HA itself. Which of compromiseed is a risk but again one that can be mitigated. You are correct about the devices themselves.
Ok yes in theory I could load trojans on an esp32 device. And get you to adopt it. IF you then allowed the device to run automations in teh environment and the right condition existed they could fire something… But the case for that breaks down at so many spots… But… Hiiiiighly unlikely and a very slim potential vector for attack. (and op, one you can easily mitigate by not adopting rando esp32 devices, I only know of one current ZWave proof of concept compromise but it’s esoteric and doesn’t get a beach head. Use good secops on your wifi and internal segments and make sure your guest network can’t touch HA)
The communication between HA and UniFi is also encrypted over HTTPS so to get access to credentials you really have to get the configuration data from Home Assistant or its file system.
Ahhh I see what you’re saying. My perspective, while now seemingly over thought, is also overly simplistic as I don’t fully understand network “hacking”. Given my devices on the IoT VLAN, which includes my HA instance, can communicate with each other, I simplistically assumed that if, for example, lets say my smart AC is hacked (requires cloud integration), I thought it can free “travel” within the IoT VLAN to other devices via communication protocols/ports.
BUT, it seems that while within a compromised device on a VLAN, to access my HA, it will still require my HA credentials to “enter” my HA instance as HA is authed to the device (or in this example the cloud integration account), but it is not authed to HA. Is this a more correct perspective?
If by HA risk mitigation, you mean it’s not accessible via external address (VPN only) and accounts have 2FA?.. then yes, I’ve mitigated access risk to the HA itself. Let me know if I’m missing something…I am always open to more knowledge
Even more nuanced than that.
Let’s assume a device is on your network and it’s compromised. THAT doesn’t automagically mean it ‘infects’ everyone around it. It means there’s a compromised device there that can do a thing - that is a very specific thing too - most likely. Like look for something else it can compromise. With endgame being a machine, I can establish a beach head inside your perimeter and then run from.
In our earlier ESP compromise - lets assume I didn’t give that device access to run automations. It could still sit on the network and look for a way to compromise other things. Getting the user to do a dum or compromise their creds is the EASIEST way. (By far)
And yes, that’s exactly what mitigation is - how are you preventing the OTHER ways they could ‘get in’? We know if we compromise HA it’s game over. How do you prevent THAT? Ok we make sure we have no open doors - good passwords, use (NON-SMS) 2FA, etc, etc, etc.
Walk it backwards covering every scenario you come up with until you’re personally satisfied that you understand the prevention required and you’ve decided the measure at that level is too much trouble or too costly for what it gains you - that’s your security posture Good luck!
For the sake of conversation and learning (which I’m loving, and appreciate, btw), lets say we did give that Trojan ESP32 access to run automations. At the basic level it pushes entity updates to HA via TCP 1883/8883 via MQTT, but having this port access for pushing updates doesn’t automagically give it access into HA, and its data/filesystem or creds, itself; correct?
I appreciate your knowledge as to create, as you mentioned, my security posture, I love truly understanding how it all works to indeed work things backwards myself.
Bit of background:
Current Setup:
