How to Update ESPHome Devices Safely After the 2026.9 Security Changes

Why this update deserves more care than a normal monthly upgrade

ESPHome updates are usually pleasantly boring. You validate the YAML, compile the firmware, upload it and watch a temperature sensor or relay return to service. Version 2026.9 deserves a more deliberate approach because it changes the security available for the update channel itself. The official release added encrypted OTA transfers, meaning the firmware image can be protected while moving across your network rather than merely checking a password before accepting it.

The distinction sounds academic until you remember what a compiled image can contain. Depending on the configuration, it may include Wi-Fi credentials, API encryption material, fallback access-point details, service names and enough information to make a compromised local network considerably more interesting. A strong OTA password is still useful for older configurations, but authentication and confidentiality are different jobs. The new encrypted path addresses both.

The awkward part is migration. Firmware older than 2026.9 cannot offer the new encrypted OTA method. If your YAML demands encrypted OTA before the installed device knows how to provide it, the command-line tool should refuse to fall back to plaintext. That refusal is the safe behaviour, but it can surprise an owner who changed every node at once and now has to find USB access to sensors hidden behind furniture, above cupboards or inside project boxes.

The right response is not panic or a whole-house update marathon. It is a two-stage migration, performed first on a device you can physically reach. The official ESPHome 2026.9 release notes and encrypted OTA documentation describe the underlying change. This guide turns that into a practical household workflow.

Before touching YAML, inventory the devices you actually own

Open ESPHome Device Builder and make a short list rather than clicking “update all”. Record each node’s hostname, board type, physical location, purpose, current status, current ESPHome version and whether you can connect a USB cable without dismantling half the room. Mark any device that controls heating, ventilation, pumps, gates, alarms, lighting needed for safe movement or something another person relies on.

Then classify the fleet into three groups. Group A contains accessible, non-critical test nodes: a desk sensor, development board or spare plug-in monitor. Group B contains useful but recoverable devices, such as room sensors and Bluetooth proxies. Group C contains awkward or important nodes: loft sensors, ceiling-mounted presence detectors, embedded controllers and anything whose failure would make the household less safe or comfortable.

Do not begin with Group C because it has the most impressive uptime. Begin with Group A because a failed migration should cost ten minutes and a USB cable, not a stepladder, a dark hallway and language unsuitable for a family publication.

This inventory also reveals forgotten devices. A node may still be online while its source YAML is missing, its secrets have moved to another computer or its board definition was copied from an old tutorial. Fix those administrative problems before upgrading. A green dot in a dashboard is not a backup.

Back up configuration, secrets and the current working state

Keep a copy of every device YAML file, shared package, substitution file and secrets.yaml used to build the fleet. If ESPHome runs as a Home Assistant add-on, include the relevant configuration directory in a proper Home Assistant backup and export that backup somewhere beyond the same storage device. If you use the desktop Device Builder, containers or a command-line installation, copy the project directory and record the ESPHome version that currently builds it successfully.

Secrets require special treatment. Do not paste API keys or OTA passwords into a chat, issue tracker, screenshot or public repository. Store them in secrets.yaml or another appropriate secret store and back them up securely. The encryption key already paired with Home Assistant is particularly important. Generating a new key because the old one is inconvenient can lock Home Assistant out until the integration is repaired.

Take a screenshot or text export of the device page showing its IP address, Wi-Fi signal, uptime and current firmware version. Save a few minutes of logs from a normal working period. This gives you a baseline after the update. If the node reconnects but a sensor begins returning nonsense, you need more than “it came back online” to decide whether the migration succeeded.

For important devices, also record how to reach the physical reset and USB connection. Note the correct cable and whether the board uses USB-C, Micro-USB, a serial adapter or exposed programming pins. You do not need to buy a dramatic repair kit. You need to know whether the cable in the drawer actually carries data.

Understand the three credentials people commonly confuse

An ESPHome setup may contain several protections that sound similar while doing different work. The Wi-Fi password gets the device onto the network. The native API encryption key protects communication between the ESPHome node and Home Assistant or another API client. The older OTA password authenticates firmware uploads but does not encrypt the firmware image in transit.

With ESPHome 2026.9 or newer, the ESPHome OTA platform can use Noise encryption. For a normal Home Assistant-connected node, the recommended arrangement is to reuse the existing native API encryption key. That leaves one per-device key to protect both API communication and OTA transfer rather than creating another secret to lose.

