Managed EDR

You all having hands on support and competent teams is what we chose Huntress for and not a competitor. Having an AI gatekeeping the chat for support blocked us from getting support during an incident we detected prior to you all being alerted about it. We were ahead of the incident and wound up having to wait for an email back and forth to create a ticket. Drop the useless AI.

Explicit Timestamp of Isolation in Incident Report In my experience the timestamp of the isolation is missing in every report so far. It would be nice, if it was attached in the remediation tab, as it is with there remediation. E.g a host was isolated. I was struggling to find the exact timestamp, when the isolation was done. If this was more clearly defined I wouldn't have had to raise tickets with support.

Hello Team, Could you please create a feature where MSSPs can receive specific reports monthly rather than daily for passwords saved locally on users machines and SharePoint. With large customers with many organisation units this can be quite prevalent and this in turn generates many alerts that analysts need to triage. Having an option where these can be deferred to a monthly report will help to combat alert fatigue.

Adding credential theft monitoring seems like an easy fit for Huntress and would kill off a competitor service too.

The ability to export a CSV file containing the details shown in the Configured Sources tab under Source Management for SIEM (e.g., source name, type and last activity) and the organization to which the source belongs would be helpful for periodically auditing which sources need attention.

Can we have the option to put in a note when Resolving an incident as to why the incident was resolved? Purely to put a note on the resolved incident, above the incident details, as to have a text field in case we want to put something in like "User logged in from unapproved country causing alert, added country to identity in Unwanted Access country rules for Client, incident resolved"

The screenconnect host section is very useful. It would be great if we could get a notification about new hosts appearing in here because it would be untypical for a new SC server to be added normally and would usually indicate either an incident, or something that needs to be addressed (i.e the previous IT companies remote access being deployed from somewhere). Ideally this would be expanded to alert on additional Remote Access and RMM tools. E.g Splashtop. Attackers are increasingly using industry standard MSP tools to stay under the radar and being able to give us a heads up directly about this would be great. I appreciate the SOC would alert on suspicious activity, though the MSP will be more aware of the context - the ability for us to toggle an option on for this would be ideal.

Organizations using Huntress at scale need the ability to bulk update agent tags for existing endpoints directly within the Huntress portal. Currently, tags are only applied during the initial installation, requiring administrators to either re-register agents or use the REST API to update tags in bulk. Use Case: We initially deployed Huntress as part of a pilot and later standardized our tagging strategy for production (e.g., Shoreside, Vessel, Server, Environment). Existing agents retained their original tags, requiring additional administrative effort to bring them into compliance with our deployment standard. Native bulk tag management in the Huntress portal would simplify onboarding, environment reclassification, organizational changes, and ongoing administration without relying on custom scripts or agent re-registration.

The Problem: Currently, VPN alerts might trigger regardless of whether the device is a managed/registered asset. This creates noise for IT teams who allow remote users to connect via VPN on their company-issued laptops. (e.g. access WhatsApp from Dubai) The Solution: Implement a "Device Awareness" filter for VPN-related detections. Known Device: If a VPN connection originates from a device with the Huntress agent already installed or a device registered/joined in the Intune, the escalation should reflect that.

Adding in new telemetry streams regarding persistence mechanisms and updating information around mechanisms we've seen in the wild