Home Assistant
RBAC - Role Based Access Control (Users & Groups rights) #22
Replies: 22 comments 29 replies
Dashboard and card Visibility control in the UI editor has User as one of the conditions available. So it gets us part of the way there. However, I agree that visibility control isn't as robust as access control, and user-based isn't the same as RBAC. In fact, instead of RBAC-managing dashboard(s) showing the thing, we should RBAC-manage access to the underlying thing itself, be it a device or an area or a Script or a Scene. And what's shown or not shown on the dashboards to a given user should be reflecting the effects of RBAC being applied to the underlying thing, including:
... Ideally also have "only if these conditions are met" (e.g. only during a given time frame, or only if Admin is also present). So a kid not having access to TV past their bedtime shouldn't be about disabling the TV entity on the dashboard they get to see. Instead it's the TV itself that should be RBAC-restricted for them, and the HA would know not to display such restricted things on dashboards for that user. Otherwise, just as an example, if I can't turn the TV on via the media player entity disabled for me, I may be able to turn it on by entering the new scene editing mode and adding the TV entity to the scene in YAML in the ON state, and just leaving the scene editor on while I watch. But if the TV ceases to exist after 9pm as far as my user's RBAC is concerned, or is disabled or read only, we won't have to worry about the whack-a-mole game with all the work-arounds, we nip it in the bud access wise. |
|
still no real user management in 2025 |
|
I want kids to have access to HA, but doing so is not really doable without RBAC. Preferribly on a per-entity basis, I could make a group that he can use and add devices/entities to it that he can use, hopefully the RBAC could be read-only, read-update (f.ex their phone sensors?), read-update-edit/delete. And also be able to lock them to a special dashboard. |
I think this is already sort-of there, with dashboards / tabs that can be visible per-user. Further to the idea of locking, I like being able to "lock against self" also (see https://github.com/orgs/home-assistant/discussions/13 ), so as to prevent unintended / fat-finger / child or cat playing with tablet being saved. "Capture everything as a deliberate edit, with saving it enabled by default" wouldn't reflect most users' implied intent. |
|
can't I hide a camera from all users ? |
|
On the dashboard: change the visibility of the card to authorized users |
|
Yeah this is a serious security concern that seemingly has gone without being fixed. I'm not sure how as it seems extremely obvious and like a serious security flaw. The whole concept of users and administrator seems like it would necessitate access control. I thought the earliest post was from 2022 but apparently it was from 2020 even earlier than I thought. This is a serious concern that limits the ability of home assistant to be used for serious applications. The closest you get is browsermod but this seems like it's integral to the security of home assistant and has been known about for apparently 5years now. Is there any solid plan to address this? |
|
It’s worth remembering that Home Assistant is designed for a home environment, not a corporate or multi-tenant setup. In most households, everyone using it is already known and trusted, so the focus leans toward convenience and flexibility rather than strict access segregation. Security here often works through social norms — the “soft layer” — rather than strict technical barriers. It’s like a kitchen: you don’t lock every knife in a cabinet, you just teach kids when not to use them. Or like a fridge — everyone keeps their own food inside, and if something’s labeled, others simply respect that it’s not theirs. There’s no need for a separate padlocked fridge for each person. This philosophy makes sense for a system meant to empower homeowners quickly and flexibly. More granular access control might come later, but it’s not core to the project’s intent right now. |
At 2M installs, I think we're well past that "right now" point. I think it's fair to say, "It works just fine for me the way it is" starts to ring a bit differently when there are two million "me's" and growing.
Sure, a house inhabited strictly by able-bodied, neurotypical, responsible, tech-savvy, like-minded adults and their obedient grown-up kids, that receives no visitors of any other kind or keeps their HA interfaces fully secure at all times when receiving such guests, can certainly have the "soft layer" be enough. I thought I had that, until my cousin, who lives nearby & pops in often, had 3 kids. I used to just leave my paring and other kitchen knives in the corner of the counter. Not anymore. Furthermore, nobody was locking doors in the area for as long as anyone remembers, until there was a shooting in the area recently. Imagine using the above logic re: HA access, to install a door that doesn't have a lock. Nay, imagine relying on that logic to install a door which doesn't even support installation of a lock of any common type without a retrofit whose implementation may be flimsy or have issues of its own or inconvenient - i.e. require quite a few iterations to refine to where it's both robust and isn't ugly and is easy to use. And this is right where we're at with HA, with two million doors in active use, unlockable & incompatible with any regular lock types, and we're saying "there's no need anyway - these doors aren't for those high crime rate areas". And I'm typing this from NYC, where my small company is serving its hospitality industry, including some premier restaurants and residences. The latter included two multi-tenant properties, for which the use of HA was favored in spite of its flaws, because it provided the owner with digital sovereignty insofar as privacy/data and non-reliance on cloud or internet connection. |
|
I really hope this is added soon. There are far too many technical entities and elements unnecessarily exposed to family members with no control limitations whatsoever. It's alarming, that still hasn't been taken seriously enough over the years. |
|
For anyone that missed it, in the livestream this month Frenck seems to have said pretty clearly that RBAC is not going to happen (@ ~ 1:16:40). |
He did say "It's a no for now" with the explanation being extensive and to be given separately - but no quick summary on the stream. So it's good to have transparency re: how they feel, and I hope they feel along the lines of "implementing RBAC against the current codebase will break almost everything but we've been working on this total rewrite" as opposed to "we don't think it's important for where we're taking this product". |
|
IMHO most convinient way is to use User Groups to assign privileges on devices/entities/dasboaards. |
|
How we have solved it at my company. We are an iot multidisciplinary harbor, agricultural and meteorological equipments control and management. Our "user" entity varies from our team, our clients, their customers, resellers, our service, resellers service, 3rd party service. These can have various access levels. Our bump was when the reseller wanted to retain service control of an equipment to be able to offer heads up to the equipment owner. The access must be extremely narrow and not to spill end customer business data back. The groups was the only way and group of groups with permissions dedup. An user in special condition can have a custom superseded access. Because there is not an entity ownership access, each company can have their own version of the group. Now the tricky part. How to keep this from destroying the database on each select to make sure each user based on where they are, have the correct access. We solved this with (because our devices use binary we thought to use bin here as well) custom build permission bitmap.
Winns:
Can be improved, but after more than a year of use so far so good. |
|
@ https://youtu.be/aFsINNDTPjU?t=4601 This is not about the trustworthiness of individual users or residents. The problem is more fundamental and far-reaching: What is critical is that most administrators and users are not aware of this risk. When additional users are created, it is not clearly pointed out that there is no real internal data separation at the API level. Instead, terms like “User,” “Admin,” and dashboard visibility suggest that internal access separation exists. By 2026, Home Assistant is no longer merely an actuator control system, but a central platform for collecting and correlating highly sensitive life data (presence, routines, energy and consumption data, security and lock states, and in some cases health data). Because there is no enforceable internal data separation, a single unintentional mistake by any user effectively leads to a loss of privacy for all residents. Human error alone is sufficient—without any malicious intent. The key point is this: this is not a convenience or purely privacy issue, but a fundamental security flaw at the system level. Justifying this risk with “simplicity” or “usability,” without clearly and unambiguously informing or warning users, is no longer appropriate given today’s volume and sensitivity of data. Precisely because Home Assistant places great emphasis on local data processing and is developed by dedicated volunteers, this discussion is important: |
|
I totally agree |
This is 100% true ! And moreover, the latest evolution of the dashboard have broken the small barriers that were existing before : home-assistant/frontend#28480. If the visibility status could just become : "visible for all", "visible for admin only", or "hidden" instead of a boolean, it could already propose a first level of differentiation between admin and users allowing to solve many cases, while not allowing full RBAC implementation. I proposed a FR in that direction: https://github.com/orgs/home-assistant/discussions/2587 |
|
My implementation of Home Assistant is in a club setting. We have a small facility which provides for various functions. These are controlled by various club positions. Being able to create users with read, control, and modify/create rights would allow a more secure, accountable, and controlled approach to access. In a home setting, this would allow various family members to have different views controls access. |
|
It seems like this would be difficult to implement but it seems like it is also very useful to implement. Is there a plan for trying to make all of the integrations and addons compatible with a rule-based access control kind of thing? |
|
I have a cleaning lady who I'd like to be able to give access to some devices without having her call me every time, and also to be able to monitor when she logs in and limit it to certain times. Granular permission management is a must, even for home use. Anyway, thanks for the great work. |
|
Serving the NYC's hospitality industry, I find that keypads are less troublesome than screens for such applications, for the exact reason you specify. Even still, I agree that any UI, including a keypad, should have a default user assignable (perhaps able to be upgraded via some secret entry or based on a known user's precise location).
|
|
Just adding my +1, I am using Home Assistant at a church. We have a few groups we would want to limit access for. Namely, we want to be able to only let certain staff members see any cameras we may connect to home assistant for notifications on movement and such, as well as access to presence sensor data, and access to energy/water usage. We want a second group of people only able to access smart thermostats which are connected. And then a third group of people who can access stage lighting controls for the main room. Apart from any cameras down the road and maybe the presence sensors in my situation, any sort of system doesn't need to be perfectly airtight. Mainly, I just want it to seem impossible to 90% of users to access other pages and other entities, and difficult for the 10% people to hack it if they tried. And of note, each group in my situation can have a dashboard with their own entities and controls, its not like I want a single dashboard to change for different users. Here is a list of implementable steps I would love to see (admittedly I don't know the code base, but each one of these seams more or less bite-sized?, and in my mind increase in complexity the higher the number):
NOTE: When I am talking about "limiting something people can see", I would be fine even if that is just client side filtered. Such that people could technically see it in the inspector or make an API call or something if they are really trying to hack it. But again, I personally am not needing airtight, just average-joe poking around settings tight. :D
|
Relevant: #13 "Read-only" mode for entities
Understandable. But we must appreciate that "seem impossible to 90% of users" is very much a moving target given how well today's toddlers associate a pencil / gear / lock icon (given some innate toddler computer science common sense) with "lemme poke around to see if I can play roblocks at 2am" |
|
I've been working on a proof of concept that implements most of what's been requested in this thread. It extends Home Assistant's existing permission engine with:
All changes are backward-compatible — existing installations see zero behavioral change. The implementation extends the existing Working branch: https://github.com/davefx/core/tree/feature/professional-acl Architecture discussion: home-assistant/architecture#1374 What's not covered yet: per-dashboard access control and integration/add-on level restrictions. These can be added following the same pattern. I'd love feedback from the community and maintainers on whether this direction is viable for upstream merge. |
|
Dave again, I love your effort. I see the architecture discussion, do you have an idea how can other people backport this into their own haas? would hacs help? I wonder how is one currently supposed to compile haas so that one would get this in it (will check it myself, but have not yet checked this)? Can you share some screenshots of the UI there? |
|
Also I am a security engineer and pentester and could stand as an independent third party. Please continue on that if there is really a strong security foundation. I would like to check it myself soon. |
|
I've prepared some methods to run a modified HA-core version using my patches. I haven't had the time to test them yet! I'll keep you informed. |
|
I also have to tell you, my idea is that it would be best to have a possibility to chose which dashboard lower-privilege users can access as well as haas capabiltiies, so that the security engine would configure per-entity and other objects level permission per user and this would apply downstream and provide a layer of security that would be the change I would love to see. I do wonder how much of an overhead this is really adding, I would say from a surface level understanding of your implementation this would be the next level of an effort. But it would make it really usable because I think the option to actually secure each dashboard would be a killer feature! And sure, if you add roles to it, which you seemed to have already done, you get further usability there. Beside that from your description it seems you have already added security in the backend, I was checking the way this works in the browser and there is indeed a lot of websocket communication for example and from the description above it seems you did target it right. Have you considered there could be some bypasses? How far are you there? I would like to recommend you https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/OWASP_Application_Security_Verification_Standard_5.0.0_en.pdf to check how mature is your handling of security. Please check it. If you would be able to validate this yourself, it would help your case a lot. |
|
Also I have to say that haas person denying even just a review of your PRs is understanble, they do have to take autenticationa and authorization seriously and this has to be top-notch to be considered by them. You can also start with threat modeling and think all through much better. Broken Access Control is currently still a problem in modern apps so this is a very important place to have done well. Yeah and I can reiterate that usability would be imporatnt too. You would not only need to have this developed right and securely but also finaly you have to uphold usability, I think the user would need central point to configure this on high level. As I said, lets say role guest, by default he would have only abbility to change his password, decide whether to share location and some mobile app level setting obviosly but then the admin would give him access per dashboard while all would be disabled by default. With that, the app would check which entities are in the dashboard, would enable only view and use only and thats it. Also there would need to be a freeze of access rights, if the admin changes the dashboard itself, the guest should still have the old entities access unless admin gives permission again. I think if you perform threat modeling, think about usability, uphold highest standards as described in ASVS, then add security testing into test cases and then after some time get it tested by third party or at least community, then there would be a really strong case for haas company to consider this. |
Use case: commercial multi-tenant hosting on a single HA instanceAdding a data point from a paying, commercial deployment rather than a household setup. We run a telescope hosting facility. Multiple independent clients rent rack/pier space The current model does not allow this to be secured. Restricting a client to their own dashboard is cosmetic. A non-admin user reaches any
None of these can be disabled by configuration. So today the only thing standing between Assist / LLM conversation agents make it worse. Exposed entities are global to the Why #1374 is the right shape The permission engine already exists and is already backend-enforced across service calls, The label-based approach in this proposal maps onto multi-tenancy almost exactly — one Ask Please consider the incremental path proposed here, starting with the minimal core change Happy to test any branch against a real multi-tenant workload and report back — we have |
|
Copied over from a duplicate FR I suggest preset roles that users can then fine-tune. PresetsPreset names are just ideas. If any of the categories aside from dashboards are not hidden, settings menu must be visible.
Use Case for each presetAdmin = Maintainer Why are upgraded permissions needed?Many Home Assistant instances are in multi-person households or households where not everyone should have full access to everything. There could potentially be a dropdown per user for which role, and they could click on a button to expand the section. So they can choose to use the preset, or to fine tune permissions. The expanded UI could be much like how Google Photos lets you select a whole day, and then unselect photos within it (for lack of a similar UI to reference). Except instead of unselecting/selecting, it's a dropdown menu. NoteI haven't covered all the potential configurable areas above- there are many others like dev tools, media browser, entity search button on dashboards, and so on. |
I agree the non-admin roles ought to be expanded, however, would caution against merging Owner and Admin. In a commercial context, which includes both business use AND a homeowner getting outside help, I think Owner is the role to manage other accounts and their access, and only the Owner ought to be able to blow up the instance or delete audit logs and such. When I deliver a new instance to a client, my role is that of an Installer and/or Configurator. From there on out, in some instances, the client's own IT should be able to take over as Maintainer for the, you know, maintenance tasks, with Installer's access suspended until needed again. Maintainer shouldn't be able to mess with the configuration, other than some input parameters that ought to be in Helper vars. |
This comment was marked as low quality.
This comment was marked as low quality.
|
I started a simple discussion yesterday, but it was closed because this one already exists. One of the first things that struck me about HA—given the size of the system—was its underdeveloped access control. I found it odd that access is assigned directly to a user rather than to a profile that defines what the user can or cannot access and can be applied to multiple users. Given that this discussion has been open since June 2025, does anyone know if an implementation is in the works? |
|
@frenck, what do you think? |
|
It also shocks me that despite all the new features that have been added to HA over the last years, the most crucial one - even basic RBAC or any access control at all that's not just a visibility control that can be bypassed by using the entity search - has been requested a long time ago and isn't even close to being implemented |
|
I guess it's probably quite complex to implement. But I'm surprised that it's not on the roadmap! |
|
I think the rise of LLMs is another good use-case for a better authorization concept. e.g. I'd like to give my assistant access to HA to create / alter a specific dashboard. I sure as hell don't want to give it access to some more security critical entities. |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
One concrete privacy use case that should be explicitly covered by RBAC is Media Browser access. Currently, an administrator can hide a camera card from selected users on a dashboard, but the same camera may still be accessible through Media > Cameras. Hiding the Media sidebar item with a custom frontend plugin is only a visual workaround and does not provide real access control. Permissions should therefore be enforced server-side for camera entities, media sources, sidebar panels, and alternate UI or direct URL access paths. Detailed example: https://github.com/orgs/home-assistant/discussions/4115 |
|
I think that's the last thing I need. |
|
I don't understand, this is the 2nd highest feature request yet still doesn't appear on the HA roadmap as far as I can tell?! |
Looking at the roadmap there is a whole load of stuff that doesn't seem higher priority to me compared to having proper RBAC in place |
Must admit I haven't looked in HACS or other places for community solutions to RBAC, so I'll go and have a look |
I found something: https://github.com/SamAthanas/user-rbac I don't know how bulletproof it is... |
|
Browsermod & kiosk mode are the basic sort of ones, then you get full RBAC repos. I've seen a few around recently (mostly AI but some are probably quite good). UIX may also allow you to implement similar restrictions to kiosk mode, although I haven't tried. Personal setup (tried to make this a details block but Github didn't cooperate unfortunately) Kiosk Mode UIX / UIX theme
Lock template |
|
Is one of those core features which was probably not predicted probably at all in the initial format. |
|
The major security flaw in Home Assistant lies in the "search bar" with its "universal access." I worked hard to build my home dashboards and create non-admin users, ensuring they could only access—via the user interface—what they were explicitly permitted to see. However, the search bar simply grants any user access to any entity in the system, with absolutely no restrictions. If it were possible to restrict access to this function to administrators only, it would make sense to create dashboards for users with controlled access to system features. But that unrestricted global access via the search bar renders any effort you make in that direction completely useless. It is simply an absurd situation! 
|
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Describe your core improvement
See discussion here, bringing this Feature Request from the Forums to here. (It's bound to happen sometime).
Legacy Feature Request
https://community.home-assistant.io/t/rbac-role-based-access-control-users-groups-rights/467158
WTH 2024
https://community.home-assistant.io/t/wth-no-access-control/802297
WTH 2022
(WTH 2022 RBAC thread was merged into Legacy Feature requests at some point)
https://community.home-assistant.io/t/wth-why-cant-we-limit-logbook-history-devtools-maps-to-admins-only-specific-users/470280
WTH 2020
https://community.home-assistant.io/t/wth-no-rbac-role-based-access-control-users-groups-rights/219581
Current limitations
You cannot create a locked down interface with limited controls for other users on the system.
Technical benefits
Additional context
No response
All reactions