Home Assistant 2026.9: Stop Seeing 127.0.0.1 in Your Invalid-Login Alerts

Your failed logins finally show the real attacker IP instead of 127.0.0.1, and HA's security dashboard tells you what's actually on fire — in a weekend afternoon. Home Assistant 2026.9 (released Sep 1–2, with patch 2026.9.1 shipped Sep 5) is the release whose headline changes are literally about login visibility and alerting, so this tutorial turns them into working configuration instead of changelog trivia.

Before you start//

• Any Home Assistant install (OS image or container), on any version — but see Step 1 about skipped releases.
• ~30–45 minutes, mostly UI navigation. Comfort with Settings menus; no YAML required unless you already have an auth_mfa_modules section defined (covered in Step 2).
• Blast radius: one restart if you touch configuration.yaml for MFA (only needed when a custom auth_mfa_modules block exists — TOTP autoloads otherwise); everything else is additive UI config. Take an HA backup before upgrading if you're behind multiple releases; nothing here modifies your data.

Step 1: Update to 2026.9.x and read what broke//

Then open the backward-incompatible changes section of the release notes — it has real entries this time: the deprecated Flexit Nordic (BACnet) fireplace mode switch was removed (use climate.set_preset_mode with preset_mode: fireplace on the Flexit climate entity instead), and KNX exposes no longer send an entity's first value to the bus. There are two more that matter if you've built LLM automations or notification triggers: LLM tool names now carry a domain prefix (GetLiveContext becomes homeassistant__GetLiveContext, so any custom prompt naming a tool directly needs updating), and persistent notifications being updated now report update_type: updated instead of added. Why: if you've skipped releases, each one carries its own section like this — read them in order before upgrading. That's where "my automation stopped working after the update" gets answered.

Step 2: TOTP MFA via profile → Security tab//

Per the current MFA docs (version 2026.9.1): if no auth_mfa_modules section is defined in configuration.yaml, a TOTP module named Authenticator app autoloads — just hit Enable, scan the QR into your authenticator app (Google Authenticator or Authy per the docs), and enter the six-digit code to confirm. If you do have an auth_mfa_modules section already, add the TOTP entry there instead:

homeassistant:
  auth_mfa_modules:
    - type: totp

then restart HA before doing the UI steps above. Why: MFA is a second factor on exactly the login bots hammer — and note the docs path, because it's your user profile's Security tab, not some "Settings → Users" page. One gotcha straight from the docs: TOTP is time-based, so if verification keeps failing, check that HA's clock is actually right.

Step 3 [CLOUD]: confirm real IPs in invalid-login attempts (and ban them)//

Before 2026.9, every failed Cloud login was logged as coming from 127.0.0.1, so a mistyped password and a bot were indistinguishable in the log. In 2026.9 the release notes say the proper IP address now gets passed through for Cloud subscribers. The side benefit, per the release: that's what makes the IP-ban UI (added to web-server settings in 2026.8, including trusted proxies) actually usable for Cloud logins — you can ban the bot's real address instead of your own router. Why: a login log that says 127.0.0.1 is telling you where HA lives, not who's knocking.

Step 4: Security dashboard — active alerts and favorites//

New in 2026.9, both managed from the same editor on the built-in Security dashboard (release notes):

• Active alerts — a section that only appears when something actually needs attention. You choose which entities can trigger it, and rate each one as an Alert or a Warning, so an open window doesn't get the same red treatment as a smoke alarm. Nothing going on? The section stays out of the way entirely.
• Favorites — pin the doors, locks, or sensors you check most to the top of the dashboard instead of wherever they happen to fall.

Open your Security dashboard, enter its editor, and configure both sections with the entities that actually matter in your house (door sensors, smoke detectors, locks). Why: until now this page was a static checklist; these two sections make it reactive — which is what "dashboard" should have meant all along.

Step 5: Activity's "why it changed" + the Sources pane//

When something changes unexpectedly, Activity used to show what and then make you guess which automation was responsible, open it, dig through its trace, and work backward. Now selecting any row opens a details dialog with the full chain: what started it (a person, a state change, a schedule, an integration, or a restart), every automation or script it passed through, and finally the entity's own change — each step clickable (automations go straight to their trace), timestamps down to the millisecond.

The Sources pane is the other half: History and Activity now share a single panel on the left that merges target picking (floors, areas, devices, entities) with filtering by domain, device class, and integration — so you can narrow a whole area down to just its motion sensors. Whatever you filter on is remembered the next time you come back. Why: "why did my light turn on" used to be an archaeology project; now it's one click per row.

Verify it worked (non-negotiable)//

1. The bad-login test [CLOUD]: from your phone on cellular (not home Wi-Fi), deliberately enter a wrong password at the HA login. After 2026.9, the attempt should surface with your real external IP instead of 127.0.0.1 — and if you've configured active alerts for auth-related entities in Step 4, an alert should appear. (Non-Cloud: verify MFA fires on your next login and that the Security dashboard + Activity work; the real-IP part is a Cloud feature.)
2. The trace test: manually trigger an automation you know (one with a "Run now" action), then open Activity, find the row for the entity it changed, and click it — the details dialog should render the full chain: your manual trigger → the automation → the state change, in millisecond order. If the chain renders top to bottom, the feature is doing its job.

When it breaks//

1. Cloud-only steps invisible to non-subscribers. IP pass-through and the ban workflow are Cloud features; local installs get MFA + Security dashboard + Activity but not the real-IP login log. Rollback: nothing — these are additive features, and a 31-day trial (no payment details) is how you test them before committing.
2. Upgrade breakage from skipped releases. If you jumped multiple versions, each release's backward-incompatible section is where your broken automations' answers live (this one: Flexit BACnet fireplace switch removal, KNX expose first-value behavior — Step 1 and the full changelog). Rollback: restore an HA backup or install the previous stable via Settings → System → Updates.
3. Don't build on the new voice processing. The Soniox speech-to-text engine is being tested in Labs (Settings → System → Labs) for Cloud subscribers — same no-logging/no-training privacy guarantee, but it's explicitly "may not be a permanent addition." Sidebar at most; don't wire your morning routine to it yet.