Managed ISPM

The control "Require Huntress Managed 'Disable Desktop and Mobile Client Access for Guests' Policy" reports Compliant on a policy that has been modified so it no longer matches the control's own documented audit procedure. The check does not appear to inspect WHICH guest/external user types are selected under Users. STEPS TO REPRODUCE Deploy the managed policy to a tenant and let the control report Compliant. Turn Continuous Enforcement ON for that control in that organization. In the tenant, edit the CA policy: Users > Include > Guest or external users, and uncheck one user type (we unchecked "Service provider users"), leaving 5 of 6 types selected. Save. Wait for the next compliance check. EXPECTED The control reports Not Compliant and, with Continuous Enforcement on, remediates. The control's own Manual Remediation & Audit text states: "Under Users verify Guest or external users is selected and all guest and external user types are included" and "Under Target resources verify All cloud apps is selected with no exclusions." ACTUAL The control reports Compliant and does not remediate. The modification persists indefinitely. Observed 2026-09-02: control last checked 02:06:01 UTC, status Compliant, Continuous Enforcement ON, while the policy had "Service provider users" unchecked. No non-compliance event was raised and no remediation occurred. Enforcement was demonstrably active at that moment: the ISPM Actions log for the same organization shows "Update Conditional Access Policy for [HUNTRESS] Block Device Code Flow" at the same timestamp. The platform was pushing policy changes; it simply did not detect this one. WHY IT MATTERS With Continuous Enforcement on, a Compliant status is a statement that the policy matches the Huntress template. Here it does not, and nothing surfaces that. Any tenant where someone narrows the user-type selection still reads Compliant, so the control's score across an estate is not a reliable measure of the posture it claims to represent. Detection is inconsistent between controls. The existing post "PIM-eligible administrators should not fail the 'Restrict Azure Portal Management' control" reports that that control treats ANY Conditional Access exclusion as non-compliant. One control flags every exclusion; this one misses a user-type change entirely. Whichever is intended, it should be consistent and documented. SUGGESTED FIX Have the compliance check compare the policy's selected guest/external user types (and any Users-level exclusions) against the template, not just the policy's existence, state and grant control - i.e. verify what the published audit procedure already says it verifies. RELATED "Conditional Access Policies - Break Glass & Service Account(s)" is the underlying need: partners need a supported way to exempt specific identities (break-glass accounts, RMM/CIPP service accounts, and GDAP service-provider identities) from managed CA policies. Today the only route is modifying the policy, which either gets reverted or - as here - silently passes the compliance check.

ISPM can see the existing conditional access policies in my tenant but it does not look like it has the ability to review them and mark them as compliant. Current I have a block legacy authentication policy and a require MFA policy but ISPM is marking these as noncompliant because they are not Huntress conditional access policies. It would be nice to either mark these as compliant manually or if ISPM could just review them and mark them as compliant automatically without me having to create another conditional access policy in my tenant.

MSP's manage customer tenants over GDAP and there are some Huntress Managed CA policies that should allow exclusion of our Microsoft Partner tenant. For example, deployment of the "[HUNTRESS] Restrict Azure Portal Management" policy blocks the partner from accessing the Entra Admin center page over GDAP, with error "Your sign-in was successful but you don't have permission to access this resource". This would be solved by excluding the partner tenant ID.

This may already be on the roadmap, but just like there are 'Huntress Managed' CA policies, it would be great to have Custom CA policies that we can create with our own settings and deploy as a baseline across multiple tenancies.

I deployed a Huntress Managed CA Policy to my 365 tenant ([HUNTRESS] Block Downloads for Guest Users), then logged into the 365 tenant and manually changed settings on this policy (excluded 3 of the guest roles intended to be targeted), to test whether or not Huntress would revert my changes to bring the CA policy back into conformity with the Huntress recommendation. This did not happen. My expectation is that a Huntress Managed CA policy will be managed by Huntress and kept in compliance with the Huntress standard. If I can "break" the policy manually directly in the tenant, and Huntress doesn't remediate that, then it's not truly managed. Now I haven't tested this with other Huntress Managed CA Policies, so I don't know if this problem is unique to this specific Huntress Managed CA Policy. But if Huntress isn't able to maintain conformity to this policy, then it isn't really managed. Is it on the roadmap for the Huntress Managed CA Policies to revert back to compliant, if someone changes the policy within the tenant? It feels like the intention behind using a Huntress Managed CA Policy is to keep these policies to a known standard.

When onboarding ISPM, it would be helpful to have an extra set of eyes to look over conditional access policies to confirm that they are not unintendedly opening up security gaps.

We have enabled the policy "[HUNTRESS] Block Unused Device Types" in the Conditional Access section, but there is nowhere to set which device types are considered unused. We have one engineer who runs Ubuntu Linux on a desktop who cannot login with this policy enabled, also a Lenovo Android tablet with Firefox browser installed shows as Linux too so can't access it - we can exclude his user specifically, but is it possible to edit the device types? So for us we could allow Windows and Linux but block macOS because we don't have any Apple Mac's

In the ISPM > Conditional Access Policies, please add the ability to view the Identities & Groups that are included/excluded from the CAP. When we first onboarded ISPM, I recall seeing the ability to view the Identities & Groups included, but now I am not seeing them -- only the number included. I would like to view the Identities & Groups. In cases where there is an expected travel location, confirming that the user is in a "Geofence Exclusion" policy would be a quick method to confirm if the user is authorized to travel in that country (or at least is expected to travel outside of the company's home location).

Rolling out the Huntress Managed CAPs to our client base in learning mode. Some tenants are not setup with Entra P1, thus cannot have the CAPs applied. Can we get the option to filter out tenants that are ineligible for CAPs. Currently our Managed CAPS dashboard shows that ~75 tenants have a policy in REPORT mode, and ~10 tenants are missing a policy. Whilst this is 100% true, its also misleading, as those tenants CANNOT have a policy.

Microsoft managed policies are a different beast with different options and different ways to deal with them. On the dashboard, there should be a distinction between custom and Msoft Managed ones. also maybe a way to handle them by automation. For example an option to auto-disable new Microsoft Managed policies that have popped on the tenant, or at the very least some kind of alerting on that