Expansion of user roles
under review
C
Chris Amalfi
Custom roles would be very helpful. I could go into the details for our specific use cases that would help our business but those may not help the vast majority. Example: An Onboarding role for a user who can add organizations to Huntress, configure base settings within each product, possibly even exclusions (which is a combination of admin and security engineer roles) but which does not have access to any of the integrations, billing areas, or other back-end settings. It would also not have access to certain security-related functions like isolation, defender actions, or incident reports.
L
Larry Ma
Based on the current limitations with permissions, we really need either the ability to limit Account Level to certain Organizations or be able to expand Organization Level Admin privileges so they can respond to ITDR alerts.
V
Victor Hong
Use Case – Org-Level Admin Access Limitations
As an MSP managing multiple client organizations, we support clients who need timely visibility and response to Huntress ITDR alerts.
Currently, Organization-Level Admins can view “Login from unexpected country” alerts but cannot take action (e.g., resolve alerts or create ITDR rules). The only workaround—granting Account-Level Admin access—would expose all other client environments, which violates least privilege and poses a security risk.
To help surface these alerts, we’ve implemented email forwarding rules (as per Huntress support guidance) to bring them directly to our client’s internal security team. This has increased engagement and accountability on their side — they now expect to be able to act on the alerts they receive. While these specific alerts are not high-risk (with Managed Response covering critical threats), the lack of actionability at the org level is now creating friction.
Importantly, this should be viewed as a positive evolution within the MSP model: we’re driving visibility, improving response culture, and helping the client take ownership — all without stepping outside Huntress's intended structure.
It would be ideal to:
Expand Organization-Level Admin permissions to manage ITDR rules and alerts
OR
Allow scoping of Account-Level Admins to specific orgs only
This would improve client confidence and streamline response without compromising multi-tenant separation. Any updates on roadmap timing would be greatly appreciated.
B
Ben Neville
We have a client that is managing their own org in our account. They want to be able to setup identity rules for when staff travel overseas which seems like a standard thing an Org Admin / Sec Eng should be able to do.
Speaking with Support they confirmed this isn't a permission they have currently. I believe that it should be.
B
Bryce Skelton
This would be amazing. We have an issue where techs may need to approve an exclusion for troubleshooting, but we wouldn't want to give full access to everything else. The current issue is not everyone is as security conscious so there would be significant overhead in auditing tenant settings to ensure nothing was improperly adjusted. If we could do RBAC or make our own custom roles and pick and choose access to various components that would be a game changer and allow our internal security team to expand the access for other techs that we currently limit.
T
Thomas Welch
The best model I can think of would be to allow the creation of custom roles where Account-level, Global client-org, and Individual client-org permissions can be individually assigned to the role. Allowing the use of custom role names could allow integration with SSO so that IdP group memberships can automatically determine roles and permissions.
Our org is deeply invested in Entra as our IdP so using our existing Entra group memberships to assign roles and permissions in Huntress would be the ideal solution. Even better if SSO could automatically provision/deprovision users so we can manage identity solely in our IdP during user on/off-boarding.
It's common for c-staff to request access to things like Huntress, especially if they get copied on alerts. SSO would at the client-org level would be great. This could allow us to automate creating organization users and granting them permissions based on Entra group memberships. It could be easily integrated with the M365 tenant mapping process.
J
Jason Boyd
Granular permissions are really needed. As others have commented, we need the ability to assign part of our MSP team with the ability to manage some items (isolate, de-isolate, Defender exclusions) for every client individually, but not globally.
J
Josh Spern
As others have said, the ability to granularly assign permissions is very much needed. The "Security Engineer" role as it stands today is too permissive.
Eric Henry
under review
J
Jeff Custer
We would like to be able to disallow account-level access changes for Account-level users (example, not be able to set an exclusion for a country...for ALL organizations), or maybe even allow ONLY user-level access changes for Account-level users (our technicians who currently have the "Security Engineer" role). Another way to put this is: We need the ability to granularly assign permissions per role. In addition, adding the ability to granularly assign organization-level permissions (for internal IT users at the larger clients) so they can do things like set travel exclusions for VPN/Location Escalations for their org, for example.
Load More
→