A typical final structure looks like this:

api:
  encryption:
    key: !secret hall_sensor__encryption_key

ota:
  - platform: esphome
    encryption:

During the first migration step, however, the installed firmware still expects the old OTA method. Keep the existing OTA password until the device has been updated to firmware that can offer encryption. Do not put password: and encryption: together in the final OTA block; they are alternative modes, not a belt-and-braces combination.

MQTT-only devices need extra care because they may not have a native api: block whose key can be reused. Follow the official migration instructions for devices without the native API rather than improvising a new key halfway through. The goal is to preserve a known route from the old firmware to the new protected state.

Stage one: install firmware that can offer encrypted OTA

Choose one Group A device. Update your ESPHome build environment to 2026.9 or newer, but leave the node’s existing OTA password in place. Confirm that the native API encryption key in the YAML is the same key already used by Home Assistant. If Home Assistant provisioned the key, copy that existing value into the YAML through your secret file if necessary; do not casually generate a replacement.

Validate the configuration before compiling. Read every warning rather than treating a successful build as permission to ignore the yellow text. ESPHome 2026.9 also tightened or changed some options outside OTA, including parts of Modbus Controller configuration and validation for certain UART sensors. A warning or validation error may be unrelated to encryption but still needs a deliberate fix.

Compile and upload the first-stage firmware using the current working OTA password. Keep a live log open. The device should reboot, reconnect to Wi-Fi, reconnect to Home Assistant and resume publishing sensible values. Look for the message indicating that encryption is offered while plaintext remains accepted. The exact log text documented by ESPHome is Encryption: offered, plaintext accepted.

Do not move immediately to stage two. Leave the device running long enough to exercise its normal job. Trigger its binary sensor, compare its temperature reading with another device, switch its output if safe, and watch for reconnect loops. If it uses Bluetooth proxying, wait for advertisements to appear. If it sleeps, allow at least one complete sleep and wake cycle.

Stage two: require encryption and remove the old OTA password

Once the test device is definitely running ESPHome 2026.9 or newer and offering encryption, edit the OTA block. Remove the password line and add the encryption block. Validate again, compile again and perform the second OTA install. This time the uploader should use the encrypted channel, and the device should report that encryption is required.

After reboot, check for Encryption: required in the logs. Confirm that Home Assistant still sees the node without asking for a new API key. Run the same functional tests used after stage one. The point is to prove that the update path is protected and that the device’s actual purpose still works.

If the tool says the device did not offer encryption and refuses to send the image in plaintext, stop. That usually means stage one did not land, the wrong host was targeted or the running firmware is older than expected. Do not weaken the config merely to make the error disappear. Restore the first-stage configuration with the original password, confirm the device version and logs, then repeat the migration correctly.

If it asks for the old password when you have already removed it, you probably tried to skip stage one. Put the old password back in the configuration and install the transition firmware first. Security migrations are unforgiving of missing steps because being forgiving would recreate the downgrade path they are designed to close.

Use logs as evidence, not decoration

A successful upload message proves that bytes were transferred. It does not prove that the device is healthy. Read the boot log from the beginning. Check the board, framework and firmware version; reset reason; Wi-Fi connection; IP address; API connection; OTA state; sensor initialisation; available memory; and any repeated warnings.

Compare the new log with the saved baseline. A slightly different memory figure can be normal after a platform update, but repeated watchdog resets, failed component setup or rapid reconnects are not. If an ESP8266 node is already close to its flash or memory limit, security improvements and component changes may expose a configuration that has no comfortable headroom. Remove unnecessary components and verbose diagnostics rather than pretending a marginal build is reliable.

Safe mode can help recover a node that repeatedly fails during normal boot. ESPHome’s OTA component enables safe-mode support by default, allowing a device to start with most components disabled while retaining networking and OTA access after repeated failures. It is useful insurance, not a substitute for physical access. Network settings, a bad board definition or a power problem can still prevent recovery.

For a relay or actuator, test fail-safe behaviour too. Confirm what the output does during reboot, after Wi-Fi loss and if Home Assistant is unavailable. An encryption migration should not silently change a heater, fan or light from a sensible restored state to an unsafe one.

