Home Assistant's Pwned Password Check Is Now Off by Default. Should You Turn It Back On?

If you run Home Assistant OS, a security check you probably never knew about just got switched off. Supervisor 2026.10.3, released October 19 and now the stable-channel version, lists it under breaking changes: "Make pwned secrets check opt-in."

The check compared the passwords in your apps (the things that used to be called add-ons) against Have I Been Pwned's list of leaked passwords. It did that quietly, by default, for years. Now it doesn't, unless you ask.

I think the new default is right. I also think a lot of people should turn it back on. Here's why both are true.

What the check actually sent

Short answer: not your passwords. Home Assistant's pwned passwords page walks through it. Home Assistant makes a SHA-1 hash of each password, sends only the first 5 characters of that hash to the Pwned Passwords service, gets back every leaked hash that starts with those 5 characters ("usually hundreds"), and does the final comparison on your own machine. That's called k-anonymity. The service can't tell which password you checked.

What gets checked: the password fields in your apps' configuration, plus any password an app reads from secrets.yaml. Think Mosquitto broker logins, the Samba share, that sort of thing.

So the privacy risk was small. The complaint wasn't really about the math. It was about consent. The GitHub issue that kicked this off, filed October 16 on 2026.10.1, is titled "i never authorized an integration that scans my secrets." The pull request that flipped the default agrees with that framing: even with k-anonymity, "it sends data derived from users' secrets to a third-party service without their explicit consent."

Why people only just noticed

One of the Supervisor maintainers pointed out in the PR thread that this "has always been the case. The results were not properly processed." That was fixed in PR #7294, merged October 6. Its description says pwned hits were being swallowed in the default configuration, so the check never actually created a warning.

My read of the timeline, and it is only my read: the check had been running for years without telling anyone anything. Then a bug fix made the warnings start showing up under Settings > System > Repairs, people saw "Insecure secrets detected in app configuration," asked what on earth was scanning their passwords, and within two weeks the default was off.

Who this affects

Only installs that use the Supervisor, which means Home Assistant OS (Green, Yellow, a Pi image, a VN). The docs say Container installs "don't have apps and don't run this check."

If you're on HA OS, what happens after the update depends on one file:

You never touched security settings. Almost everyone. The check is now off.
You ever saved a security option from the command line. Your saved value stays. A maintainer noted in the PR that saving any security option wrote the whole file, so a few people may have the check stuck on without ever choosing it. That group is "likely very, very small".

Should you turn it back on?

If your apps use passwords you made up years ago, or passwords you also use somewhere else, yes. I'd turn it on. The data that leaves your house is 5 characters of a hash, and what you get back is a warning that a password matches something in a breach list. That's a good trade.

If every app password is a long random string from a password manager, the check isn't going to find anything, and leaving it off costs you nothing.

To turn it on, open the Home Assistant command line (the Terminal & SSH app works) and run:

ha security options --pwned=true

To turn it off explicitly:

ha security options --pwned=false

If it does flag something, the repair names the app but not which password, because the check only compares hashes. Home Assistant's page suggests replacing the short, common or reused ones first, and replacing all of them if you can't tell. Change it in the app's Configuration tab, or in secrets.yaml if that's where it lives, update every device that logs in with it, then restart the app. The warning clears within about an hour.

The other change: integrations have categories now

Same week, different team. The Home Assistant contributors blog announced on October 20 that integrations now carry purpose categories: 28 of them, like Lighting, Climate and Energy, most with subcategories such as Energy > EV charging. Every core integration lists one to three in its manifest. The point is finding things by what they do, not by their name.

For regular users it shows up first on the integrations page at home-assistant.io. The bigger reason it matters: "Next, the Marketplace browses by them too." That's the built-in Marketplace replacing HACS, which I covered in my 2026.10 rundown.

If you maintain a custom integration, add the categories key to manifest.json now:

{
  "categories": ["energy.ev_charging"]
}

It's optional for custom integrations, but the blog says the HACS action "warns when the key is missing, and fails on an unknown category." Five minutes now means your integration lands in the right aisle on day one of the Marketplace instead of in a pile at the back.

What I'd do this week

Update the Supervisor if it hasn't updated itself.
Decide on the pwned check on purpose. If you reuse passwords anywhere in your apps, run ha security options --pwned=true.
Check Settings > System > Repairs. If an "Insecure secrets" warning is already sitting there, believe it and change that password.