Introduction and context

A few weeks ago, I was brought in to architect and deploy a client infrastructure that includes Home Assistant. While evaluating the tech stack and the requirements, I realised that the underlying architecture of Home Assistant demanded deep technical review. My perspective is that convenience choices made by the developers put users and infrastructure sovereignty at risk.

Security professionals must evaluate these platforms, designed for hobbyists, with strict scrutiny rather than accepting default deployment scripts.

What I found

HAOS is not Home Assistant. Home Assistant Operating System (HAOS) is a specialized, lightweight buildroot-based Linux system designed to run Home Assistant. Its core components include a Buildroot-based Linux system, Docker container engine, bootloaders (GRUB/U-Boot), RAUC for updates, and AppArmor for security.

Home Assistant relies on Docker containers to run. This means that HAOS is not only a Linux distribution in the traditional sense, but rather a container orchestration system for Home Assistant.

The core risk manifests within the official deployment configuration. The deployment model requires the primary container to execute with the privileged: true flag, network_mode: host, and the default user is root.

services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /PATH_TO_YOUR_CONFIG:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
    environment:
      TZ: Europe/Amsterdam
  1. The configuration maps the host D-Bus socket /run/dbus directly into the container to control hardware communication protocols like Zigbee, Matter, or Bluetooth. This design choice creates a way to escape the container.
  2. The application executes as the root user inside the container. Because namespaces are not remapped by default, root inside the container matches root on the host operating system.
  3. Exposing the system D-Bus allows any process inside the container to transmit arbitrary instructions to the host systemd daemon and NetworkManager. It becomes easy to disable firewalls or start malicious services on the host.

Understanding the impact, severity and scope

Users frequently install custom integrations pulled directly from unverified, community-maintained repositories, via the Home Assistant Community Store (HACS). As easy as a click of a button. No security validation happens before installation. This pattern introduces a high risk of supply chain attack. A single compromised addon or dependency grants an external actor full root privileges over the entire local network segment.

Hobbyist operators often operate under the comforting illusion that their local network is an island. Well, to me, Home Assistant is a threat to privacy and security.

  • Home Assistant and its addons manage display, archive data, watch baby monitors, cameras, microphones and other lights and sensors. A total access to exploit one's privacy.
  • Home assistant controls door locks, garage doors, gates and other alarms. Making it able to let anyone inside your house.
  • Home assistant is given access to multiple devices and appliance on a site. Allowing full control over the environment, computers included.

In other words, installing HAOS in a network without proper control exposes the entire network and the privacy of every member.

Sovereignty is a method, not a gift.

Coverage

From developers

The Home Assistant developers are aware of the issue. In fact, if one tries to run Home Assistant without these permissions, the software will flag the system as "Unhealthy" or "Unsupported" in the settings dashboard. They argue that because HA must control local hardware directly (Bluetooth adapters, Zigbee USB sticks, network interfaces for device discovery), it cannot function inside a locked-down sandbox.

They consider the problem as a non-qualifying vulnerability for their security and do not accept reports about it because they openly designed it to have host root access.

Translation:

We made it to be easy, not to be secure. So you can't complain about security vulnerabilities

This operational philosophy of "convenience-first" is a persistent vulnerability and contradicts standard security and IT operations frameworks that often mandate explicit change enablement and continuous boundary validation.

Broader community

I am not the first to bring up this concern and I am certainly not the first to share my frustration over a lazy Docker design.

In fact, just a week after I left the site, the CVE-2026-34205 was published with a critical severity score of 9.8. The details attached to this CVE show how no authentication is required and user impersonation is achieved.

Actions and recommendations

Securing the infrastructure requires a defensive approach due to, as said above, the HA server must be considered untrusted, compromised.

  • DO NOT share the host for any other usage than Home Assistant.
  • Isolate the host as much as possible via network segmentation.
  • Place the host behind a proxy to handle external access.
  • Place the host behind a reverse proxy to limit direct access.
  • Manage your own mDNS repeater.
  • Firewall policies must restrict traffic:
    • Allow connections to initiate only from the trusted user network to the Home Assistant host on the specific web port TCP 8123.
    • Explicitly block the automation VLAN from initiating any connection back to the trusted network.
  • Continuously monitor and alert.
  • Reduce the surface of attack by limiting HA's scope to strictly to its core: reading sensors and executing some lightweight local automations.

What NOT to do

  • Downplay the risk: The threat remains real. A compromised automation server provides an immediate ground for lateral network activity.
  • Think binary: Security does not operate as an all-or-nothing philosophy. It requires organisation, anticipation, structured governance, continuous risk mitigation, and systemic control.
  • Leave Home Assistant on your home network without isolation: Exposing your primary workstations and users to a privileged container environment opens the door to failure.
  • Install more because it's fun: Security is not about fun. It's about responsibility. Only install what HA is made for. No custom addons.

Acknowledgements

This analysis was made possible because of the open-source nature of the project. Contributors who maintain the transparency of the Home Assistant codebase, allow security professionals to inspect the underlying mechanics and verify root causes. While I don't agree with their operational philosophy, we must respect their transparency.

Conclusion

Moving forward, I will not include Home Assistant in any office or residential infrastructure under my management. The risks outweigh the benefits. It's a fun project for those who enjoy playing around, but not a solution that can be trusted. I will stick to professional implementations and operations.