Roll out in batches that preserve household function

After the accessible test node has survived both stages, migrate a small batch of similar devices. Similarity matters because devices built from the same package or board family are likely to share problems. Update two or three nodes, verify them and pause before continuing.

Do not update all Bluetooth proxies together. Keep enough old, working coverage to observe sensors while the first proxy is tested. Do not update every room sensor before a heating schedule needs them. Do not update the controller and the only device that monitors it in the same batch. Redundancy is useful only when you avoid rebooting all of it simultaneously.

Schedule important devices when someone can monitor the outcome and when a short outage is harmless. Autumn is a poor time to discover that the loft heating sensor needs a serial flash at midnight. For inaccessible nodes, consider delaying the migration until you can safely reach them or until another maintenance task already requires access.

Keep a checklist with four states: backed up, stage one complete, stage two complete and function verified. A device is not complete merely because its YAML now contains encryption:. The running firmware and the post-update tests are what count.

Common mistakes and the calmer alternative

A practical recovery ladder when an update goes wrong

1. Wait and observe. Some boards take longer to reconnect after framework or build-system changes. Watch router leases and serial logs if available.
2. Power-cycle once. Use a controlled restart rather than repeatedly flicking power. ESP8266 boards may need a reset after serial flashing before OTA works normally.
3. Try safe mode. If the device is rebooting repeatedly but networking returns, safe mode may expose an OTA window for corrected firmware.
4. Restore the last known-good configuration. Rebuild it with the correct ESPHome version and existing credentials.
5. Use the physical serial path. Connect the device locally and flash a known-good image. Do not do live mains work to reach an embedded controller.
6. Re-adopt only when necessary. Treat deleting integrations, generating keys and rebuilding entity identities as a last resort because it can break automations and history.

If the device is connected to mains voltage, built into a fixed appliance or installed where access is unsafe, stop before dismantling it casually. Secure firmware is worthwhile. Electrocution remains an extremely robust denial-of-service attack.

Final checklist

• Inventory devices, versions, locations and physical recovery access.
• Back up YAML, packages, secrets and the working build environment.
• Preserve the API key already paired with Home Assistant.
• Start with one accessible, non-critical device.
• Keep the old OTA password for the first update to 2026.9 or newer.
• Confirm logs show encryption is offered and normal functions still work.
• Replace the OTA password with the encryption block.
• Install again and confirm logs show encryption is required.
• Test sensors, outputs, reconnects and fail-safe behaviour.
• Roll out in small batches while retaining known-good coverage.
• Keep a serial recovery route for awkward or important devices.

The security improvement is real, but the safest update is the one you can explain, verify and reverse. A fleet of tiny boards should not become mysterious merely because it is automated.

Related DigiTech guides

• How to Fix Home Assistant Bluetooth Dead Zones With an ESPHome Proxy
• How to Audit Smart-Home Automations Before the UK Clocks Go Back
• How to Make Smart Lighting Work When the Internet or App Goes Down
• How to Photograph and Label a Gadget Teardown Before a DIY Repair

Editorial notes

Lightweight UK trend research compared three timely areas: ESPHome’s September encrypted-OTA release and active Home Assistant community interest; autumn heating and smart-thermostat buying interest after the October energy-price change; and repair/reuse interest ahead of International Repair Day on 17 October 2026. Heating controls were commercially active but DigiTech has recently covered radiator valves, energy monitoring and clock-change automations. Repair culture had a strong seasonal hook, but recent DigiTech articles already covered repair decisions, bench preparation and teardown documentation.

The ESPHome security migration offered the clearest fresh utility: it is based on a current official release, solves a specific risk for DIY smart-home owners and is materially different from the recent Bluetooth-proxy placement guide. The editorial rotation guard reported three product-led and five utility-led posts in the latest eight, so a product article was not required. DIY Electronics was not yesterday’s category and was the least recently used category in the latest seven posts.

This article contains no affiliate links. The task is a software and credential migration, and forcing a board, cable or tool recommendation into the workflow would not improve the advice. Readers should use the known-good data cable and recovery hardware appropriate to their existing board.

Review freshness

Last reviewed: 9 October 2026

Update cadence: Review after major ESPHome OTA, encryption, safe-mode or migration changes, especially the planned removal of older plaintext fallback paths.