Managed ITDR

When an organisation is allowed to login from all countries and regularly has to do so it creates a lot of noise when tickets constantly get created for them. It would be great if a possibility would be created to exclude an organisation from any login from unexpected country login.

A view that shows all VPNs in use (with usage percentages and the most recent used date so we aren't making changes to things that were used once, months ago) so an Admin easily can see what is in use and make determinations on what to allow within Unwanted Access

This is an incredibly important part of Google ITDR that is not enabled in the current version. Right now, only the “User log events” log is being monitored, which mostly includes login, re-authentication, and 2FA events according to their documentation: https://developers.google.com/workspace/admin/reports/v1/appendix/activity/login This means that if an active token is hijacked and then used to access Gmail or Google Drive, that activity is not being monitored by Huntress. As a result, no alerts are generated even if the access is coming from a VPN or an IP address that is abnormal compared to the one that originally generated the token. For reference, I tested this by using an active session created using a usual IP, connecting to a full-tunnel VPN in a different state, and then archiving an email and sending a few chats to someone. The activity in the Google logs was showing under the new IP, but because Huntress is not monitoring that at the moment, the incident was not reported. As you can see, this creates a pretty significant gap. It makes it hard to justify paying for Huntress Google ITDR when it only monitors events at the time tokens are created, and not what happens after they’re in use (which is typically the more important activity to be monitoring).

We are getting requests to allow for over 10 countries for some users. It would be a lot simpler if there was a way to add multiple countries to an identity at a time.

We have some users based in Europe, or SE Asia, and when they travel we get a few alerts for new countries. It would be great if we could add country groups or continents to allow rules.

Currently they are able to interact with the VPN/Geolocation escalations but not the usage location.

It would be nice if there were an option to create an alert for successful and/or attempted logins for specified admin account(s).

## Problem When a new M365 tenant connects to Managed ITDR, Huntress starts with a blank slate. Today we only run two narrow historic checks at onboarding — inbox rules and rogue applications — then wait for forward-looking detections to fire. If a tenant is already compromised when it onboards, nobody knows until the attacker makes their next move. This leaves a critical gap at the moment of first impression. Tenants frequently onboard while actively compromised, or carrying artifacts from prior incidents that were never fully remediated. Partners have no retrospective story to share with their clients showing what was happening before Huntress arrived. ## What We'''re Doing About It At the moment a tenant completes onboarding, Huntress will automatically look back across up to 180 days of historical activity and run our full identity detection suite against it — credential theft, token theft, adversary-in-the-middle, suspicious browsers, datacenter logins, and more. Active compromises (still ongoing, no remediation taken) generate critical incident reports and trigger identity lockdown, just like a real-time detection would. Previously remediated compromises are added to the ITDR Security Assessment as forensic context, so you can share the full picture with your client. The Security Assessment becomes a comprehensive retrospective rather than a blank report followed by piecemeal findings.

The Identities view is great to drill into activity and details of a specific user, but I would like to see a few more fields added in order to increase the detail of that user's snapshot. Account created date (currently shows only a registered date (this is when Huntress first saw the account). EntraID has the field Created date time Password Last Set field for a quick glance of how old the password of the account is. EntraID has the field Last password change date time User Display name, not just the email (pulled from EntraID / O365) Assigned Roles, specifically admin roles/group (e.g. Global Admin, Sharepoint Admin, etc). User Type :: Member or Guest Additionally, a criticality option would be a nice addition -- something manually configurable for us to set on Global Admins and/or C-Suite individuals in order to raise incidents more quickly or with higher priority/severity.

## 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.