Managed ISPM

rollback of entra changes made outside of ISPM

We'd love to see more flexibility in tailoring ISPM reports to a customer's actual Microsoft 365 environment. Many of our MSP customers use Security Defaults and don't have licensing for Conditional Access or advanced Defender features. Yet these controls still appear as non-compliant, driving down their overall compliance rating. Ideally, ISPM could recognize licensing and baseline configurations automatically, or let MSPs define which controls apply. For example, a Business Standard tenant using Security Defaults shouldn't be penalized for not having Conditional Access policies. We'd also like to see a distinction between Not Applicable, Risk Accepted, and Non-Compliant, with the compliance rating adjusted accordingly. Simply hiding controls from the report doesn't solve the scoring problem. These are customer-facing reports that we use to demonstrate security improvements over time. We want customers focused on actionable improvements, not overwhelmed by findings that don't apply to their environment. The goal is simple: Make compliance ratings reflect the security controls a customer can actually implement within their existing configuration.

It would be great if we can specify a group or users that are excluded from managed policies (CA). For example the CIPP user should be excluded internally (if you use CIPP) and also a Break Glass Admin Account which is excluded from all policies should also be an option to set.

I would love a way I could see a managed deployment scheduled per organization. I can see that in your ISPM you can go to Details > and see what organizations are compliant, but an ability to select a specific client will let me better understand the independent organizations current standing, and when planning to roll this out for the org, what kind of affects I can tell the client they will receive. When a customer wants a day by day schedule on what is going to be affected, this would be great to share with them. Perhaps even an exportable list to send them?

When receiving a newly-noncompliant escalation for a control, the escalation page lists the steps to resolve but nothing about which account or setting triggered the escalation. For example, if we receive a notification that an administrative account now has an application license, the escalation should highlight which account that was (and Ideally the variable before/after that changed in order to trigger the escalation). It seems like the data is already there based on the escalation text "Huntress detected a compliant security control becoming noncompliant", and this change would save technicians from needing to hunt down whatever account may have caused the alert.

High/Medium/Low severity rankings applied to these to help prioritize - points out some easy wins - which policies to start enforcement on and how to prioritize.

The control currently treats any Conditional Access exclusion as non-compliant. However, exclusions for Privileged Identity Management (PIM) eligible administrators are required for PIM to function correctly. Conditional Access evaluates active role assignments, not eligible assignments. An administrator with an eligible role is treated as a standard user until they activate the role through PIM. If the Azure Portal and Entra Admin Center are blocked, those users cannot access the location where elevation occurs, creating a catch-22 where they cannot elevate because they are not already elevated. Consider allowing exclusions for PIM-eligible administrator groups without marking the control as non-compliant.

There needs to be an option to exclude break-glass accounts from this check! We regularly test our BGA accounts, but worst case ISPM blocks the sign-in, something else happens and then we're locked out of the tenant. This should not happen.

When ISPM performs an action, it would be very useful if the ISPM Actions log provided a detailed view of the identities that have been modified. As an example, if ISPM executes the task for "Ensure sign-in is blocked for member accounts inactive for 90 days" or "Ensure sign-in to shared mailboxes is blocked" to disable sign-ins we have no visibility within the ISPM platform as to which identities this task was performed against and have to manually check Microsoft 365 audit logs

Can you add a filter so it's easy to see which problems can be automatically fixed and which ones need manual intervention?