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.

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.

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.

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.

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.

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.

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.

Feedback from a partner we recieved:

I know Huntress has been talking about removing the Security Engineer role completely for Organizational level, but maybe that should be the equivalent of the current admin role, while the admin role is modified to actually allow for all actions. I'm unclear as I don't believe I've run into this issue before, for most clients we do the management of the escalations at the account level, but I would still expect that if I make an internal organization's power user an admin for the organization it would still allow them to resolve escalations. Otherwise, I'm not sure what the point of that role would be? For that client specifically, they found that new VPN connection was unexpected, but they were unable to create a new ITDR rule to effectively take action on the alert.

We need roles for different techs to manage different companies