I build and lock down ESPHome scenes the same way I build servers: no glamour, no cloud dependency. Start with a clear threat model. Decide what data needs to leave the device and what stays local. Pick one control channel for scene triggers and stick to it, either the Home Assistant API or MQTT with TLS, not both unless there is a good reason.
Start at the device. Change the default WiFi credentials and give each device a unique password. Put devices on a separate IoT network or VLAN and clamp that network with firewall rules so it cannot reach the main network. Keep passwords and keys in secrets.yaml, not in the YAML itself. Set an OTA password and an API password in the device config. If MQTT is in use, run it with TLS and client authentication. Do not leave broker ports open to the internet. Turn off mDNS on devices that do not need local discovery. Disable telemetry or cloud integrations on the device side. For small examples, add api: password: "long-random-string" and ota: password: "another-long-string" to the device YAML, then reference the values from secrets.yaml. Use static IPs or DHCP reservations so firewall rules and monitoring stay reliable.
Scene design matters too. I build scenes in Home Assistant and trigger them from ESPHome devices with the API or MQTT commands. Keep scene state machine logic in the controller, not on the ESP device, unless the scene has to run without the controller present. For light scenes, store the intended brightness and colour in Home Assistant scenes and expose only switches or buttons from ESPHome. For battery-powered or offline-capable devices, put the fallback behaviour into the ESP YAML: set a safe default on boot with on_boot then publish a retained status so the controller knows the device state. Avoid sending raw sensor streams, images, or audio unless the local network is locked down and the data is encrypted in transit and at rest.
Monitoring and management reduce risk more than one lock ever will. Add an uptime sensor and a last-seen timestamp to each ESPHome device. Use the native status sensors so flapping devices show up quickly. Keep OTA on, but limit it to the IoT network and require the OTA password. Log to local systems, not external cloud services. If a device starts failing OTA repeatedly, the usual culprit is WiFi or power. I would start with a better power supply, shorter data lines, and a stable 3.3V rail for the ESP32 or ESP8266. If WiFi is flaky, move the access point closer or add a mesh node. For persistent failures, compile with a watchdog restart handler so the device reboots into a known state instead of sitting there doing nothing useful.
Network controls matter as well. Run a local DNS blocker like Pi-hole to cut down outbound telemetry domains. Use firewall rules to block device-initiated connections to unknown endpoints. Keep MQTT message retention minimal, and do not publish sensitive tokens as retained messages. Client certificates give stronger broker auth than passwords if you want that extra step. Keep the ESPHome toolchain and firmware up to date and read the release notes for security fixes. I treat each device like a host that matters: strong credentials, limited network access, and health checks that actually get looked at.
Takeaways: treat scene triggers as control-plane traffic and keep them on a segmented network; use secrets.yaml and per-device passwords; prefer local controllers and TLS for MQTT; add health sensors and watchdogs for recoverability; keep data off the local network where you can. That keeps the smart home useful without leaving it wide open.
