Security
What is still open on your controller, and how to close it
Settings → Access → Security lists what is still unlocked on this controller and where to fix each thing. The same information reaches Home Assistant as a diagnostic entity, so a controller nobody visits can still say something.
Two lists, and the difference matters
Outstanding is a problem with this controller — the shipped broker password still in place, the panel reachable without signing in. Each entry has a Fix button that takes you to the control that changes it, or, where there is no control, the exact change to make by hand.
Worth considering is advice that applies to nearly every controller and depends on how you use the device. A self-signed certificate is the designed default, not a fault.
Only the first list drives the count beside Security in the sidebar and the Home Assistant sensor. A badge that is red on every device ever shipped is a badge nobody reads.
What is checked
| Check | Why |
|---|---|
| Administrator account | Without one, whoever reaches the first-run wizard takes the device |
| Unauthenticated access | Anyone on the network could read the configuration, switch outputs and reboot |
| MQTT broker password | The one every boneIO ships with is published and identical on every device |
Old credentials in config.yaml | The pre-1.6 web.auth block kept a password in clear text |
| HTTPS certificate | Self-signed means a browser warning on every visit |
| Embedding in other sites | Whether another site may put the panel in a frame |
| SSH login password | The boneio account can become root; the factory password Black (or none) means anyone who reaches SSH can too. With the factory password, Fix opens the SSH login password card in Accounts; with none at all, log in over SSH and run passwd |
| Operating system updates | Installed updates waiting for a restart, or a kernel that is not ready for the next boot (then: do not restart, contact support). Automatic security updates switched off is listed under Worth considering |
| Panel served in the clear | The panel's own port answers without encryption on the network — Move behind the proxy closes it |
| Development mode | BONEIO_DEV mounts development routes — correct on a development board, never on a shipped one |
Checks that pass are listed too, folded away. Seeing how many things were examined is what makes "two outstanding" mean something.
After an update
The first time you open the panel after an update, a prompt points at this section — but only if something is outstanding. It appears once per version and closing it is enough; nothing here is forced.
Who can see it
Administrators only, including through the API. A list of what is still unlocked is a shopping list for anyone who should not have it, so a read-only account gets nothing — not even the overview.
Embedding the panel in other sites
The Embedding this panel in other sites card controls which sites may show the panel inside a frame. Since 1.6 the default is this device only.
That is also what the boneIO Black add-on for Home Assistant needs: the add-on proxies each controller, so the framed page is served on Home Assistant's own address and counts as the same site.
The setup that needs more is a dashboard pointing an iframe card or
panel_iframe straight at https://<controller>:8443. Add that Home
Assistant address in the field on the card — the server address only, no path.
Turning the restriction off lets any site on the internet display your panel in a frame. That is what clickjacking needs.
Changes here take effect after the application restarts.
The Home Assistant sensor
The controller publishes binary_sensor.<device>_security — a diagnostic
entity with device_class: problem, ON while something is outstanding.
The details ride on the entity's attributes:
| Attribute | Meaning |
|---|---|
actionable | How many outstanding items — this is what turns the sensor on |
summary | Readable description of those items, for a notification |
advice | The "worth considering" items, kept separate on purpose |
critical, warning, info | Counts by severity |
recommendations | The same list in a form you can template against |
Template against summary for a notification and it describes exactly what
turned the sensor on — not the advice, which would make the automation say
something the sensor does not.
Security events in Home Assistant
The sensor above says how the controller is set up. A second diagnostic entity, Security events, says what is happening to it: it fires when somebody keeps typing wrong passwords, so an automation can send you a notification — the same way it would react to a button press.
| Event | When |
|---|---|
password_guessing | The wrong-password limit just filled — at the login form, the Confirm your password prompt, the change-your-own-password form or the SSH login password card. Once per burst, not once per refused try |
session_signed_out | A signed-in session was signed out after five wrong passwords |
Each event carries the account name (for a login, whatever was typed), the
form (where: login, confirm, password_change or ssh_password), a
readable message for the notification, and the address it came from
(client, left out when it is the controller itself).
Events are not stored: one that happens while Home Assistant or the broker is down is not replayed later. A controller without MQTT still signs people in normally — it just has nobody to tell.