Managed ITDR

It seems that Huntress just wants this Entra Usage Location set so they can use it as a datapoint, setting it per user it tedious. MSP and IT also use JIT accounts which can create accounts on the fly. As an MSP, we are getting these alerts for every JIT account being created. For all our clients, we could simply just tell you (in settings) that USA is the only Usage Location, vs setting this on a per user basis. Above that, if there was a single user in say Japan, it would be better for us to set that usage location on their identity in Huntress, not in Entra.

Hi Huntress Team, It has been unnecessarily confusing to investigate VPN-related ITDR alerts, particularly in BYOD environments where users access corporate resources from personal cellphones using VPN services. I've raised this concern multiple times, but we're still running into the same issue. A few improvements would make these alerts significantly more actionable: Device context: Clearly distinguish between sign-ins originating from personal mobile devices and corporate-managed laptops directly on the alert review screen. Show this upfront. IP enrichment: Provide more context about the source IP. Is it residential, cellular, commercial VPN, or a data center? Who is the ISP? Alert investigation: Surface enough information to help analysts determine whether the activity is genuinely suspicious without having to cross-reference Microsoft Entra sign-in logs every time. Currently, we routinely have to validate these alerts against Microsoft logs to understand what actually happened. This raises a bigger question about the value of ITDR as a standalone product. If we consistently have to rely on Microsoft Entra and Defender logs to validate Huntress alerts, it becomes difficult to justify paying for ITDR rather than configuring the appropriate detections and alerts directly in Microsoft Defender. The value of a managed detection product should be reducing investigation effort, not adding another layer of alerts that require manual validation every time. I'd appreciate knowing whether these improvements are on your roadmap or if there are existing capabilities we're overlooking. Thanks, Reni

We recently received an escalation about a login through an unusual VPN service to an account at one of our clients. I wanted to share some feedback on the incident report and our follow-up with support, with the goal of helping improve reporting and user training. When we reviewed the reported IP addresses, we recognized them as belonging to data centers we regularly block due to brute-force attempts against that same client’s VPN. We disabled the affected account, revoked all sessions, and began investigating. Our investigation found that the attacker had successfully signed in from multiple IP addresses and registered an additional MFA method. We removed the malicious MFA method while retaining the user’s existing passkey. We also followed up with the user and verified that subsequent attempts by the attacker were failing. The incident report described a different sequence of events. It stated that the activity was detected because of the unusual VPN, but that the attacker had removed all MFA methods and subsequent attempts were blocked because no MFA methods remained. That did not match what we observed: the attacker added an MFA method, and our team removed it while leaving the legitimate user’s passkey in place. When we followed up with support, we were told that newly registered MFA methods are not expected to be reported and may or may not be included in the incident report. I also want to emphasize that Huntress’s unusual VPN alert is what prompted us to investigate in the first place. That alert gave us the opportunity to identify the compromised account and take action before this became a much larger incident, and we appreciate that. My feedback is focused on making the reporting that follows that valuable detection more accurate and useful. Clearly distinguishing the attacker’s actions from our remediation, along with explaining when newly registered MFA methods are monitored or included in reports, would help partners understand the incident and communicate it accurately to clients. This could also be a useful example for partner training: the initial alert successfully brought us into the investigation, while the differences in the final report highlight an opportunity to improve how the findings and response are documented.

It would be a good idea to deactivate any devices that were added in Entra during the attack, or at least include this step in the remediation plan, as these devices could provide persistence mechanisms for an attacker after the incident.

## Problem Bringing a new M365 tenant under Managed ITDR is the first step of every partner-client relationship. Partners need that process to be fast, predictable, and visible — they need to see exactly where each tenant is in onboarding, get an accurate signal when something requires their attention, and minimize the time they spend manually walking each tenant through setup. Partners running ITDR across dozens or hundreds of tenants also need a single place to monitor onboarding progress without checking each integration individually. As Huntress expands Identity protection beyond ITDR, partners also need a simple path to add additional Identity products to a tenant they've already authorized — without restarting onboarding from scratch. ## What We're Doing About It We've rebuilt the ITDR onboarding flow with the partner experience at the center. Partners see clear status as each tenant moves through onboarding. Common errors are automatically corrected, and when partner action is required, we send a specific, actionable notification. The new onboarding flow also supports adding additional Identity products to an existing tenant as a one-click action. ## Impact The manual steps a partner walks through to onboard a tenant take roughly two minutes; the remaining onboarding work completes in the background. Real-time visibility into the status of every tenant being onboarded. Common onboarding errors are auto-resolved; the rest come with a clear, action-specific notification. Additional Identity products can be added without re-authorizing the entire tenant.

Add the ability to select a policy, then select multiple customers to accept risk. Or accept risk for a policy at the account level.

Can we please split up the trusted device suppression so VPN's & Countries are not joined into the same setting. Simply the same as already created but with a different option for each type of escalation notification suppression. Equally if a client has a hard block rule on specific VPN's/Countries it would be good if this still issued a critical and took the correct action, these rules should be enforced prior to notification suppression rules come into play.

Providing the IP address causing a rule violation would be useful.

Allow geo-location (country), VPN and IP-based detection rules in Huntress ITDR to be scoped by Microsoft Entra ID user attributes (job title, department, group membership, or custom security attributes / extension attributes), instead of only applying them uniformly across the entire organization.

Per the latest product update, Chris mentioned that permission requirements have changed for ITDR. Huntress should have a way to validate if partner organizations are setup with latest graph API permissions to enable most up-to-date ITDR detections.